Getting Hired

What the loops test, graded

Start with how little is known. No employer publishes its FDE interview loop, and nobody has published pass rates, let alone which rounds predict good engagements. What exists is candidate reports, gathered by prep sites from small, self-selected samples. Every description of a loop in this chapter is T4: anecdote, aggregated. Job posts are better evidence of one narrow thing, what employers ask for, and they are used here only for that.

With that caution, the reports agree on a shape. A coding round is almost always there, and it is a floor: fail it and nothing else counts, pass it and it decides little. The rounds that differ from a software-engineering loop are three. A decomposition round hands over an open problem and watches the candidate turn it into something buildable. A take-home or build has to be defended against a customer's needs, not just run. A project deep dive has the candidate defend each decision in something they built. All three ask the same question in different clothes: why this, for this customer, and how would you know it worked?

As support for this chapter's argument, that is weak. The best-documented loop belongs to the oldest, least typical FDE model; the second rests on two reports and a guide; the third is a blank. The argument survives because it needs no precise loop data: whatever the round is called, an FDE interviewer wants to see the behaviours from the skill map that a CV cannot show, and judgment and product are the domains posts measure worst.

That sets a budget. A rule of thumb, not data: prepare coding until medium problems are routine, with and without an AI assistant, then put the remaining hours into the project in 16.6 and timed decomposition practice. Where a post lists algorithms among its required fundamentals, budget for a standard software-engineering screen too. If a loop is coding and system design and nothing else, believe it: the job is probably AI engineering under the FDE title (16.7).

What the evidence cannot tell you, and where to prep

Three gaps matter: no pass rates for any round, no account of how employers weigh rounds, and no evidence that a dedicated "customer role-play" round is standard anywhere. The one verified OpenAI candidate report labels two rounds "Customer Interaction" without describing a role-play, and the OpenAI guide does not mention one.

That last gap is where an echo is forming. A Chinese article from APPSO, republished by 36Kr under the iFanr (爱范儿) masthead in August 2026, describes a five-round Anthropic FDE loop with a client-simulation round, attributes the loop to a guide posted on Reddit, and attaches a failure rate for the round that it credits only to "an organisation's estimate" (有机构估算) (APPSO via 36Kr, 29 August 2026; T3 relaying an anonymous T4). This book does not repeat the figure. When a pass rate for any FDE round turns up, ask who counted, how many candidates, and where; so far nobody can say.

Company-by-company prep is well served; link to it and grade each resource by its sample:

• Aced (the site formerly called Exponent) has the most detailed loop guides, linked in the box above. Each lists how many candidate experiences sit behind it, and the counts are small: use them for round names and prompts, not rates.
• Paden Gayle's free FDE Handbook (Maven), about ten pages, promises "the four things you have to demonstrate to get hired". It does not name the four on its landing page. It is a practitioner's view (T4), from a founding FDE who, by the page's account, is writing an O'Reilly book on the role (in Early Release, 2 of 12 chapters, due December 2027).

Decomposition is discovery on a clock

Decomposition rounds look like system design with a made-up problem, and candidates who treat them that way lose by drawing boxes in minute three. The round is the first two weeks of an engagement compressed into an hour. Take "improve traffic in NYC". The weak answer designs a sensor pipeline. The strong one asks who the customer is and which number they are paid to move: a transit agency, a delivery fleet and a mayor's office each get a different system.

The method is the one Part II teaches, run aloud. Five moves, in order:

• The lever. Who is asking, what number they report upward, and what "better" means to them. If the interviewer will not say, propose one and state it as an assumption. This is discovery's stated-versus-observed problem.
• The workflow and its data. Who does the work, where the data lives, who owns it, and what you could reach in week one. Say where it will be ugly.
• The first win and the "not now" list. Pick one slice that matters and fits in weeks, and say aloud what you are leaving out. This is scoping, and the "not now" list is the move interviewers most often never hear.
• The number and how you would check it. A baseline, a threshold and a small eval set, built with the people who know the work. Evals covers it; OpenAI's reported system-design question asks for exactly this.
• What breaks, and who runs it after you. The rule that must never be broken, enforced outside the model, and the team that owns the system when you leave.

Only then draw the architecture: the least clever thing that clears the threshold. A rule of thumb for a sixty-minute round, not reported data: the lever and the workflow by minute fifteen, the first win and the number by minute thirty, the architecture in what is left. A candidate who reaches the architecture late with a clear lever, a scoped first win and a number has done what the round is for. One who has a perfect architecture for an unstated problem has shown the AI-engineering half of the job and nothing else.

The deep dive is where judgment is tested

The take-home defence and the deep dive are where customer and judgment behaviour can be seen, because they ask about decisions already made. They probe for what the rubric's L2 and L3 rows name: a number someone agreed, a scope someone pushed against, a piece of bad news and what happened next, a system someone else now runs.

So tell one engagement, and tell it in that order. What was asked for, and what was actually wrong. The number, who agreed it, and the baseline. The thing you said no to, and why it was load-bearing (Judgment Under Pressure has the four commitments worth holding). The moment it fell short, and the plan you gave. Who runs it now. Name a role and a date in every answer, and say what your lead did rather than you; a good interviewer will find the seam.

NDAs make this harder than it sounds. Practise until the story holds without a single proper noun; if it falls apart without the customer's name, it was about the customer, not about you.

Ways in

The shape of the asks says where the doors are, and every door is the same test: evidence that you have owned a problem for someone else. Most roles are mid-level. A minority hire straight from university, typically at the platform companies with a long history of the role. Several employers name former founders, plausibly because a founder has done discovery, scoping and handoff for their own product. And several posts say outright that side projects count as evidence, which is the opening the portfolio project in 16.6 is built for. The gaps each background brings are in the skill map.

China is worth reading separately, because the doors there are labelled differently. The reported posts lean on lateral hires, and the usual stated bar accepts enterprise delivery experience as an alternative to engineering. Same argument, different market: delivery is customer work, which opens the path to implementation and pre-sales engineers and project managers. The evidence is two articles and a handful of posts, a direction rather than a map. As What an FDE Is warns, check the job family: an internship filed under sales support trains for a different job than one under R&D. Pay and the wider market are covered in Where FDEs Work.

One portfolio project, shaped like an engagement

Build one project, not five. Five demos on clean data are Technical L1 five times, and repetition at L1 does not add up to L2. One project shaped like an engagement feeds every round: decomposition gets your stated-versus-observed story, the deep dive a number someone agreed, the behavioural round the thing you said no to.

The non-negotiable part is a real user who is not you. A maintainer, a small clinic, a charity, a friend's business, a team at your current job: someone whose problem it is, who can disagree with your threshold and who will still be running the thing after you stop. Without that person the project has no witness. The stack matters much less. Keep it small enough to finish in four to six weekends (a rule of thumb).

Be precise about what it can prove. Done once, it yields one-off data points, not levels, by the skill map's own rule. Done well, those data points sit at L2 in each domain: Technical L2 if it runs on the user's real data in their environment with an eval set; Customer L2 if the user agreed your stated-versus-observed summary; Product L2 if you send a feedback brief to the maintainers of a tool you used; Judgment L2 if you flagged a risk in writing before it landed. No L3 anywhere, because every L3 needs someone with power who could have refused. Say so in the interview; knowing where your evidence stops is judgment.

PORTFOLIO PROJECT BRIEF                         date: ____________
Project: ______________________  User (not you): __________________
Their role: ___________________  Will run it after: _______________

1. PROBLEM
   As stated by the user: __________________________________________
   As observed (what you watched, how long): _______________________
   The number they care about: _____________________________________
   User agreed the observed version?  YES / NO   date: ___________

2. SCOPE
   First win: ______________________________________________________
   Not now:   ______________________________________________________
   Never (rule enforced outside the model): ________________________
   Success metric: __________________  baseline: ___________________
   Threshold (set by the user): ____________________________________

3. EVAL SET
   Source of cases: ________________   size: ______   held out: ___
   Who labelled: ___________________   agreement between labellers: _
   Failure categories found: _______________________________________

4. THE BUILD
   Where it runs (theirs, not yours): ______________________________
   Acts or proposes?  ACTS / PROPOSES   why: _______________________
   Result vs threshold: ____________   date measured: ______________
   The bad news, if any, and the plan you gave: ____________________

5. HANDOFF README (what the user needs without you)
   How to run / stop it: ___________________________________________
   How to tell it is wrong: ________________________________________
   Who to ask when you are gone: ___________________________________

6. EVIDENCE MAP (skill map, Ch 3; one-offs, not levels)
   Domain      Level shown   Artefact            Witness
   technical   ___________   _________________   _______________
   customer    ___________   _________________   _______________
   product     ___________   _________________   _______________
   judgment    ___________   _________________   _______________
   Cannot show (and why): __________________________________________

The filled version below is a worked example, not a real project: issue triage for a mid-sized open-source library. Its figures are illustrative ranges.

PORTFOLIO PROJECT BRIEF                     date: 6 weekends, done
Project: issue triage, OSS library  User: lead maintainer
Their role: one of 3-5 volunteers   Will run it after: maintainers

1. PROBLEM
   As stated: "we need a bot that answers user questions"
   As observed: read 2 months of issues and sat in on 2 triage
     calls; new issues wait days for a first label, and a large
     share are duplicates or mislabelled bugs vs questions
   The number they care about: time to first triage
   User agreed the observed version?  YES   date: weekend 1

2. SCOPE
   First win: propose a label + likely duplicates on new issues
   Not now:   answering questions; auto-closing; the docs site
   Never: anything mentioning security is routed to a human,
          checked by a keyword rule outside the model
   Success metric: label agreement with maintainers; time to
     first triage   baseline: from 6 months of issue history
   Threshold (set by the user): "as good as a tired maintainer,
     and nothing waits more than a day"

3. EVAL SET
   Source: closed issues with final labels   size: a few hundred
   held out: the most recent month
   Who labelled: 2 maintainers re-labelled a sample of ~50
     to check the history; they agreed on most, not all
   Failure categories: feature requests filed as bugs; vague
     one-line issues; issues in other languages

4. THE BUILD
   Where it runs: the project's own CI, on its own token
   Acts or proposes?  PROPOSES   why: a wrong close drives
     contributors away; a wrong suggestion costs one click
   Result vs threshold: below on labels at first, met after
     two rounds of fixes   date measured: weekend 5
   The bad news: told the maintainer at weekend 3, with the
     three failure categories and a re-measure date

5. HANDOFF README
   How to run / stop it: one workflow file; delete it to stop
   How to tell it is wrong: weekly count of overridden labels
   Who to ask when you are gone: the maintainer, who ran a
     full re-deploy from the README while the author watched

6. EVIDENCE MAP (skill map, Ch 3; one-offs, not levels)
   Domain      Level shown   Artefact            Witness
   technical   L2 (once)     CI workflow, evals  maintainer
   customer    L2 (once)     stated/observed     maintainer
   product     L2 (once)     brief to the label  its author
                             tool's maintainers
   judgment    L2 (once)     security rule,      maintainer
                             written weekend 1
   Cannot show: any L3; nobody with power refused anything,
     and it ran once, for one user

Notice what the example does not contain: a leaderboard score, a novel architecture or a chatbot. Saying no to the requested chatbot is the strongest line in the brief, because it is the week-one move of every engagement. The model behind it is a footnote; the eval engineering is in Evals 101 and eval-set maintenance. Bring the brief, and let the deep dive run through its sections in order.

Interview them back

The sceptics' strongest evidence is about hiring. The disappointed hires in What an FDE Is took jobs that turned out to be services, and found out after joining. Gayle's course makes the same point from the other side: because "the definition is still unsettled", it teaches how to tell the difference "when evaluating a role, a course, or a job posting" (O'Reilly live event page; T4).

So treat the loop as discovery in both directions. The decomposition round shows how the employer frames a customer problem: if the interviewer only wants an architecture, that is what the job will want. The deep dive shows what they probe: if nobody asks who agreed your number, nobody will on the job. Three questions about the loop itself are worth asking the hiring manager, because the answers describe the job. The readings are this book's rules of thumb, not data:

• "Which round most often sinks a strong engineer here, and what did they miss?" "Coding" means a software-engineering bar with travel attached; "they jumped to a solution" means the customer domain is real.
• "Has everyone on this loop been on site with a customer in the last six months?" Interviewers who have not will grade what they know, which is code.
• "What does the take-home rubric reward?" If nobody can say whether a defended scope beats a polished demo, the round is a coding test.

Then ask about the work; the book already has those questions: the stage-by-stage posting checklist, one question per domain in the skill map, and the five questions on the employer's economics in Origins and Economics. Two vague answers are a pattern. What the ladder above the offer looks like, and what the pace costs, is the subject of Levels, Burnout and What Comes Next.