Vibe Engines Learn
FDE interview prep  /  Take-home playbook
Interview Track~12 min readUpdated Jul 2026
Interview Track 07

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.

01

What graders are actually scoring

The scoring reality

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.

SignalWeightHow it is read
Scope judgementHighestDid you cut the right things and say so? An explicit “not building X because Y” list is the single strongest artefact you can include.
VerificationHighTests, an eval, or a reproducible check. “It works” with no evidence is the weakest possible claim in a deployment role.
Failure handlingHighTimeouts, rate limits, malformed input, partial failure. This is the enterprise reality the role exists for.
DefensibilityHighEvery non-obvious decision has a one-sentence reason. This is what the walkthrough round grades.
OperabilityMediumCan someone else run it? A two-paragraph runbook is rare and reads as senior.
Code qualityMediumReadable and consistent. Nobody is scoring cleverness.
Feature countLowestFrequently negative. Breadth without depth reads as poor judgement.
02

The method

Five phases with fixed time budgets. The budgets matter more than the technique — most failures are time allocation failures.

10%

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.

15%

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.

45%

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.

20%

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.

10%

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.

→ The two-more-days section

“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.

03

A practice spec — five hours, realistic

Deliberately ambiguous, in the shape real briefs take. Time-box it, then score yourself with the rubric below.

Brief: “Ticket triage assistant”

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.
→ The move that separates the top decile

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 →

04

Self-scoring rubric

Thirty points. Score honestly; anything under 20 would not advance in a competitive loop.

Criterion024–5
Scope memoNoneDescribes what was builtAlso states what was not built, and why
Completeness of one pathNothing runs end to endHappy path onlyErrors, retries and degradation handled
VerificationNoneA few testsTests plus an eval with a stated metric and target
Ambiguity handlingGuessed silentlyAssumptions listedAssumptions listed and measured where measurable
OperabilityNo instructionsHow to run itRunbook: what breaks first, what to monitor
DefensibilityCannot explain choicesCan explain mostThree trade-offs with rejected alternatives, written down
Then defend it

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.

OpenAI: the defence round Distyl: AI-assisted rules All 9 rounds Evals for client work
Frequently asked

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.

Receipts

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

  1. 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
  2. Gaijineer — OpenAI Forward Deployed Engineer interview process — named first-hand candidate account. gaijineer.co/openai-forward-deployed-engineer-interview-process
  3. Gaijineer — Sierra software engineer (agent) interview experience — named first-hand candidate account. gaijineer.co/sierra-software-engineer-agent-interview-experience
  4. 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
The FDE Take-Home Playbook · the interview track of the FDE course · Vibe Engines · 2026
Finished this one? 0 / 197 Handbooks done

Explore the topic

See this alongside everything else on the same subject — handbooks, system designs, challenges and tools, in one place.

Interview Prep Forward Deployed Engineering

More Handbooks

Explore more from Vibe Engines

Roadmaps →
System Designs →
AI System Designs →
Algorithms →
Labs →
Paper Breakdowns →