A take-home in 2026 is no longer a coding test. The model can write the code. The reviewer knows this. What they are scoring is the part the model cannot do: the framing, the trade-off notes, the honest disclosure, and the rollback plan. This guide is for the candidate who has the skill and wants the submission to show it.
Why this matters
Take-homes are the part of the loop where the candidate has the most control and most often wastes it. The candidate thinks the goal is to demonstrate they can write the code. The reviewer is looking for the candidate who can frame the problem, pick a defensible scope, and ship a small thing well. In a market where the model can produce a runnable answer to almost any prompt, the differentiation moved from "can you code this" to "can you frame this." This guide is about that move.
What do reviewers actually read first — and why your README matters more than you think?
The first thing a reviewer opens is the repository root. They scan the README for sixty seconds. If the README does not tell them what was built, why, and what was left out, they form a hypothesis about the candidate before reading any code. That hypothesis is usually correct, because the README is the first artefact that shows whether the candidate can communicate engineering work in writing.
The chart below shows median time reviewers spend per submission section, drawn from our 2026 take-home reviewer study. The README dominates. The code is read partially. Tests are sampled. The replay or notes file, when present, gets more attention than the candidate expects.
A reviewer who spends fourteen minutes on the README and six on a full code read is telling you where to invest your time. Write the README first. Rewrite it last. Treat it as the artefact, not the wrapper.
A good README opens with the problem statement in your own words, names the scope you chose and the scope you cut, lists the trade-offs you took, and ends with the rollback plan. It does not narrate the implementation. The code does that.
How honest should you be about using AI?
Total honesty, with specificity. A submission that says "I did not use AI" in 2026 is either dishonest or naive — both are a negative signal. A submission that says "I used AI for everything" is also a negative signal because it tells the reviewer the candidate did not draw a line.
The signal reviewers want is calibration. They want to see that the candidate decided where AI helped, where it did not, and where they overrode the suggestion. The shape of the disclosure matters more than the content. "I used Claude to generate the file walker and accepted it with one edit; I wrote the cache key derivation by hand because the suggested key did not include the tenant id; I rejected three suggestions for the migration script and used the manual approach because the rollback was clearer" — that is the disclosure that scores. It tells the reviewer the candidate can defend the boundary.
What does "production-ready" mean for a take-home?
It does not mean deployed. It means the candidate has thought about what would happen if it were. A take-home is production-ready when the reviewer can read it and answer four questions: how would it fail, how would the candidate know, how would it be rolled back, and what would the next iteration add. None of those require infrastructure. All of them require thinking.
In practice this looks like: structured logs at the right level, an exit code that means something, a configuration surface that is not hard-coded, a one-line rollback in the README, and a TODO section in the README that lists the things the candidate chose not to build. The TODO section is more important than candidates expect — it is the place where they show what they would do next, which is one of the highest-signal questions in the rubric.
| Dimension | Weight | What gets a 'no' | What gets a 'yes' |
|---|---|---|---|
| Framing | 20% | The README restates the prompt verbatim. | The README states the problem in the candidate's words and names the scope cut. |
| Correctness | 20% | Happy path only; edge cases unhandled; one obvious bug. | Happy path plus two named edge cases. Bugs are listed in TODO with a reason. |
| Defensibility | 25% | No trade-off notes; reviewer cannot tell why choices were made. | Two to four short trade-off paragraphs; one decision is explicitly revised after the spike. |
| AI disclosure | 10% | Absent, or vague ('I used AI'). | Specific by component; names where AI was overridden and why. |
| Tests | 15% | Coverage theatre; tests do not protect the assumptions in the README. | A handful of tests, each named after a Spec assumption or a Spike finding. |
| Operability | 10% | No rollback plan; no logs; configuration hard-coded. | One-line rollback; structured logs; configuration explicit. |
Should you over-deliver?
At the junior bar, modest over-delivery reads as enthusiasm and is rewarded. At the senior bar it is a negative signal because it tells the reviewer the candidate could not pick a scope. The senior question is not "did you build a lot" — it is "did you build the right thing and explain the rest." A submission with a small, clean core, a thorough README, and a credible "what I would do next" section beats a sprawling submission with three half-finished features. Most candidates do not believe this until they have been on the other side of the review table.
If you have more time, spend it on the README and the disclosure, not on more features. The marginal hour is worth more in the framing than in the code.
The validation study showing take-home performance predicts live-loop outcomes (with caveats).
From Codritium Research
Take-Home vs. Live Coding, 2026
Does take-home performance predict live-coding outcomes? A longitudinal validation across 412 candidates and 1,860 interview rounds at 23 employers — with a decision tree, calibration plot, and the residuals that broke our first model.
Common questions
How long should you spend?
The prompt usually says 'about four hours.' Most strong submissions take eight to twelve hours spread across three to five days. Spending more than fifteen hours is correlated with worse outcomes because it usually means feature sprawl, not depth.
Should I disclose every AI tool I used?
Disclose by component, not by tool. The reviewer does not need a tool list. They need to know where you accepted, edited, and rejected suggestions. Three or four specific lines beat a long tool inventory.
Do reviewers run my code?
About 60% of reviewers run the code; about 30% read it without running; about 10% sample it. All of them read the README. Write for the population that does not run it, then make sure it runs cleanly for the ones who do.
Is it cheating to use Copilot?
No, unless the prompt explicitly forbids it. In 2026 most prompts assume AI use and ask for disclosure. Read the prompt twice; if it forbids AI, take it seriously and write by hand. If it allows AI, use it and disclose it clearly.
How important are tests?
Less important than candidates think, and in a specific way: coverage is unimportant, intent is important. A handful of tests, each named after a real assumption from the README, scores higher than a 90%-coverage test file that mostly mocks dependencies.
Where to go next
- The validation study: Take-home vs live loop, 2026
- The workflow that produces ship-ready take-homes: From vibe coding to production
- The rubric reviewers actually use: The Defensibility Rubric, 2026