What an FDE interview actually tests

Most candidates prepare for this interview as if it were a software interview with a customer round attached. It is closer to the reverse: a judgement interview with a coding section attached. The coding section is easy to prepare for and rarely decides the outcome.

The three rounds, and what each is for

Build. A scoped task, usually with a deliberately imperfect data source. The grader is not looking at whether it runs. They are looking at what you did when the data was wrong: did you stop, did you ask, did you silently impute. A candidate who ships a working pipeline over clearly broken data has failed the round and will often be told they passed.

Diagnose. A messy verbal situation — a customer, a complaint, a deadline. This round produces the actual signal, because there is no correct answer to hide behind. The interviewer is watching for whether you separate the stated ask from the underlying process, and whether you can name what you would measure.

Persuade. Present something to a non-technical listener and defend it. Usually a readout. The failure mode is explaining the architecture; the pass is explaining what changed for the customer and what did not.

Eleven questions worth rehearsing

These are paraphrases of the categories that recur across public question banks, not a leaked list.

1. A customer says the model is "not accurate enough". What do you ask next? — Who is judging accuracy, against what, on which slice, and what happens downstream when it is wrong.
2. You have one week and three teams asking for things. How do you choose? — Answer with the selection criterion, not the choice. The criterion is usually: which one produces a decision that costs money if it is wrong.
3. The data you were given does not match what production shows. What now? — The pass is saying you stop and reconcile, and that you would rather lose a day than build on the wrong source.
4. How would you decide whether this deployment worked? — Metric, source, window, exclusions, and who arbitrates. Anything less is a mood.
5. The customer's IT sponsor approved it; the business owner did not. What happens in month two? — Nothing. Name this and you have demonstrated the single most useful piece of field knowledge in the interview.
6. Write the acceptance criteria for a document-extraction system. — Should include the error budget on the fields that matter downstream, not a global accuracy number.
7. A feature shipped and nobody uses it. Diagnose in ten minutes. — Not handy, not trusted, or not about the user's actual job. Ask which, with evidence.
8. When would you tell a customer not to buy? — Needs a real answer: when the problem is a process problem, when the data does not exist, when the cost of change exceeds the benefit.
9. What do you do when the model provider changes a model under you? — Version pinning, evaluation set, and a rollback plan. This is now a standard question and a common gap.
10. Hand over this system to someone who will run it without you. — What artefact, what does it contain, how do you know they can.
11. Something in your last project was wrong. What was it? — The only question that reliably separates people who have shipped from people who have read about shipping.

The habit that fails strong candidates

Answering the first question with a technology. "Not accurate enough" → "I'd add a reranker". "Nobody uses it" → "I'd improve the UI". Both are plausible and both skip the step that defines the role: converting a complaint into a testable statement.

A useful discipline for the interview, and for the job: before any technical proposal, say the metric out loud. The claim is that invoice matching takes four minutes; we will know it worked when the median falls below two and the dispute rate does not rise. If you cannot form that sentence, you are not ready to choose the technology, and saying so is a stronger answer than guessing.

The second habit is pretending certainty about numbers you do not have. Interviewers in this role hear invented statistics constantly. "I don't know, here is how I would find out, and here is what it would change" scores higher than a confident wrong figure, every time.

Questions to ask them

The interview runs both ways, and the answers sort employers quickly.

• Who owns the customer relationship — the FDE, a salesperson, or a partner manager?
• What happens to an FDE between deployments? Bench, product work, or bench-and-worry?
• How many deployments did the team run last year, and how many are still in use?
• Who decides when a deployment ends?
• What does the handover artefact look like, and can I see one?

The fourth and fifth are the discriminating ones. A team that cannot answer them is selling pre-sales with a different title, which is the boundary described in is an FDE a pre-sales role. What the capability round is actually grading is laid out in the capability model; the delivery vocabulary those answers rely on is in the five stages.

Red flags, both directions

For the candidate: a process with no customer-facing round, a take-home that is real unpaid client work, or a team where every FDE reports to sales. For the employer: a candidate who can describe the model stack in detail and the customer's process not at all, or one who has never had a number they were accountable for.

Neither side should treat the interview as a filter on knowledge. The knowledge is a commodity and it is on the internet. What is being tested is whether the person, placed in front of a customer with a vague complaint and a deadline, produces a number.

Preparing in a week

Three drills, in order. Take a workflow you know and write its metric definition table — five columns, no prose. Then write the scoping memo for the same workflow, including what you would refuse. Then present both to someone non-technical in eight minutes and see which parts they interrupt.

That is close to the interview, and closer to the job than any list of questions.