The FDE client role-play interview

In the FDE client role-play, the interviewer plays a stakeholder — often non-technical, sometimes deliberately frustrated — and you run the conversation live. It's scored on four behaviors: you ask questions before proposing anything, you speak plainly, you stay with their concern instead of retreating into your architecture, and you don't get defensive. Technical brilliance barely registers here; the question behind the round is "can I put this person in front of our biggest client?"

This is Stage 2 of the loop described in FDE interview questions & how to prepare — the stage pure engineers most often lose on.

The scenarios you'll face

The setup is always some version of "the client is unhappy and you're in the room." Three real shapes:

• The broken-trust bug: "Your dashboard has shown wrong numbers since Tuesday, and my boss presents with it Friday."
• The blown estimate: "We were told this would take two weeks. It's been five. I'm losing faith."
• The impossible ask: "Just make the AI answer correctly every time. Why is that hard?"

Notice none of these have a technical solution you can blurt out. That's the point — they're testing the conversation, not the fix.

The four-move loop

Whatever the scenario, one loop passes it:

1. Clarify. Ask before proposing — minimum three questions. What changed, and since when? What exactly is wrong — the symptom, not their diagnosis? Who's affected, and how badly?
2. Restate. Say the problem back in their words: "So since Tuesday the revenue numbers on the exec dashboard are off, and your boss presents Friday — the deadline is the real pressure here." This one move defuses most frustration, because the client finally feels heard.
3. Propose. One concrete next step with a time attached: "Here's what I'll do in the next hour, and I'll message you by 3pm with what I found — whether or not it's fixed by then."
4. Checkpoint. Before ending: "Does that cover what you need for Friday, or is there something else riding on this?" The second problem hiding behind the first one is where accounts get saved.

What it sounds like

Take the wrong-numbers scenario. A losing answer opens with a fix: "It's probably the ETL job — we'll redeploy the pipeline." A winning answer opens with permission and questions:

"Before I guess at a fix — can I ask three quick questions? What changed on Tuesday, if anything? Which numbers are off, and by roughly how much? And who else touches this pipeline?" … "Okay — so the numbers your boss presents Friday have been inflated since Tuesday, and nobody trusts the dashboard right now. Here's what I'll do in the next hour…"

The single most underrated line in the round is honest ignorance with a plan: "I don't know yet. Here's how I'll find out, and when you'll hear from me." Said calmly, that line alone passes interviews — because it's exactly what a customer needs to hear at 4pm on a bad day.

When they turn up the pressure

Good interviewers escalate mid-scenario — the "client" gets curt, or drops "we're considering alternatives." This is deliberate. They're testing composure, not looking for a groveler.

• Don't match the emotion; address it: "I hear that this has cost you credibility internally — that's the thing I most want to fix."
• Don't over-promise to escape the discomfort. A fantasy deadline fails the interview and the job.
• Don't blame their team or their data, even when it's true. Reframe as discovered complexity — then show the plan.

The jargon test inside the test

Somewhere in the role-play you'll have to explain something technical. The scoring is brutal and simple: does the explanation land in the client's terms or yours? "It's an eventual-consistency issue" fails. "Your dashboard reads from a copy that runs a few minutes behind — the numbers aren't wrong, they're from ten minutes ago" passes. If your explanation needs a second explanation, it didn't work.

The behaviors that fail the round

• Proposing a fix before understanding the problem
• Explaining your architecture instead of their impact
• Arguing about whether it's "really" wrong, or relitigating the original estimate
• Defensiveness in any form — the round is partly a provocation test
• Making the client feel naive for asking a naive question

These map one-to-one to the top rejection reason in FDE loops: too much engineer, not enough human. The candidates who fail this round usually write excellent code — that's what makes the round decisive.

The role-play rarely stands alone: your take-home walkthrough often turns into a mini role-play, and the behavioral questions probe the same customer instincts in past tense.