The FDE take-home assignment: what to expect and how it's scored

An FDE take-home is a small, breadth-first product build — nominally 4–6 hours — that touches every horizontal in brief: wiring up an API, handling messy data, often an AI/LLM step, and getting the whole thing running end-to-end. Nobody expects depth in every layer. What's scored is whether you can carry a small product across the whole stack without getting stuck in one corner — because that's literally the job. And the data they give you usually has something wrong with it. Often deliberately.

This is the deep-dive on Stage 1 of the loop mapped in FDE interview questions & how to prepare.

What the brief looks like

A representative shape (details vary, the shape doesn't): "Here's an API (or a data dump with quirks). Pull the data, transform it / answer questions over it, expose the result — a small CLI, endpoint, or report. Include instructions to run it." At AI companies there's frequently an LLM step: summarize the records, answer natural-language questions over them, classify the messy field.

Read the brief twice and write down two things before touching code: what is the demo moment — the one flow that must work? And what's wrong with the data they gave you? There's always something.

Time-box it like a field deployment

For a nominal 4–6 hour take-home:

1. First 30 minutes — read and scope. Demo moment, explicit out-of-scope, data quirks.
2. Hours 1–3 — the thinnest end-to-end slice. Input → processing → output, working ugly, as early as possible. Everything after this is improvement, not risk.
3. Hours 3–5 — harden the demo path only. The malformed rows, the empty responses, the obvious failures on the main flow. Resist improving corners nobody will run.
4. The last hour — the README and walkthrough. Scored as heavily as the code. Budget for it like a deliverable, because it is one.

What reviewers actually check, in order

1. Does it run, from the README, first try? A surprising share of submissions die here.
2. Does the core flow work on their data — including the messy parts?
3. Is the code readable enough to extend? Not elegant. Readable.
4. Does the README show judgment — scoped assumptions, honest trade-offs?
5. Only then: is anything impressive?

Notice what's not on the list: framework choice, folder-structure ideology, test-coverage percentage. Working-and-explained beats sophisticated-and-fragile, every single time.

The README is half the submission

Reviewers read the README before the code — it's your opening statement. The structure that works:

• What this does — two sentences, plain language, demo moment first.
• How to run it — exact commands, tested from a clean checkout. A README that doesn't run is a rejection in disguise.
• What I'd do with more time — 3–5 specific items ("swap the in-memory store for Postgres and add retry on the ingest call"), never generic ("add tests").
• Assumptions & trade-offs — every corner you cut, named, with the reason.
• The hacky part — point at it yourself, with the proper fix described.

Naming your own hack is counterintuitive and powerful: it converts a weakness into a judgment signal. Reviewers will find it anyway — the only question is whether you found it first.

The follow-up questions

The take-home almost always comes with a live walkthrough. The probes are predictable, and they're worth rehearsing out loud:

• "Walk me through it. What's the hackiest part?" — Tour the flow end-to-end, then volunteer the hack before being asked.
• "What breaks first if the input is 10× bigger and 10× messier?" — Name the specific choke point and the cheap hardening you'd do first.
• "Why this stack? Defend it — now argue against it." — "Fastest path to working for this scope" is a great answer if you can also name its limits.
• "What would you cut with half the time?" — Cut robustness on unlikely paths before touching the core flow, and say what you'd tell the stakeholder.

The four traps

• The polish trap: spending hour 4 on a UI for a data-pipeline brief. Match effort to what the brief scores.
• The scope trap: building the configurable general solution. They asked for a bridge over this river.
• The silence trap: submitting code with no narrative. The README is the handover test.
• The perfection stall: missing the deadline to gold-plate. Shipped on time and 80% good is the winning move — it's literally the job.

One more thing worth knowing: a practice take-home doubles as your proof artifact. A small working project against a public API — with the README above — is the strongest attachment a candidate without direct FDE experience can put in front of a hiring team. And the walkthrough conversation blends straight into system design probes, so prep them together.