Client Simulation & Role-Play
At some point in a forward-deployed-engineer loop, the interviewer stops being an interviewer and becomes your client — impatient, sceptical, sometimes annoyed. There's no right architecture to draw. They want to see how you talk to someone whose project is on fire. This page works eight of those role-plays: the weak reply that loses the room, and the strong one split into exactly what you say and what you do next.
Learning objectives
- Use one repeatable shape — acknowledge, own, explain, commit — for any difficult client moment.
- Explain AI behaviour (non-determinism, retrieval, accuracy limits) to non-technical executives in plain words.
- Turn a confrontation into an agreed next step with a date and an owner.
- Tell the difference between a weak and a strong reply, and say why.
30-second recap
- The FDE method: Work backward from the client's outcome, ship the thinnest end-to-end slice, and iterate in a tight feedback loop with real users.
1 · How the role-play round works essential
This is the round strong engineers fail most often, and almost never for lack of knowledge. The interviewer says "I'm the VP of Operations at your client, and the demo you just gave me didn't work," and waits. Candidates who've spent weeks on system design suddenly have nothing to draw. Some freeze. Some argue. Some start explaining embeddings to a person who just wants to know whether their launch date is safe. The technical content of the answer is usually easy; what's being tested is everything around it.
That's because it's the job. A forward-deployed engineer is often the only person from the vendor that the client sees every week, so your conversations are the product experience. The FDE method only works if the client trusts you enough to give you their real data, their real problems, and a second chance when something breaks. Interviewers score four things: did you listen before answering, did you stay calm when the "client" pushed, were you honest about what went wrong and what you don't know, and did you steer to a concrete next step instead of ending on an apology.
One shape handles almost every scenario on this page. Acknowledge what the client is feeling and what happened, in their words. Own your part plainly, without blaming the model, the data, or their team. Explain just enough — the cause in one or two plain sentences, no jargon. Commit to a specific next step with a time attached. Then stop talking and let them respond. Silence after a commitment feels uncomfortable, but it's where the client decides whether to trust you.
- Read left to right: each box is one move in your reply, in order.
- The first blue box is about the client, not you — say back what happened and why it matters to them before anything else.
- The middle boxes are where engineers over-talk. Owning takes one sentence; explaining takes one or two.
- The green "Commit" box ends the reply on action: what you'll do, by when, and how they'll hear about it.
In short: don't lead with the technical explanation. Show you heard them, own it, explain briefly, and end on a dated next step.
2 · The live demo fails in front of the client essential
Every FDE has this moment eventually, and the interviewer wants to see the first ten seconds. The temptation is either to panic and apologise repeatedly, or to cover it with "that's just a glitch, it normally works." Both lose trust: one looks out of control, the other looks like you're hiding something. What's being tested is composure, honesty in public, and whether you can turn a failure into evidence that you know how to handle failures — which is what a client actually needs from you after go-live.
- Write the exact question down in front of them. It shows you're taking it seriously and gives you the test case.
- After the meeting, pull the trace: was the right document retrieved, and if so, why did the answer ignore it?
- Fix the cause, add the question to the regression set, and re-run the full evaluation, not just this one question.
- Send the promised note by Thursday: what happened, why, what you changed, and the evaluation result after the fix.
- For future demos, rehearse on a fixed script and run the evaluation the morning of the demo.
Why this lands: you named the error before anyone else had to, framed it as better caught now than later, and committed to a dated follow-up. The COO learns something more useful than "the demo worked" — they learn that when this system fails, you'll find out why and tell them straight.
Go deeper: the regression gate · iterating in the feedback loop · talking at the right altitude
3 · "We need the six-week scope in three days" intermediate
The interviewer is checking whether you'll say yes to be liked, or no to be safe — both are wrong. Saying yes means shipping something broken to a board, which is worse than shipping nothing. Saying a flat no leaves the client alone with their problem. What they want to hear is that you find out what the board actually needs to see, and offer the smallest thing that meets it honestly. That's the thin end-to-end slice, applied under pressure.
- Agree in writing what Friday's slice includes and what it doesn't, so nobody is surprised in the meeting.
- Pick the document type with the clearest value and the cleanest data.
- Build that slice end to end, run the evaluation, and prepare one slide with the results and known limits.
- Offer to brief the client's sponsor before the board meeting so they can present it confidently.
- Confirm the remaining scope and dates the following week.
Why this lands: you protected the client from a public failure, found the real need behind the request, and offered a concrete alternative with a date. Asking "what does the board need to decide?" is the single most useful question in this whole page.
Go deeper: work backward from the outcome · managing the pull to over-build · pilot to scale
4 · The bug they reported is back intermediate
A repeat bug is worse than a new one, because it's about trust, not software. The client isn't upset about the refund policy; they're upset that "fixed" didn't mean fixed. The interviewer wants to see whether you get defensive, and whether you understand that the real fix now has two parts: the bug itself, and the process that let it come back.
- Find the root cause, not the trigger. For example: the re-upload added the old policy again because there's no version filter.
- Fix the cause (deduplicate by document version, filter to current documents only).
- Add the original question and today's to the regression set, so they run on every re-ingestion and deploy.
- Send a short written note: cause, fix, new safeguard, and how they'll be told if it ever fails.
- Check whether the same gap could affect any other documents, and say so in the note.
Why this lands: you owned the broken promise without grovelling, separated "fix the bug" from "fix the process", and gave the client something they can check. Clients forgive bugs; they don't forgive the same bug twice without a reason.
Go deeper: the regression gate · evals for a support assistant · owning a failure
5 · "Why does the same question get different answers?" advanced
This tests whether you can explain a real technical property honestly to someone who doesn't care about the technology. Language models generate text word by word with some built-in variation, so wording can change between runs — that's true, and pretending otherwise will backfire when they see it again. But the CFO's actual worry isn't wording; it's whether the facts change. A strong reply separates the two, explains the cause in one plain sentence, and says what you'll put in place for the cases where consistency matters.
- Get both answers and compare the facts, not the wording.
- Run the same question 20 times and measure how often the facts differ. Report that rate, not an opinion.
- For high-stakes answers, use structured output for the key figures and require a citation for each one.
- Where the answer is a fixed fact (a rate, a limit), look it up from a system of record rather than generating it.
- Send the CFO a one-page summary: what varies, what doesn't, the measured rate, and the controls in place.
Why this lands: you didn't hide the non-determinism, you translated it into a business comparison, and you reframed the problem from "wording" to "facts" — which is what the CFO actually cares about. Measuring a rate instead of arguing from one example is the same instinct that makes good engineers good.
Go deeper: determinism, honestly · the risk register · deterministic checks
6 · IT won't give you the credentials advanced
Security teams blocking access is one of the most common reasons FDE projects stall, and they're usually not being unreasonable. They're accountable if something leaks, and you're asking them to take a risk on a vendor they barely know. The interviewer wants to see whether you treat security as an obstacle to get around, or as a stakeholder whose concerns you can actually address. Going over their head to the sponsor is the fastest way to make a permanent enemy.
- Write down their specific concerns and answer each one in writing.
- Reduce the request to the minimum: read-only, specific fields, a dedicated service account, with logging they can see.
- Provide the vendor security pack: data flow diagram, retention, the model provider's data-use terms, certifications.
- Propose a phased start: masked or synthetic data first, real data after they've reviewed the results.
- Tell your sponsor the honest timeline impact, without asking them to override security.
Why this lands: you treated the security lead as a partner, asked what the actual risk was, cut your request down to least privilege, and offered a way to prove safety before asking for trust. That's how you get access next month instead of never.
Go deeper: vendor security review · PII and the DLP boundary · data residency
7 · "Your AI doesn't work" professional
The trap is to start convincing. A CTO who's been hearing complaints doesn't want a sales pitch; they want to know you understand what's going wrong. "Doesn't work" is almost never literally true — usually it's working well for some tasks and badly for others, and nobody has the data to tell which. The interviewer wants to see you get specific, bring evidence, and be willing to accept the CTO's decision if the evidence goes against you.
- Get the specific complaints and the conversation logs from those three teams.
- Categorise the failures: wrong answers, out-of-scope questions, slowness, usability.
- Measure usage and quality per team. Often one team's use case is a poor fit while others are going well.
- Prepare an honest one-page review: what works (with evidence), what doesn't, and a recommendation.
- If one use case is a bad fit, recommend narrowing the scope. Saying "this part isn't working" earns more trust than defending everything.
Why this lands: you took the complaint seriously, asked for specifics, proposed a short fact-finding window with a dated review, and openly accepted that "stop" was a possible outcome. Being willing to recommend stopping is exactly what makes a CTO trust your recommendation to continue.
Go deeper: why AI rollouts fail · rollout metrics · when the metrics say no
8 · Explain RAG to the Chief Legal Officer in 60 seconds professional
This tests whether you can explain the system at the right level for someone whose job is risk. The CLO doesn't need vectors or embeddings. They need to know where the information comes from, whether the system can make things up, whether they can check its answers, and who can see what. A strong explanation uses one familiar comparison, then answers those risk questions before they're asked.
- Offer a short live demo where the CLO asks a question and clicks the citation to check the source.
- Send a one-page summary: data flow, retention, access controls, and the evaluation results.
- Ask what would make them comfortable approving: an internal-only pilot, a human review step, or a specific test set from their team.
- Make sure access rules match their document permissions before any real use.
Why this lands: one familiar comparison, then straight to the questions a lawyer cares about — source, checkability, confidentiality, error, access — including an honest admission that it can misread. Saying the limitation before they ask makes everything else you said more believable.
Go deeper: why RAG exists · the RAG loop · talking at the right altitude · tenancy isolation
9 · "Can it be 100% accurate?" tech-lead
This is the tech-lead question because the honest answer is "no", and saying no well is a senior skill. No AI system — and no human team — is 100% accurate, and promising it is the quickest way to lose credibility the first time it's wrong. But a bare "no" leaves an exposed executive with nothing. The strong reply reframes the question from "is it perfect?" to "is it safe and better than today?", and offers a design where errors are caught before they cause harm.
- Measure the current human baseline on a sample of real questions, so there's an honest comparison.
- Agree acceptance criteria with the sponsor in writing: accuracy target, categories that always go to a human, and response times.
- Design human review where errors are expensive, and confidence-based handover where the system is unsure.
- Roll out in stages, with a weekly quality report and an agreed rollback trigger.
- Make sure the sponsor can explain all this to their own leadership, so their name is protected by a process, not a promise.
Why this lands: you refused the impossible promise without refusing the client, compared against the real alternative (people) instead of perfection, and offered measurable safeguards and an agreed bar. The sponsor walks away with something they can defend to their boss — which is what "it's my name on the line" really meant.
Go deeper: human-in-the-loop · why you can't ship without evals · the guardrail layer · the risk register
🪜 Practice ladder beginner → industry
- Beginner: say the §2 failed-demo reply out loud three times, using the Acknowledge → Own → Explain → Commit shape, until it takes under 30 seconds.
- Easy: write your own 60-second plain-English explanation of a system you've built, for a non-technical executive. Cut every term they'd need to look up.
- Core: with a partner playing the client, run §3 (the scope squeeze). They should refuse your first offer; practise finding the real need behind the deadline.
- Stretch: run §6 (the security lead) and have your partner raise two concerns you didn't prepare for. Practise asking questions instead of defending.
- Hard: run §7 (the CTO) with your partner interrupting and getting angrier. Keep your voice calm and still end on a dated next step.
- Industry: record yourself doing §9 (100% accuracy), play it back, and count how many times you used jargon or made a promise you couldn't keep.
✓ Checkpoint — you can move on when you can…
- Answer any difficult client moment with Acknowledge → Own → Explain → Commit, without notes.
- Explain non-determinism and RAG to executives in plain language, separating wording from facts.
- Turn a scope or access dispute into a smaller, agreed next step instead of a yes or a no.
- Refuse an impossible promise while still giving the client something they can defend.
- End every reply on a specific action with a date.
Knowledge check check yourself
In an FDE client role-play, your live demo gives a wrong answer in front of the client's leadership. What should your reply include, and what should it avoid?
Show answer
A client executive asks you to guarantee the AI system will be 100% accurate. How should an FDE answer?