Practise the FDE customer simulation round in 60 minutes

In the customer simulation round, strong FDE candidates spend the first ten minutes only asking questions. The reason is that the round scores exactly one thing: whether you find the real problem before you start building. And customers rarely reveal their real constraints in the first conversation.

Interviewers also make it hard on purpose. In Cognition’s case study round, someone plays a non-technical or difficult customer to see how you handle a barrage of questions.

The good news is that the skill can be practised. All it takes is a friend willing to play an evasive stakeholder who refuses to hand over a clear spec. Below is a complete practice session you can run tonight.

What does the 60-minute session involve?

The session splits into 10 minutes of preparation, a 45-minute call and 5 minutes of scoring. These timings are set for practice, not taken from any particular company’s interview round.

You need a friend to play the customer, a countdown timer, a blank text file for notes and, if possible, a recording app. The role-player reads the role card from step 1; you must not see it.

Step 1: Write the role card and hide the constraints in it

The whole session depends on the role card. The example below is hypothetical; swap in an industry you know:

ROLE: Head of operations, logistics company (hypothetical)
Opening line: "We want to use AI for our support tickets."

Hidden constraints (reveal only when asked the right question):
- Customer data must not leave internal infrastructure
- The support team has 6 people, none of whom can code
- There is a demo for the board in 4 weeks
- Right now people copy urgent tickets by hand into a shared Excel file

Scope changes (the role-player raises these unprompted):
- Minute 20: "Actually, the boss wants it to reply to customers on its own."
- Minute 35: "Can we add English and Japanese?"

The two scope changes are planted deliberately. In a real round, the interviewer may play a difficult stakeholder who keeps moving the goalposts, and this role card recreates exactly that pressure.

Check: the role-player understands that each constraint is revealed only when asked about directly, never volunteered.

Step 2: Draft questions during prep, ask them in the first ten minutes

During the 10 minutes of preparation, draft groups of questions in the text file. The two most worth keeping come from practitioners. FDE Academy advises asking what a “win” looks like for the customer this month. Educative argues that the workaround is often the clearest signal of where the real pain lies.

USERS:       Who uses this every day? How do they do it today?
WIN:         What would have to happen this month for you to call it a win?
WORKAROUND:  When the current system breaks, how do people cope?
DATA:        Where do the tickets live? Can they be taken outside?
PEOPLE:      Who runs it after the deployment team leaves?
DEADLINES:   Are there any fixed dates that cannot move?

When the call starts, the first ten minutes are for questions only. Do not read them out in order like a survey. Let the customer’s answers lead to the next question, and glance at the file only to see which groups you have missed.

Check: by the end of minute 10, how many of the four hidden constraints have you uncovered? If fewer than two, the session has shown you exactly what to practise.

Step 3: State the constraints aloud

Uncovering the constraints is only half the job. Scaler advises stating constraints aloud, even when the interviewer has not raised them, because the assessor cannot read what stays in your head.

One sentence is enough: “Before I propose anything, let me repeat three conditions: the data stays in internal infrastructure, the operators can’t code, and there is a demo in 4 weeks. If any of those is wrong, please correct me.” The sentence shows you have grasped the shape of the problem and invites the customer to correct you before you build the wrong thing.

Check: did you repeat the constraints before you said the word “architecture”?

Step 4: Propose the smallest version that still delivers value

According to techinterview, strong candidates propose the smallest version that still creates value, not the most complete system they can imagine. Scaler makes the same point another way: offer a proof-of-concept, not a full architecture.

For the role card above, the smallest version could be a system that classifies incoming tickets and suggests draft replies, which staff approve before sending, all running in internal infrastructure. It replaces the hand-copied Excel file, satisfies all three constraints and still allows a real demo in 4 weeks.

Check: you can describe the proposal in one sentence and name one number you will measure on demo day.

Step 5: When the customer keeps changing the request

At minute 20 the “customer” will demand that the system reply on its own, and this is where many people nod along. FDE Academy argues that “Yes, and here is the impact on the timeline” is stronger than an unconditional nod. New FDEs have to learn to scope a request and set it against what has already been committed.

Applied to the example: “Automatic replies are possible, but they need an extra round of quality evaluation before they reach real customers. If we do that now, nothing will be working by the demo in 4 weeks. So I suggest keeping the human-approved version for the demo and moving automatic replies to phase two.”

PostHog’s FDE handbook draws an even sharper line: work that doubles in size is a new quote, not a silent extension. In the practice session you need not mention quotes, but keep the principle: a bigger request has to be renegotiated openly.

Saying no does not mean clinging to the original plan. If the change at minute 35 is reasonable, for instance because most tickets already arrive in English, change the plan and explain why.

Check: after each change, did you set the new request against the agreed commitment and say clearly what has to be traded off?

Step 6: Lock scope with a short summary

Around minute 45, close the call with the agreed scope. PostHog describes how its FDE team works: write the scope as a short summary and send it to the customer for confirmation before committing. In the practice session, read these three lines aloud:

AGREED:        classification + draft reply suggestions, staff approve before sending
CONSTRAINTS:   data stays in internal infrastructure; operators don't code; demo in 4 weeks
LATER PHASE:   automatic customer replies; more languages (if not in the first version)

Check: does the role-player agree with all three lines without changing anything?

Step 7: Five minutes of scoring

Let the role-player score you; do not score yourself. If you have a recording, listen to it once more afterwards.

Criterion	Check question
Structure	At which minute did you first propose a solution?
Constraints	How many of the four constraints did you uncover, and did you state them aloud?
Scope	Could the proposal be put in one sentence?
Pushback	Each time the customer changed the request, did you state the impact or just nod?
Close	Did the role-player confirm the final summary?

The three most common mistakes

The first is treating the ten minutes of questions as a formality and then proposing what you had already planned. If the customer’s answers changed nothing in your plan, you skipped exactly what the round tests: finding the real problem before building.

The second is saying no with generic reasoning, such as “that’s not a good idea”. A refusal persuades only when it is tied to the timeline or to a constraint the customer has just stated. The third is the opposite: defending the first version to the end, when the interviewer’s barrage of questions is there precisely to see how you handle the next one.

What does this skill look like with a real customer?

This round is not just a test. The scoping advice in step 5 was written by FDE Academy for new FDEs, and locking scope with a summary is how PostHog’s FDE team works every day. Once you are hired, you will use exactly these skills.

Picture a real kickoff: a vague request, constraints that surface only when asked about, a workaround buried in a file no one mentions, and a goal that shifts halfway through. It is just like the practice session, except the consequences are real.

So on your CV, do not just list technologies. Write one line about a scoping decision: what you cut, because of which constraint, and what you delivered on time as a result. That line is also a ready-made story when an interviewer asks about a time you had to say no.

Run this session three times with three different role cards and scoping questions will become a reflex. Then the scope change at minute 20 in a real interview will no longer catch you off guard.