Saturday, 11:40pm. The take-home assignment said "should take 2-4 hours." It is now hour six. There are three half-finished abstractions, a test suite that was supposed to come "after the core logic," and a README that still says TODO: write this. Somewhere around hour three, the assignment stopped being an interview exercise and became a referendum on this candidate's entire competence as an engineer, which is exactly the moment most people start adding features nobody asked for — a caching layer, a plugin system, a config file — because if the thing is impressive enough, surely the time spent won't matter.
It will matter. Take-home assignments are not graded on ambition. They're graded on whether you can scope a problem, ship something that runs, and explain your decisions clearly — which is a different skill than the one most candidates train, and the gap between "talented engineer" and "passes the take-home" is almost always about discipline, not ability.
What a take-home is actually testing
Companies use take-homes instead of (or alongside) live coding for one main reason: they want to see how you work without someone watching, on a problem that's closer to real work than a whiteboard puzzle. That means the rubric is rarely just "does it work." Most rubrics, explicit or not, weigh:
- Scoping judgment — did you build the thing they asked for, sized appropriately, or did you over- or under-build it?
- Code you'd actually ship — readable names, reasonable structure, tests on the parts that matter — not necessarily exhaustive coverage.
- Communication — does the README explain what you built, what you'd do with more time, and any tradeoffs you made under the clock?
- Time discipline — did you respect the stated time box, or did you burn a weekend on a 3-hour assignment?
That last one surprises people the most. Submitting something polished after 14 hours on a "3-4 hour" assignment isn't impressive — it's a signal that you either can't estimate, can't stop, or both, and both are expensive traits on a real team with real deadlines.
Time-box it for real, with a timer
Set an actual timer before you open the assignment. If they say 3-4 hours, plan for 3.5 and stop near there even if it's not "done" — finished-and-honest beats polished-and-late. A workable split for a typical 3-4 hour assignment:
- 20-30 minutes — read the whole prompt twice, write down what "done" means in your own words, and decide what you're explicitly not doing.
- 60% of the remaining time on the core functionality — the thing they actually asked for, working end to end before you touch anything else.
- 20% on tests for the parts most likely to break or that show judgment (edge cases, not 100% coverage theater).
- Last 20-30 minutes — the README. Non-negotiable; see below.
If you finish core functionality early, resist scope creep. Extra polish on the thing they asked for beats a half-built extra feature nobody requested.
The README is part of the deliverable, not an afterthought
A surprising number of strong submissions lose points because the README is empty, generic, or missing entirely. Reviewers often skim the README before running the code — it's your only chance to narrate decisions a stranger reading your diff cold would never infer. A README that actually helps your case covers:
- How to run it (literally, copy-pasteable commands) — broken setup instructions kill submissions before the reviewer sees a single line of logic.
- What you built and, briefly, why you structured it that way.
- What you explicitly skipped or simplified given the time box, and what you'd do differently with more time. This is the single highest-leverage paragraph in the whole submission — it shows judgment under a constraint, which is the actual thing being tested.
- Any assumptions you made when the prompt was ambiguous (it almost always is, on purpose).
Common ways people quietly fail this round
- Silent scope creep — adding a feature, framework, or abstraction nobody asked for, at the cost of finishing the actual ask.
- No tests at all — even 3-4 focused tests on the trickiest logic signal more than zero.
- Broken setup — a missing dependency line or an undocumented env var, and the reviewer never even sees your logic.
- Ignoring the time box — submitting 10+ hours of work for a "few hours" prompt, badly, because burnout set in around hour 6.
- No explanation of tradeoffs — a perfectly fine submission that reads like it was thrown over a wall with zero narration.
Take-home vs. live coding vs. a generic question dump
A take-home tests something a live whiteboard round can't: how you actually work without a clock ticking down in front of an audience. But it also rewards a different kind of practice. Grinding a question dump from GeeksforGeeks or a friend's WhatsApp PDF of "100 interview questions" trains pattern recognition for puzzles — it does almost nothing for scoping a fuzzy real-world prompt or writing a README a stranger can act on. LeetCode reps help with the live-coding round; they don't help you decide what to cut when a take-home's "few hours" budget collides with your ambition. The skill that actually transfers is explaining your decisions out loud, clearly, under a real constraint — which is exactly what a spoken mock interview forces you to practice, and a silent question bank cannot.
If the role's take-home is paired with a follow-up call where someone walks through your code with you (increasingly common), that conversation is graded too. Practising how you'd narrate "I skipped input validation here because the prompt said happy-path only, and I'd add it first if scope expanded" out loud, before the real call, is exactly the kind of rehearsal a mock interview session is good for — see our guide on talking through code like a senior engineer for the phrasing patterns that make tradeoff explanations land instead of sounding defensive.
After you submit
Send a short note (or use whatever portal they gave you) confirming submission, and if there's a deadline gap before you hear back, our guide on following up after no response covers the right cadence. If you get a follow-up call to walk through the code, prep it like any other round — review what you wrote (you'd be surprised how fast you forget your own tradeoffs after a few days), and rehearse explaining the "what I'd do with more time" section out loud, since that's almost always where the conversation goes first.
Frequently asked questions
How long should I actually spend on a take-home assignment?
Spend close to the time the company states, plus maybe 15-20% buffer — if they say 3-4 hours, budget 3.5 and stop near there even if it isn't perfectly polished. Submitting something finished and honest within the stated window is a stronger signal than something more polished submitted after 10+ hours, which reads as poor time estimation rather than dedication.
What should I include in the README for a take-home assignment?
Include exact run instructions, a short summary of what you built and why you structured it that way, what you explicitly skipped or simplified given the time box, what you'd do differently with more time, and any assumptions you made where the prompt was ambiguous. The 'what I'd do with more time' section is often the single highest-leverage paragraph in the whole submission.
Should I add extra features to a take-home assignment to stand out?
No — scope creep is one of the most common ways strong candidates quietly fail this round. Reviewers grade whether you built the thing they asked for, sized appropriately, within the time box; an unfinished requested feature plus an unrequested extra one reads as poor judgment, not ambition.
Do take-home assignments need full test coverage?
No. A few focused tests on the trickiest or most failure-prone logic signal good judgment; exhaustive coverage on a time-boxed assignment usually means you under-invested in the core functionality or the README to get there. Reviewers are checking that you test thoughtfully, not exhaustively.
What happens after I submit a take-home assignment?
Many companies follow up with a call where someone walks through your code with you and asks about your decisions — this conversation is graded too. Prep it like a regular interview round: review your own tradeoffs before the call, and rehearse explaining what you'd do differently with more time, since that question almost always comes up.