The FDE Customer Simulation Round: A Role-Play Playbook

The FDE customer simulation round is a live role-play in which interviewers act as your customer's stakeholders and hand you a deliberately vague problem. You succeed by clarifying the objective before you propose anything, scoping the solution out loud with structured logic, communicating tradeoffs in language a non-technical buyer understands, and staying composed when the panel pushes back or changes the requirements halfway through. The single most common failure is jumping to a solution before you have confirmed what success means to the customer. This playbook covers the discovery questions to lead with, a structure that keeps you organized under pressure, and how to handle the curveballs the panel is holding in reserve.

Why this round exists

A forward deployed engineer spends most of the job in rooms exactly like this one. A customer describes a problem they only half understand, in their own vocabulary, with constraints they will not volunteer until you ask. The simulation compresses that into 30 to 45 minutes. The panel usually splits into two characters: a business buyer who cares about outcomes and timelines, and a technical counterpart who will poke holes in your design. They are not testing whether you can build the thing. They are testing whether you can be trusted alone in front of a customer who is paying seven figures.

For the wider picture of where this fits, see the full FDE interview process. This is the round where the skills the role actually tests collide: engineering judgment and customer empathy in the same breath.

The mistake that sinks most candidates

Strong engineers fail this round by solving too fast. The customer says "we want to use AI to handle support tickets" and within ten seconds the candidate is describing an embedding pipeline. It feels productive. It is the wrong move, and the panel notes it immediately.

You have not learned what "handle" means. Deflect the easy ones to a human? Draft replies for an agent to approve? Auto-close low-risk tickets? Each implies a different system, a different risk profile, and a different definition of done. By architecting before clarifying, you signal that you would walk into a customer site and build the wrong thing confidently. That is the exact failure mode the role is built to prevent.

The fix is a hard rule: no solution language until you can state the objective in one sentence the customer would agree with.

Step one: discovery before design

Open with discovery, and make it visibly deliberate. A few questions that consistently earn signal:

• Objective. "If this works perfectly six months from now, what is different for your team?" This forces a concrete outcome instead of a technology wish.
• Current state. "Walk me through how this is handled today, including the workaround nobody likes." The workaround tells you where the real pain is.
• Definition of success. "How would you measure whether this is working? What number moves?" If they cannot answer, that is itself a finding you should name.
• Constraints. "Where does the data live, who is allowed to see it, and is there a deadline or budget I should design around?" Surfaces the data residency and compliance walls early.
• Stakeholders. "Who else has to be happy with this besides you?" The skeptical engineer on the panel is often that hidden stakeholder made literal.

Ask three or four of these, not fifteen. The skill is selecting the questions that most change your design, then stopping. An interrogation is as bad as a premature solution.

Step two: structure the thinking out loud

Once you have the objective, narrate a structure before you fill it. Something like: "Here is how I want to work this. State the goal back to you, list the constraints I heard, sketch two approaches at a high level, then go deep on the one that fits your constraints best." This does two jobs. It gives the panel a map so they can follow you, and it buys you a few seconds of thinking time that look like leadership rather than hesitation.

When you propose, anchor every choice to something the customer said. "You told me the team is stretched and the data cannot leave your network, so I am leaning toward a managed retrieval setup inside your VPC rather than a custom system you would have to maintain." That sentence is worth more than a perfect architecture, because it proves you were listening and you can justify a tradeoff in their terms.

Step three: communicate tradeoffs like a buyer hears them

A tradeoff stated in engineering jargon is a tradeoff the buyer cannot weigh. Translate. Instead of "we could add a reranker to lift precision," try "we can make the answers more accurate, but it adds a bit of latency and some cost per query, so it is worth it if a wrong answer is expensive for you." Name the lever, the price, and the condition under which you would pull it. That last part, the condition, is what separates a consultant from an order-taker. Practicing this framing on real RAG and agent design questions makes it automatic.

Step four: handle the pushback they planted

The panel will test your composure on purpose. Common curveballs and the move for each:

• The skeptic attacks your design. "That will never work with our legacy system." Do not defend reflexively. "Tell me more about the system, because you clearly know a constraint I do not." Curiosity beats ego, and it usually surfaces the real requirement.
• The requirements change mid-stream. "Actually, it also needs to work offline." Acknowledge the shift, restate the new constraint, and show how it updates your design. Visible adaptability is the point of the test.
• They ask for a guarantee you cannot give. "Will it be 100 percent accurate?" Be honest. "No system is, so let me propose how we measure accuracy and set a threshold you are comfortable with." That is where an evaluation plan earns its keep.

How to practice

Drill the discovery questions until they are reflexive, then do mocks where a partner plays a difficult stakeholder who withholds information and changes their mind. Record yourself answering a vague prompt cold and watch for the moment you start solving too early. Build vocabulary on real behavioral and customer-facing questions, and pressure-test your scoping instinct against the must-know set.

The one-line version

Clarify the objective before you design, structure your thinking out loud, price every tradeoff in the customer's language, and treat pushback as a gift that reveals the real constraint. Do that and the simulation stops being an ambush and starts being a normal day on the job.