Most deployments do not fail on code. They fail in four conversations: the demo that breaks in front of executives, the customer who insists on the wrong feature, the security gatekeeper who will not release the data, and the manager whose team gets smaller if you succeed. Every FDE interview probes these — reported OpenAI loops weight case and empathy work at roughly half the evaluation — and every guide tells you to rehearse them with a friend. Here they are as branching dialogue, with a live trust meter and a scored verdict.
4 scenarios · branching replies · live trust meter · signals scorecard · verdict
trust
The only currency you have. It buys scope changes, bad news, and time. Spend it deliberately.
scope the failure
When something breaks, say what it is not. Uncontained failure contaminates the whole system in the room’s mind.
the outcome behind the ask
Every wrong request is a right outcome wearing a bad costume. Find the outcome and you can redirect without refusing.
rational opposition
Blockers are almost never villains. They are people whose incentives your project threatens. Find what they win.
customer-room.live
Choose a scenario
Each scenario runs four beats. Your reply changes what the customer says next and moves the trust meter. There is no perfect script — there are answers that keep the room, and answers that lose it.
50
trust
0/4
beat
—
room
The four signals being scored
Interviewers running a roleplay round are not grading your charisma. They are checking four specific behaviours, and each one maps to a way real deployments die.
01
Listen before you answer
The first move in every scenario is a question, not a position. Engineers lose this round by answering the question that was asked instead of finding the one that matters. In a deployment, the same reflex is what makes you build the requested feature instead of the needed one.
02
Deliver bad news early and plainly
Bad news does not improve with age; it compounds. Saying “this will not be ready Friday, here is what will” on Tuesday costs a fraction of what it costs on Friday afternoon. Candidates who soften the message into unintelligibility score worse than candidates who are blunt.
03
Say no in a way that increases trust
The move is: ask what outcome they want, name the mismatch, offer a path to the outcome. Never bare compliance (you build the wrong thing) and never bare refusal (you lose the relationship that lets you build the right thing).
04
Treat opposition as an incentive problem
The person blocking you usually has a reason: headcount, credit, workload, risk exposure, or being the only one who understands the current process. Escalating first converts a solvable incentive problem into a permanent adversary, and everyone in the room remembers who escalated.
The sixty seconds after a demo breaks
This is the single most-tested scenario, because it is a compressed sample of everything else. There is a script that works, and it takes about fifteen seconds to deliver.
// the four moves, in order1. name it "That's failing — let me tell you what that is."
2. scope it "That's the ingest path, not the model. Everything you saw before it is real."
3. commit "I'll have the cause by end of day and a fix or a workaround tomorrow."
4. continue "The next part doesn't depend on it — can I show you that?"
What makes it work is move 2. An unscoped failure expands in the room’s imagination until it covers the entire system; a scoped one stays a bug. What breaks it is apologising at length, blaming the environment, or quietly restarting things and hoping nobody noticed — all three read as someone who cannot be trusted alone at a customer.
worst move
silence
second worst
blame
best move
scope it
time budget
~15s
The picture: one scenario, two paths through it
Every beat offers four replies, and each reply carries a fixed trust change. The meter is the running sum, starting at 50. The verdict at the end then applies two tests at once: the final trust, and how many of the four signals your replies showed. A signal counts once, however many times you show it. In this scenario, beats 1 and 3 both show “bad news early”, so the best path collects three different signals, not four.
Worked example: high trust that still misses the top band
Play The wrong feature and choose well, except for one reply that sounds reasonable at beat 4. Every number below comes from the lab’s own scoring table.
Beat
Your reply
Δ trust
Trust
Room
Signal
start
—
—
50
cooling
—
1
“What would you do differently if you were looking at that screen?”
+15
65
open
listens first
2
“Thursdays — tell me about that.”
+14
79
with you
listens first (again)
3
Automate the Thursday report first, and let it feed the dashboard
+16
95
with you
says no well
4
“Just approval to change the scope in the statement of work.”
+2
97
with you
none
verdict
97 trust, but only 2 distinct signals
Leaning hire
Trust of 97 clears the 80 bar easily. The verdict still drops a band, because beats 1 and 2 showed the same signal and beat 4 showed none. Swap beat 4 for “an hour with whoever does the Thursday assembly, and a decision on what counts as correct” (+13, reads incentives). Trust becomes 108, shown as 100, with 3 signals: Strong hire. The lesson carries over to the real round. Interviewers score the range of behaviours you show, not just whether the room ended up happy. Asking for access and a definition of done is a separate skill from listening, and only one of them was missing here. The opposite failure scores worse. In The demo breaks, name it (+12), then “hard to say” (−12), then commit (+14), then “up to you” (−8) ends at 56 with one signal: Leaning hire by only one point over the 55 line.
Trade-offs: what each kind of reply costs
For a conversation, the columns mean: Time is what the reply does to the schedule, Space is what it does to trust in the lab (the Δ values from the scenarios), and Why is the mechanism.
Case
Time
Space
Why
Ask first: the outcome, or what they need to see
Costs a pause now and saves weeks later
+14 to +15 wherever it is offered
Turns a stated request into the real requirement before you commit to anything.
Specific commitment with a date
Fixes the next checkpoint
+14 (demo, beat 3; security, beat 2)
Converts bad news into a competence signal. The cost: you must hit the date.
Bare compliance
Fastest yes in the room
−14 for “Sure, three weeks is doable”
You ship the thing nobody opens in month two. The delay just comes later.
Bare refusal or correction
Ends the topic, and the goodwill
−8 to −12
Being right without shared evidence turns it into a contest of opinions.
Answer a feeling with a metric
Quick, and settles nothing
−10 for “Our evaluation shows 94% accuracy”
Their experience counts as evidence too. Asking to see the cases it got wrong scores +14 at the same beat.
Waiting it out
Free today, and the engagement clock keeps running
−10 to −14
Your champion has nothing to defend you with.
Escalate or invoke authority
May unblock this week
−12 to −16
You win the access and make a permanent adversary of the person who approves every later change.
Route around a control
Looks fastest
−16, and it can end the deal
It will be discovered, and it confirms the reviewer’s worst assumption.
The pattern across all four scenarios is the same. The reply that feels fastest in the room (comply, refuse, escalate) is the one that costs the most trust, and trust is what pays for every later scope change. The replies that score best all cost a little time up front: a question, a draft sent early, a specific date. That is also why no single script works across all four. In the demo, a firm commitment is the strong move. Against the security lead, committing to anything before you have asked a question is the weak one.
Check yourself
A customer insists on a feature you are confident will not solve their problem. Best first response?
The request is a proxy for an outcome. Once the outcome is on the table you can propose a better route to it, which is a redirect rather than a refusal — and if it turns out they were right about the mechanism, you have lost nothing. Leading with “you are wrong” wins the argument and loses the deployment.
Security has blocked your data access for three weeks. What does a strong FDE do?
Two things at once: visible progress on the unblocked parts (synthetic data, the pipeline, the interface, the eval harness) and a specific escalation with a named owner and date. Waiting burns the engagement clock; routing around security is the one move that can end a deal outright.
A middle manager keeps raising objections that stall the rollout. Most likely explanation?
Objections that keep arriving from the same person are almost always an incentive signal, not a comprehension gap. Find what they win if this works — ownership of the new process, a metric that makes them look good, credit in the readout — and the objections usually stop. A better demo does not change anyone’s incentives.
Common questions
What is a client roleplay round in an FDE interview?
An interviewer plays a customer in a difficult situation and scores how you listen, how honestly you handle bad news, and whether you can decline a request without losing the room. Reported OpenAI forward deployed engineer loops weight case, empathy and business judgement at roughly half the total evaluation.
What do you do when a demo fails in front of the customer?
Name it, scope it so it does not contaminate everything else, commit to a specific time for the cause and the fix, and continue with the parts that do not depend on it. Handled that way a visible failure builds more credibility than a flawless demo, because the customer learns how you behave when something breaks — which is what they are actually buying.
How do you say no to a customer?
Ask what outcome they want, name the mismatch between the request and the outcome, then offer a path to the outcome. Bare compliance builds the wrong thing; bare refusal costs you the relationship you need in order to build the right thing.
How do you handle a stakeholder who is blocking the project?
Assume a rational interest rather than malice: headcount, credit, workload, or risk exposure. Find out what they win if the project succeeds and make it explicit. Escalating over their head first is the most common mistake and it turns a solvable incentive problem into a permanent adversary.
Can you really practise this alone?
Partly. What a simulator drills well is recognising the shape of each situation and knowing the strong move — which is most of what candidates get wrong. The conversational half, including handling an interviewer who probes your answer, still needs a human. Run all four scenarios here first so you are not spending a real rehearsal on the basics.