Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path →
The take-home,
and how to defend it
Take-homes are the centre of gravity in modern FDE loops — a multi-hour build at OpenAI, an agent from scratch at Sierra, an AI-assisted build at Distyl. All three are graded the same way: not on how much you produced, but on whether you scoped it well and can defend every decision. Here is the method, plus a practice spec and the rubric.
What graders are actually scoring
A take-home in an FDE loop is a proxy for an engagement. The grader is asking: given an ambiguous brief and a fixed time budget, what did this person choose to build, what did they refuse to build, how do they know it works, and can they explain themselves to a customer?
Volume is not on that list. A complete narrow build with tests and a clear write-up beats a sprawling one every time.
| Signal | Weight | How it is read |
|---|---|---|
| Scope judgement | Highest | Did you cut the right things and say so? An explicit “not building X because Y” list is the single strongest artefact you can include. |
| Verification | High | Tests, an eval, or a reproducible check. “It works” with no evidence is the weakest possible claim in a deployment role. |
| Failure handling | High | Timeouts, rate limits, malformed input, partial failure. This is the enterprise reality the role exists for. |
| Defensibility | High | Every non-obvious decision has a one-sentence reason. This is what the walkthrough round grades. |
| Operability | Medium | Can someone else run it? A two-paragraph runbook is rare and reads as senior. |
| Code quality | Medium | Readable and consistent. Nobody is scoring cleverness. |
| Feature count | Lowest | Frequently negative. Breadth without depth reads as poor judgement. |
The method
Five phases with fixed time budgets. The budgets matter more than the technique — most failures are time allocation failures.
Scope, before any code
Write a short memo first: what problem this solves, who the user is, what success means, what you will build, what you will explicitly not build, and the assumptions you are making. Half a page. It becomes the top of your README and the spine of your defence.
If the brief is ambiguous, that is deliberate. Resolve the ambiguity in writing rather than by guessing silently.
Skeleton the whole path
End to end, with stubs: input, processing, output, error path. Get something running in the first hour even if every step is fake. This guarantees you ship something complete when time runs short — and time always runs short.
Build the one real path
Make the narrow path genuinely work. Handle the ugly cases as you go rather than at the end: timeouts, rate limits, malformed rows, partial failures, retries that must not duplicate. Resist every impulse toward a second feature.
Prove it
Tests for the properties that must hold, or an eval if the output is fuzzy. Then deliberately break it: kill the network, feed it garbage, send the same request twice. Fix what breaks, or document it as known.
This is the phase people cut when they run late. It is the phase with the highest score-per-minute.
Write up and rehearse
README: the scope memo, how to run it, three trade-offs with rejected alternatives, known limitations, and what you would do with two more days. Then rehearse a two-minute verbal overview — problem, scope, approach, evidence — because that is how the defence opens.
“What I would do with two more days” is the cheapest high-value paragraph in the whole submission. It converts every gap from an oversight into a stated trade-off, and it gives the interviewer an easy, productive opening question.
A practice spec — five hours, realistic
Deliberately ambiguous, in the shape real briefs take. Time-box it, then score yourself with the rubric below.
A mid-size logistics company receives around 400 support emails a day. Today an ops coordinator reads each one, decides which of six categories it belongs to, extracts the shipment reference if there is one, and assigns a priority. They want this automated. They have given you a file of 300 historical emails with the labels their team assigned, and access to an internal shipments API that can look up a reference and return the shipment’s status.
Deliver: something they could run tomorrow, plus your reasoning. Five hours.
Everything that makes this a genuine FDE test is in the ambiguity:
The traps
- The 300 labels are inconsistent — the same email type appears under two categories. Do you check?
- “Priority” is undefined. Do you invent a definition, or ask and state an assumption?
- The shipments API will time out sometimes. Does your pipeline lose the email?
- Some emails have no reference. Is that an error or a normal case?
- Nobody said what accuracy is good enough. Can you propose a threshold and justify it?
What a strong submission looks like
- Scope memo that names the label inconsistency and measures it.
- One complete path: email in, category and reference out, errors handled.
- A held-out eval set with a stated metric and a stated target.
- Graceful degradation when the API is unavailable — queue, do not drop.
- An explicit list of what was not built: no interface, no retraining loop, no priority model.
- A runbook paragraph and a “two more days” section.
Measuring the label inconsistency before building anything. Two coordinators labelled the same email differently; that ceiling determines what accuracy is even achievable, and it turns “how accurate is it?” into a conversation you control. This is the negotiated-eval skill, and it is the most-cited hard skill in frontier-lab FDE job descriptions.10 The method →
Self-scoring rubric
Thirty points. Score honestly; anything under 20 would not advance in a competitive loop.
| Criterion | 0 | 2 | 4–5 |
|---|---|---|---|
| Scope memo | None | Describes what was built | Also states what was not built, and why |
| Completeness of one path | Nothing runs end to end | Happy path only | Errors, retries and degradation handled |
| Verification | None | A few tests | Tests plus an eval with a stated metric and target |
| Ambiguity handling | Guessed silently | Assumptions listed | Assumptions listed and measured where measurable |
| Operability | No instructions | How to run it | Runbook: what breaks first, what to monitor |
| Defensibility | Cannot explain choices | Can explain most | Three trade-offs with rejected alternatives, written down |
Record the walkthrough. Watch it once.
Two minutes of overview, then decision by decision. Almost everyone talks about implementation when the grader wants trade-offs. Watching yourself once fixes it permanently.
The picture: five hours to scale, and what each phase earns
Cost and trade-offs: where a minute is worth the most
Each row is a decision you make during the five hours. Time is what it costs from the 300-minute budget, Space is the rubric points at stake (out of 30), and Why is the reasoning a grader will look for in your defence.
| Case | Time | Space | Why |
|---|---|---|---|
| Write the scope memo first | 30 min | Scope memo row: 0 or 2 → 4–5. It also sets up the ambiguity and defensibility rows | It becomes the top of the README and the first two minutes of the defence. It is written once and used three times. |
| Skeleton the whole path before building any of it | 45 min, all stubs | Protects the one-path row from 0 (“nothing runs end to end”) | If hour five goes badly you still hand in something that runs end to end. Without the skeleton, a late bug can leave you with nothing that runs. |
| Measure the label inconsistency | Part of the 30-min scope phase | Ambiguity row: “assumptions listed” (2) → “measured” (4–5) | Disagreement between the coordinators caps the accuracy you can reach. Measure it and you set the target instead of being judged against 100%. |
| Queue, don’t drop, on API timeout | Minutes inside the build phase | One-path row: happy path (2) → degradation handled (4–5) | An email lost on a timeout is a lost customer ticket. “Queue, do not drop” is in the strong-submission list for a reason. |
| Write trade-offs down while building | Seconds per decision | Defensibility row: “can explain most” (2) → three written trade-offs (4–5) | You will not remember at the defence why you chose SQLite over a queue service. A one-line note at the moment you decide is the cheapest point on the rubric. |
| A second feature (priority model, UI) | Comes out of the 135 or the 60 | No rubric row. Feature count is weighted lowest and is often negative | It spends time that one of the scored phases needed. List it under “two more days” instead. |
| Cut the prove-it phase when late | Saves up to 60 min | Verification row: up to 5 → 0–2 | This is the cut people make and the most expensive one. If the build overruns by 45 minutes, proof shrinks to 15. Cut scope instead. |
| A two-paragraph runbook | About 10 of the write-up’s 30 min | Operability row: “how to run it” (2) → 4–5 | Rarely included, and it reads as senior: what breaks first, what to monitor. |
| Go well over the five hours | +1 hour or more | Nothing gained, and it can cost judgement points | Over-running is read as a scope failure, which is the main thing being tested. |
Read the Space column and the plan writes itself. Nearly every point on the rubric depends on judgement written down, not on code volume. A narrow build with a memo, a measured ceiling, a queue, an eval and a runbook can score well over 20. The same five hours spent on three features with none of those can score under 10. Run the overrun case once to feel it: a build that takes 180 minutes instead of 135 leaves 15 for proof, not 60. That is just enough to run the happy path once, and not enough to break anything on purpose.
Check yourself
The practice spec above, with a few complications added. Answer before you open each one.
It is hour four of five. The one path works end to end, there are no tests, and a priority model is half built. What do you do with the last 60 minutes?
Stop the priority model. Spend the time proving the path: a held-out eval with a stated metric and target, then break it on purpose (kill the API, send garbage, send the same email twice). Move the priority model to “two more days” with one sentence on why it waited. Verification is worth up to 5 points. A half-built feature is worth nothing.
You find 40 pairs of near-identical emails in the 300 labels. In 10 pairs the two labels differ. What does that do to your accuracy target?
The coordinators agree on 30 of 40, or 75%, on emails that should get the same label. A model scored against those labels can’t be expected to reach 95%, because the labels themselves disagree a quarter of the time. Put the number in the scope memo and propose a target relative to it. Or merge the two categories they confuse and say so. Either way, you have turned the accuracy question into one you can answer.
Say the shipments API times out on 1 call in 20. At 400 emails a day, with a lookup on each, what does a pipeline that drops on error lose, and what should it do instead?
400 ÷ 20 = 20 emails a day, lost without anyone noticing. Instead, classify the email anyway, put the lookup in a retry queue, and mark the ticket “reference pending”. Make the retry idempotent, keyed on the message id, so a retry never creates a second ticket. That is graceful degradation, and it moves the one-path row to the top band.
In the defence the interviewer asks, “Why didn’t you build an interface?” What is the strongest answer?
Point to the not-building list in your scope memo: the team asked for automation, the coordinator already works in email, and an interface would have come out of the proof phase. Then say what you would build with two more days. You chose not to build it and wrote that down, so it counts as judgement, not as something you missed. This is the defensibility row. The weak answer is “I ran out of time”, which says the cut was an accident. It may be true, but it hands the grader the opposite of the signal they are scoring.
Quick answers
How do you pass an FDE take-home?
Scope it in writing before coding, skeleton the whole path early so you always have something complete, build one narrow path that genuinely works with failures handled, spend a fifth of your time proving it works, and write up three trade-offs with the alternatives you rejected. Graders score scope judgement, verification and defensibility far above feature count.
How long should an interview take-home take?
Respect the stated budget — commonly around five hours for frontier-lab FDE roles. Going well over is not rewarded and often signals poor scope judgement. If you run short on time, cut features rather than verification: a complete narrow build with tests scores higher than a broad one without them.
What should be in a take-home README?
The scope memo (problem, user, success definition, what you built, what you deliberately did not build, assumptions), how to run it, three trade-offs with rejected alternatives, known limitations, a short runbook covering what breaks first and what to monitor, and a “what I would do with two more days” section that converts gaps into stated trade-offs.
How do I prepare for a take-home defence or walkthrough?
Write your trade-offs down while building, because you will not remember them afterwards. Deliberately break your own code before the call so you know how it fails. Prepare a two-minute overview covering problem, scope, approach and evidence, and one honest weakness with the fix you would apply. Never explain a decision by saying an AI tool made it — the artefact is yours.
Sources
Every number on this page traces to one of these. Where a figure is self-reported or crowd-sourced rather than first-party, it is labelled inline.
Cited on this page
- Anthropic — Forward Deployed Engineer, Applied AI (JD) — 40/30/30 split; MCP servers, sub-agents and agent skills as deliverables. jobs.menlovc.com/companies/anthropic/jobs/69674588-forward-deployed-engineer-applied-ai
- Gaijineer — OpenAI Forward Deployed Engineer interview process — named first-hand candidate account. gaijineer.co/openai-forward-deployed-engineer-interview-process
- Gaijineer — Sierra software engineer (agent) interview experience — named first-hand candidate account. gaijineer.co/sierra-software-engineer-agent-interview-experience
- Distyl AI — “Interviewing with AI at Distyl” (first-party) — AI-assisted take-home and the anti-patterns they reject. distyl.ai/blog/frontier/interviewing-with-ai-at-distyl
Explore the topic
See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.
More Handbooks
- The Agentic AI Interview HandbookTwenty topics every senior AI engineer should be able to reason about live — from eval pipelines to reliability patterns for generative systems.Read →
- The Senior AI Engineer Interview Handbook60 questions across architecture, production incidents, agentic systems, RAG, evals, cost, safety, and leadership — what staff-level AI interviewers actually probe for.Read →
- 50 Angular Interview QuestionsA visual handbook covering components, change detection, RxJS, signals, routing, forms, performance, and testing — what interviewers actually probe for in senior Angular roles.Read →
- 50 Python Interview QuestionsFundamentals to advanced: data structures, OOP, iterators & generators, the GIL, asyncio, memory, testing, and the standard library — a visual walk through everything a Python interview touches.Read →
- 51 LLM Evals Interview QuestionsGolden sets, LLM-as-judge, regression testing, offline vs online evals, RAG evals, agent evals, red-teaming, and observability — demystified for interviews and production.Read →
- The Agent Evaluations HandbookA self-contained handbook on evaluating AI agents — theory, interactive widgets, and practical guidance. Trajectory evals, tool-use scoring, LLM-as-judge, observability, and reliability for PMs, engineers, and founders.Read →