The FDE client role-play interview

In the FDE client role-play, the interviewer plays a stakeholder — usually non-technical, often mid-frustration — and you run the conversation live. Nothing in it requires you to solve anything. It's scored on four behaviors: you ask before proposing, you speak in their language, you stay with their concern instead of retreating into your architecture, and you don't get defensive when the temperature rises. The question behind the round is the question behind the whole loop: can I put this person in front of our biggest client?

Two things make this round worth over-preparing. First, almost nobody prepares for it at all — engineers rehearse system design for weeks and walk into this round cold. Second, it's frequently the decider. A rejection email that says "we went with someone whose experience is a closer fit" very often means "the role-play scared us."

This is Stage 2 of the loop mapped in FDE interview questions & how to prepare.

The candidate who failed it

A composite from real loops, and I meet a version of this candidate most months: strong resume, big-name company, genuinely polished take-home. The scenario was wrong dashboard numbers. The "client" (me) opened with the complaint. The candidate's first full sentence was a tour of the ingestion pipeline — where the dedupe job sits, why the upstream join might double-count. Technically plausible. But I, playing the client, repeated my actual concern twice — "my boss presents these numbers Friday" — and never got a response to it. Not once in twelve minutes.

That candidate was a no, and it wasn't close. Not because the pipeline theory was wrong — because in the field, that exact conversation is how an account churns. The customer doesn't remember whether the dedupe theory was right. They remember that they said "Friday" three times and the engineer said "Kafka."

The scenarios you'll face

The setup is always some version of "the client is unhappy and you're in the room." Three shapes cover most of what actually gets run:

• 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 that none of these can be solved in the room. That's deliberate. They're testing the conversation, not the fix.

A passing run, annotated

Here's how a strong run of the wrong-numbers scenario actually sounds. The annotations are what I'm writing on my scorecard at each moment.

Client: "Your dashboard has been showing wrong revenue numbers since Tuesday. My boss presents these to the board on Friday. What is going on?"

Candidate: "Okay — that's bad, and I want to get you an answer quickly. Before I guess at a fix, can I ask three quick questions?"

Scorecard: didn't propose anything yet. Asked permission — which sounds small, but it puts the client back in control of a conversation they feel they've lost control of.

Client: "Fine."

Candidate: "Did anything change on your side around Tuesday — a new data source, a system upgrade, anyone new touching the pipeline? … Which numbers specifically are off, and roughly by how much — inflated, deflated, or random? … And besides Friday's board meeting, is anyone else making decisions off this dashboard right now?"

Scorecard: three questions — timeline, symptom, blast radius. The third one is the mark of someone who's actually deployed at customers: wrong numbers being read is a bigger emergency than wrong numbers existing.

Client: "Revenue's inflated, maybe 15–20%. And I don't know what changed, that's your job. Honestly, we're starting to wonder if we picked the right vendor."

Scorecard: this is me escalating on purpose. The curt "that's your job" and the vendor threat are the test inside the test. What I want to see: no flinch, no groveling, no matching the heat.

Candidate: "That's fair — it is my job, and I hear that this has cost you credibility internally. That's the thing I most want to fix. So let me play back what I've got: since Tuesday, revenue on the exec dashboard is inflated 15–20%, the board sees these numbers Friday, and right now you can't trust what you're presenting. The deadline is the real pressure here — is that right?"

Scorecard: absorbed the jab without defending or apologizing in circles, then restated the problem in the client's words. This is the moment most candidates never reach — the client finally feels heard. Watch the last three words: they hand the mic back.

Client: "…Yes. Exactly."

Candidate: "Here's what I'll do. Inflated-by-a-consistent-fraction usually smells like duplicated records rather than a calculation bug, but I don't know yet — and I'd rather not guess at you. Give me until 3pm today: I'll trace Tuesday's data loads, and you'll get a message from me by 3 whether or not it's fixed by then — what I found, what's fixed, and what's left. If we're still not clean by Thursday, I'll build you a verified export for the board deck so Friday is safe no matter what."

Scorecard: one hypothesis, held loosely and translated ("duplicated records", not "the upstream dedupe job"). A commitment with a clock on it. And the Friday backstop — that's the move that says "I understand your Friday matters more than my root cause." That line alone can carry the round.

Candidate: "Before we wrap — does that cover what you need for Friday, or is there something else riding on this dashboard I should know about?"

Scorecard: the checkpoint. Half the time, this question surfaces a second problem hiding behind the first — "well, actually, finance also pulls these numbers…" — and that's where accounts get saved. Full marks.

Total elapsed time: under four minutes. No architecture was discussed. Nothing was solved. And this candidate passed the round in the first ninety seconds, for the same reason the earlier one failed in them.

The loop behind the transcript

Strip the dialogue and four moves remain — they work for every scenario, including the two this page didn't transcribe:

1. Clarify. Minimum three questions before any proposal: what changed and when, what exactly is the symptom (not their diagnosis), who's affected and how badly.
2. Restate. Their problem, their words, their pressure — until you get a "yes, exactly." That "yes, exactly" is audible in real interviews; treat it as your gate to move on.
3. Propose. One concrete next step with a time attached — and report-back that happens whether or not it's fixed by then. Silence until a fix is ready reads as abandonment to a client already burned.
4. Checkpoint. "Does that cover what you need?" — the second problem behind the first is where the round's bonus points live.

For the blown-estimate scenario, the same loop holds with one addition: never relitigate the original estimate and never blame their data — even when their data deserves it. The reframe that works is "we discovered complexity" followed immediately by a re-scoped plan with a nearer win. For the "make the AI never be wrong" scenario, the winning shape is cost-of-error framing: which flows are expensive when wrong (those get review steps and hard constraints) and which are cheap (those get speed). You'll notice that's a system design answer wearing plain clothes — the rounds bleed into each other on purpose.

The jargon test inside the test

Somewhere in the role-play you will have to explain something technical, and the scoring is unforgiving: does it land in their terms or yours? The candidate above said "duplicated records," not "the dedupe job upstream of the aggregation is failing." Same fact, different language, opposite outcome. The reliable test: if your explanation would need a second explanation, it didn't work. "Your dashboard reads from a copy that runs a few minutes behind — the numbers aren't wrong, they're from ten minutes ago" needs nothing after it.

What fails the round

Every failing run I've scored has been some mix of five behaviors:

• Fix-first. Proposing before understanding — even a correct proposal loses, because the field version of that habit builds the wrong thing confidently.
• The architecture lecture. Answering "my boss presents Friday" with a data-flow diagram. The client's concern must be answered as stated before anything else.
• Defensiveness. Relitigating the estimate, defending the pipeline, "well, actually your team changed the schema." Even when true — especially when true.
• The fantasy deadline. Promising Friday-safe-guaranteed to escape an uncomfortable moment. It fails the interview and, later, the job.
• Condescension. Making the client feel naive for asking why the AI can't just be right. That client controls the renewal.

These map one-to-one to the number-one rejection reason across FDE loops: too much engineer, not enough human. And they're why your take-home walkthrough often morphs into a mini role-play halfway through — the take-home proves you can build; this round proves you can be handed a customer. The behavioral questions probe the same instincts in past tense.

How to actually prepare

You can't rehearse a fix, but you can rehearse the loop until it's your default under pressure. Run the three scenarios above out loud — ideally with a friend playing an escalating client, at minimum alone in a room. The goal isn't memorized lines; it's that "can I ask three quick questions?" comes out of you before your pipeline theory does, even when you're nervous and the theory is good. That ordering is the entire round.