My first take-home took eighteen hours and got rejected. My next one took five and got an offer. The difference was scope, tests and a README that explained my thinking.
Written after both outcomes · Updated September 2026 · 8 min read
Take-home assignment
Small and finished beats big and half-done.
The short version: do exactly what the brief asks, time-box it to roughly the suggested hours, write a few meaningful tests, and spend the last 45 minutes on a README that explains your decisions and what you'd do with more time. Read the AI policy before you start and follow it exactly.
Assignments vary a lot. When the brief and this article disagree, follow the brief.
My first take-home took eighteen hours
And that was the problem.
The brief said "around four hours". I spent a weekend on it: extra features, a config system nobody asked for, an admin endpoint, no tests. I was proud of it. The feedback, when it came, was polite and specific: the submission was hard to review, and it wasn't clear which parts mattered.
That's when I understood what a take-home is actually testing. Not how much you can build. Whether you can decide what not to build.
Anyone can add features. The signal is what you chose to leave out, and whether you said why.
Read the brief like a spec
Twice, with a pen.
Underline every requirement
Then check them off before you submit. Missing one is the most common rejection.
Find the AI policy
Allowed, forbidden, or silent. If silent, ask the recruiter.
Note the suggested time
It's a scope hint, not a challenge.
Ask one clarifying question
A good question early reads as professional, not clueless.
How I spend the hours now
How I split the time on the take-home that led to an offer.
The parts people skip are the parts that get reviewed most closely: the tests and the README. A reviewer skims your code for twenty minutes; they read your README properly.
The README that made the difference
Four short sections.
Fifteen lines each. Reviewers told me this section carried the submission.
That last section is quietly powerful. Writing "with more time I'd add retry handling and a proper migration path" shows you know what's missing, which is most of what seniority looks like on paper.
The AI policy question
Read it, then follow it exactly.
More companies now state a policy, and the two honest options are both fine: use AI and describe how, or don't use it at all. What isn't fine is ignoring a clear instruction, because take-homes are usually followed by a review call where you walk through your own code line by line.
On my second take-home the policy allowed AI with disclosure, so I noted in the README which parts I'd used it for. Before starting, I'd also spent a couple of evenings refreshing the patterns I expected to need, comparing my own implementations with the approaches from Phantom Code AI. That preparation happened before the assignment arrived, which kept the submission entirely mine.
The review call
Assume you'll defend every line.
Prepare to explain
Why you structured it this way
Where it would break at scale
Why those tests and not others
What you'd change now
Red flags for reviewers
Code you can't explain
No tests at all
A README that just says 'run npm start'
Features nobody asked for
Common questions
Short answers.
How long should it take?
What goes in the README?
Do I need tests?
Can I use AI?
Small, finished and explained
The submission that got me an offer was smaller than the one that got me rejected. It did exactly what was asked, had six tests, and came with a README that explained every choice I'd made.
If you're staring at a brief this weekend: set a timer, cut one feature, and spend the last hour writing about your decisions.
— Written on a weekend I got back
What's the worst take-home you've been given?
Mine asked for 'about 4 hours' of a full payments system.
Some third-party reviews of these tools are published by competing products, so verify prices on official sites before buying.
Top comments (0)