The FDE interview: a typical loop
Say what each of the four FDE rounds scores and the one mistake that loses each, and map a company's decomposition, coding screen or take-home onto them.
On this page
Most FDE loops run four rounds in some form: a case, a technical deep-dive, a customer scenario and a behavioural conversation. Companies rename them, merge two, or put a coding screen or a take-home in front, but each variant scores one of four things: a decision reached with numbers, depth on a system you built, an objection held without losing the customer, and a record of owning an outcome. Knowing which round you are in tells you what the interviewer is writing down.
The shape of the loop
The recruiter screen asks two things that matter later: why this role rather than its neighbours, and how much travel you have counted on. The loop is four rounds of 45 to 60 minutes, and the debrief reads the four scores together, so a round you skipped in preparation shows up as the low score everyone discusses.
Round 1: the case
A vague customer problem and 45 minutes: an insurer wants AI on claims, a facilities firm is missing its emergency response times. The round scores whether you separate the ask from the outcome, find where the time actually goes, propose a build with a numbered definition of done, and say what would reverse you.
The clock works as in the system-design framework. About 8 minutes of questions that end in numbers: volume, minutes per step, what was promised. About 7 of sizing: tokens at an assumed 0.75 words per token, the peak hour rather than the average, cost as a multiple of the contracted rate r. About 15 on the first build and its eval, 10 on the plan and its gates, and 5 held back for the interviewer's change of constraint.
The mistake that loses this round is drawing the architecture before locating the minutes. A retrieval pipeline on the whiteboard at minute 5 is an answer to a question nobody has measured. The worked version of this habit is mapping the workflow before the model, and the case-round exercise runs it at interview pace.
Round 2: the technical deep-dive
You choose a system you built; the interviewer takes one part of it to the bottom: the data path, what failed, the eval, the decision you would reverse now. The round scores depth on one component and whether the numbers are yours.
Prepare one deployment to that depth rather than three to a sketch. For the claims pilot the minimum is 1,200 claims a day, about 4,300 input tokens and 160 output tokens per claim, about 6r a day, a peak of 240 claims an hour, a p99 gate of 20 seconds, an agreement gate of 95% on 200 adjudicated cases where two reviewers had agreed on 174 before adjudication, and the reading you reached against that gate. An interviewer who hears those from memory stops checking whether you owned the system and starts asking how you would change it.
The mistake that loses this round is an architecture tour with no numbers in it. If you cannot say the volume, the tail latency and what the eval measured, the interviewer concludes that someone else owned them. The deep-dive exercise is the eval question asked the way a senior engineer asks it.
Round 3: the customer scenario
An interviewer plays a customer with an objection: the CIO who wants it on-premises, the VP who wants a chatbot. The round scores whether you ask for the requirement before answering the request, put the trade-off in the customer's terms with a number they can check, and decline without losing the sponsor or agreeing in the room to something nobody has measured.
The CIO scenario is where the model sits done out loud; the six-week feature request is saying no. The interviewer scores the conversation as much as the answer: whether this customer would want you back on Monday.
The mistake that loses this round is winning the argument. Correcting the CIO's latency intuition in technical detail is accurate and loses the room. The customer-scenario exercise has the arithmetic that lets you agree with the requirement and still change the build.
Round 4: behavioural
Questions about things that happened: a slip, a disagreement with a customer, a request you declined. The round scores specificity (a date, a number, a named role at the customer), the first person where it was your call, when you told the people who needed to know, and what you changed afterwards.
Write two stories in advance, each with a number that moved, a person who decided something because of what you wrote, and the week you disclosed the bad news. The champion who left in week 4 is the shape of a good one.
The mistake that loses this round is a slip story whose disclosure date you never give. The interviewer asks "when did the customer find out?", and the gap between when you knew and when you said is the score. The behavioural exercise puts two answers to that question side by side.
The variants, mapped onto the four
A decomposition round hands you a vague problem to break into inputs, data model, logic and outputs. It is the case round with more weight on the data model, and a customer objection often arrives inside it.
A coding screen is the code half of the deep-dive, usually held before the loop: a small program, correct on its edge cases, written live. Normalising an export or scoring an eval set is the right size, and the solving loop from the DSA course applies unchanged: restate, brute force, find the waste, choose the pattern, test the edges.
A take-home is a case or a build done in advance and then defended. It counts twice: once for the written answer and once for the defence, which is a deep-dive on the thing you just made. Read the rules on tool use first. Anthropic's careers page (opens in a new tab) says its technical interviews use live coding tools and that candidates may look things up, and its guidance on candidates' AI usage (opens in a new tab) says take-homes and live interviews are done without AI assistance unless the company says otherwise. Those pages cover its technical roles generally, not FDE alone, and other companies set their own rules.
A hiring-manager conversation is the behavioural round plus "why this role", and the second half is answered from the role table: the row that separates the FDE from the job you are leaving.
In an interview
What the loop as a whole tests is consistency. The deployment you describe in the deep-dive is the one the behavioural interviewer asks about an hour later, and numbers that differ between rounds read as invented: 1,200 claims a day in the morning and "a couple of thousand" in the afternoon is one story told twice, badly. Give each round what it scores: the case a decision, the deep-dive depth, the scenario a customer who would invite you back, the behavioural a date.
The mistake that loses points is preparing only the round you are already good at. Engineers over-prepare the coding screen and walk into the customer scenario with nothing written down, and a loop is four scores in which one low score is what the debrief spends its time on.
Check yourself
1. A company's published process: recruiter screen, a 60-minute decomposition round, a coding screen, a 48-hour take-home, a hiring-manager conversation. You have 10 hours to prepare. Map it onto the four rounds and allocate the hours.
Decomposition is the case; the coding screen and the take-home's defence are the deep-dive; the take-home's write-up is the case again; the hiring manager is the behavioural. With no customer-scenario round, expect an objection inside the decomposition or the defence. Case 4 hours (four case exercises), deep-dive 3 (two code exercises and the eval defence), behavioural 2 (two stories with dates and numbers), customer scenario 1 (the CIO, once). The case gets most because it is scored twice.
2. At minute 30 of the case you see that your first build cannot reach the promised number. Restart, or adjust?
Adjust, out loud. Say which number it misses and by how much, change one part, and redo the arithmetic: "the panel removes half the 7 search minutes only when it finds the right clause, so 3.5 × 0.8 = 2.8 minutes at the 80% hit rate I assumed, short of the 3.3 needed; at 95% it is 3.3. The build stays and the hit rate becomes a gate at 95%." Restarting spends the last 15 minutes on a second unfinished answer, and the change itself is what the round scores.
3. In the deep-dive the interviewer asks what your system cost per day. You do not remember the contracted rate. What do you say?
The tokens, then the multiple: "about 5.2 million input tokens and 0.19 million output a day, so about 6r at r per million input and 4r output. The rate is in the contract and I would not quote it from memory." That answer shows you owned the arithmetic. A remembered dollar figure is unverifiable and invites the next question, which you cannot answer.
Source: Anthropic, Careers: How we hire (opens in a new tab) and Guidance on candidates' AI usage (opens in a new tab), both read 2026-10-17.