A test with two ways to fail
The take-home assignment is a strange interview format because you can fail it from both directions. Do too little and you look like you do not care. Do too much - gold-plate it for twenty hours - and you signal someone who cannot scope, ship, or respect a deadline. Both are real failure modes, and the second one is more common among strong engineers who want to impress.
The skill is calibration. Here is how to land in the middle that actually stands out.
Read the prompt for the real ask
Most take-homes tell you what they are evaluating if you read carefully. "Build a small API that does X" with a note about clean code is asking for clarity and structure, not a feature-complete product. A prompt that mentions tests is telling you tests are scored. Build to the rubric they handed you, not to the most impressive thing you can imagine.
If there is a time estimate, treat it as a real constraint. "This should take about three hours" means they will read it expecting three hours of work, and a twenty-hour submission can actually count against you. It reads as someone who does not know when to stop.
Do the core thing well, then stop
The winning move is almost always: nail the core requirement cleanly, with good structure and a couple of tests on the important paths, and then stop. Clean, readable, correct, and obviously complete beats sprawling and half-polished every time.
Resist the urge to add features. An unrequested feature, built quickly, often hurts you - it is usually rougher than the core and signals poor judgment about scope. If you have an idea for an extension, do not build it; mention it.
Use the README to show your judgment
The highest-leverage twenty minutes you can spend is on a short README. Use it to do what the code cannot:
- What you built and how to run it.
- The tradeoffs you made and why - "I used an in-memory store to stay in scope; in production this would be a real database."
- What you would do with more time.
That last section is where you get credit for the features you wisely did not build. It shows the reviewer you understand the full picture and chose to scope deliberately, which is exactly the senior signal they are looking for.
The meta-signal
A take-home is not really testing whether you can build the small thing. Of course you can. It is testing whether you can scope a problem, deliver clean work to a constraint, and communicate your decisions - because that is the actual job. Calibrate to that, and you stand out by doing less, better, with a clear explanation of why.