Take-home — what reviewers actually check

A take-home is a coding assignment a company gives you to do on your own time instead of (or on top of) a live interview. The prompt usually says something like "spend about 4 hours building X." The trap is taking that literally and trying to build a complete, polished product. The reviewer — the engineer who grades your submission — does not spend 4 hours reading it. They spend roughly 15 minutes, and in the first 5 they're really just checking a handful of fast signals: can I run this in one command, does the basic case work, are there tests, is the code tidy, and does the git history look sane. So your job is to engineer for that 15-minute skim, not for completeness.

Here's the everyday analogy. Think of it like cooking a dish for a job at a restaurant. You're told "you have 4 hours." A nervous cook tries to make a giant five-course meal and serves five half-cooked, lukewarm plates. The chef tasting it takes two bites of the first thing, finds it raw, and stops. A smart cook instead makes one small dish, fully cooked, plated cleanly, with a note: "I focused on the main course; here's how I'd add the sides with more time." The chef takes one perfect bite and is sold. A small thing done all the way through beats a big thing done halfway — every time.

The single most undervalued piece is the README — the text file at the top of the project that explains it. This lesson says roughly 60% of your score lives there. A strong README has: how to run it (ideally one command), the key design choices you made, what you deliberately cut and why, what you'd do with more time, and known limitations. Saying "I skipped pagination because the spec didn't require it" reads as good judgment; shipping half-built pagination reads as someone who couldn't finish. The "what I'd do with more time" section is literally where reviewers grade how you think.

A short way to approach any take-home:

Why the format has changed: pure-algorithm take-homes are mostly dead because an AI chatbot can solve them in one shot, so they no longer tell the company anything. What replaced them all share one theme — prove you actually understand your own submission. The "extend your own code" round asks you to add a feature to the code you submitted, live, on the spot — so never submit code you couldn't modify cold. A transcript defense (used at places like Anthropic) means you also hand over your AI session log and explain specific choices — "why did you accept this suggestion, why re-prompt here?" — so treat that session like a clean paper trail, not 40 frustrated retries of the same prompt. And "build with our tool" rounds make the tool itself the test.

One increasingly common shape at AI startups is the 48-hour agent build: "build a working agent that does X, send the repo plus a 5-minute Loom" (a Loom is a short screen-recording walkthrough). An "agent" here is a program that loops with an AI model and tools to accomplish a task. Reviewers grade, in order: does it work end-to-end, do you have evals (even 5–10 test cases with expected outputs and a pass/fail check — without them you're just "vibe-coding"), is the agent loop bounded (a max number of iterations and a cost cap so it can't spin forever), does the Loom show one real tradeoff decision, and does the README pre-empt the obvious follow-ups including estimated cost per run. The pattern is the same as the cooking analogy: a small agent that demonstrates the full loop cleanly beats a sprawling one that hallucinates and never finishes. Honesty plus a working narrow scope wins.