Interview Prep 03 — Behavioral & Customer-Facing

JD2 is a customer-facing principal role ("trusted technical advisor," "travel for customer engagements," "stakeholder management"). Half the interview tests whether you're someone a customer's VP will trust in a room — not just whether you can quantize a model. This file covers the behavioral stories and customer role-plays that engineers most often fumble.

Table of Contents

Why this round exists

A solutions architect is the human bridge between the vendor's silicon and the customer's problem. The company is betting you can: walk into ambiguity, earn technical trust fast, turn a vague ask into a scoped plan, deliver a POC, handle it when things break in front of the customer, and explain it to both the customer's engineers and their CFO. The behavioral round probes for judgment, ownership, and communication under pressure — the things that don't show up in a coding screen.

The reframe: a brilliant engineer who can't run a customer meeting is not qualified for JD2. The interview weights this heavily and most technical candidates under-prepare it. This is your edge if you don't.

STAR stories you must have ready

Prepare each as Situation → Task → Action → Result, 2 minutes, with a real metric. Map your own experience onto these prompts:

1. "Tell me about a time you turned a vague customer ask into a concrete spec." The skill: discovery and scoping (K08 §6). Show how you converted "make it fast/cheap/smart" into measurable SLOs + accuracy floor + budget, and how that reframing changed the solution. Land the lesson: requirements are usually solutions in disguise; dig to the underlying success metric.

2. "Describe a hard technical trade-off you had to explain to a non-technical stakeholder." The skill: communication + trade-off framing (K08 §5,10). Show you led with the decision and the dollars, used the right analogy, and gave a frontier (fast/balanced/cheap) rather than one answer.

3. "Tell me about a production incident you led." The skill: triage + escalation under pressure (K08 §8). Show the method: stabilize first, classify, minimal repro, escalate with evidence to the right team, communicate continuously, blameless post-mortem. The structure is the point — calm process beats heroics.

4. "When did you recommend against what the customer asked for?" The skill: trusted-advisor integrity (K08 §5). The classic: they wanted the biggest model; you proved a smaller one cleared their floor at a fraction of the cost — or you flagged that their plan would breach a power/latency constraint. Recommending down/against, with evidence, is the strongest trust signal there is.

5. "A time you were wrong, or a project failed." The skill: ownership + honesty. Overpromising and missing, a benchmark that didn't hold in production, a sizing assumption that broke. Show what you learned and the process change. Calibrated honesty about limits is what makes an advisor trusted (K08 §10).

6. "Drove alignment across teams who disagreed." The skill: stakeholder management. Coordinating product + hardware + software (and the customer) to a resolution when they pointed fingers. Show you used evidence (a clean repro, a benchmark) to depersonalize the disagreement.

7. "Delivered something end-to-end you owned." The skill: ownership of the full lifecycle (K08 §6) — discovery → POC → production → handover/docs. Quantify the outcome ($/token cut, latency hit, cameras served, customer renewed).

Customer role-play scenarios

The interviewer plays a customer; you run the engagement. Practice these out loud — the goal is to demonstrate the discovery → spec → trade-off reflex conversationally, not to win an argument.

Role-play A — The over-spec'd ask. Customer: "We need a 70B model on 8 H100s for our FAQ bot." You: don't accept the spec. Ask the success metric ("what accuracy on what, at what latency and cost?"). Probe whether a tuned smaller model + RAG clears it. Offer to validate both on their data. Tests: do you reflexively rightsize and reframe, or just take the order?

Role-play B — The competitor benchmark. Customer: "Vendor Y's slides show 3× your throughput." You: stay calm, don't trash the competitor. Note that benchmarks hide conditions (I/O lengths, precision, latency-vs-throughput, peak FLOPs). Offer to reproduce on their actual workload and show the honest goodput curve. Tests: integrity + benchmarking literacy (K06 §10).

Role-play C — The angry escalation. Customer: "Latency doubled in production and we're losing money." You: acknowledge + own it, stabilize first (rollback/scale), then structured triage (which phase? GPU busy/idle? since when — a deploy or driver change?), commit to a comms cadence. Tests: composure + method under fire (K08 §8).

Role-play D — The impossible triangle. Customer wants max accuracy, min latency, min cost — all at once. You: make the trade-off explicit and kind. "Pick the two that matter most and I'll optimize hard for them; here's what each corner costs." Show the frontier. Tests: can you say no to physics without losing the room?

Role-play E — The non-technical executive. Customer's CFO: "Just tell me, should we buy this?" You: lead with the decision and the money ("this cuts your inference bill ~40% with no measurable quality loss, fits your power budget, ROI in N months"), offer depth only if asked. Tests: altitude control (K08 §10).

The trusted-advisor principles

The throughline of every answer in this round:

  1. Lead with their goal, not your tech. Tie every recommendation to the customer's success metric and dollars.
  2. Turn vague into measurable before you solve. The spec is your deliverable as much as the solution.
  3. Present frontiers, not edicts. Give 2–3 options with numbers and a recommendation; let them choose with eyes open.
  4. Be honest about limits and uncertainty. "Here's what I'm confident in, here's what we must test." Overpromising ends trust.
  5. Recommend against yourself when warranted. Smaller model, fewer GPUs, "you don't need this." It's the strongest trust-builder.
  6. Use evidence to depersonalize. A clean repro and an honest benchmark end arguments that opinions can't.
  7. Match altitude to audience. Engineer-depth for engineers, decision-and-dollars for executives, and move between them fluidly.
  8. Own the whole lifecycle, including the boring handover docs — that's what turns a project into a relationship.

Red flags that sink solutions-architect candidates

Avoid these — interviewers are specifically watching for them:

  • Taking the order. Accepting a customer's stated spec without probing the underlying need.
  • Leading with mechanism. Explaining PagedAttention to a CFO who asked "should we buy it."
  • One answer, no trade-offs. Real engineering is a curve; a single number signals you don't see the frontier.
  • Trashing competitors instead of reproducing the benchmark honestly.
  • Numbers without conditions. "It's 3× faster" with no model/precision/I-O/percentile destroys credibility.
  • Hero, not method. Incident stories that are "I stayed up all night" instead of "I classified, stabilized, escalated with evidence."
  • Overpromising. Claiming lossless quantization, guaranteed latency, or certainty you don't have.
  • Can't say no to physics. Promising the impossible triangle instead of framing the trade-off.

The meta-signal across all of it: a principal solutions architect is calm, evidence-driven, customer-goal-oriented, and honest about trade-offs. Every story and role-play should radiate those four. Pair this with the technical depth and the sizing fluency and you are the candidate JD2 is written for.