Read the brief like a spec, not a puzzle
A take-home is a small project with a hidden rubric. Before you write a line of code, read the brief twice and pull out three things: what the reviewer explicitly asks for, what they imply, and what they did not mention. The explicit asks are non-negotiable. The implied asks, like reasonable error handling or a way to run the project, are where many candidates lose points. The unmentioned parts are your time budget protection. If the brief does not ask for authentication, do not build authentication.
Make a short list of the required features and treat it as your acceptance test. If the brief says "the API should return paginated results and handle invalid input gracefully," those are two checkboxes you must be able to tick at the end. Reviewers often grade against the brief almost literally. Missing a stated requirement reads worse than a smaller, cleaner submission.
Decide the time budget before you start
Most take-homes suggest a time box, often three to five hours. Honour it, even if you are tempted to keep polishing. Reviewers can tell when someone spent twenty hours, and an overbuilt submission can backfire because it suggests poor judgement about scope.
Split the budget roughly like this:
- Ten percent on reading the brief and planning.
- Sixty percent on the core feature working end to end.
- Fifteen percent on tests for the parts that matter.
- Fifteen percent on the README, cleanup, and a final pass.
Get one thin slice working end to end early, even if it is ugly, before you make any part nice. A submission where the main path runs beats a half-finished elegant abstraction every time. If you run low on time, a working feature with a noted gap is far stronger than a broken feature with beautiful code.
What reviewers actually grade
Reviewers are not looking for cleverness. They are imagining what it would be like to have you on the team. They tend to weigh these in roughly this order.
Does it work and is it easy to run
The first thing a reviewer does is clone the repo and try to run it. If the setup is unclear or it does not start, you have already lost ground. A clear README with exact commands matters more than people expect.
## Run
1. Copy `.env.example` to `.env`
2. `npm install`
3. `npm run dev`
4. Open http://localhost:3000
## Test
`npm test`
Is the code readable
Naming, structure, and consistency carry more weight than any individual algorithm. Use the conventions of the language and framework. Keep functions small and named after what they do. A reviewer should be able to follow the main path without jumping through ten files.
Did you make sensible decisions
Reviewers value judgement. If you skipped something on purpose, say so. A short note like "I chose an in-memory store to keep setup simple, in production this would be a real database" turns a perceived gap into evidence of good thinking.
Tests that signal seriousness
You usually do not need full coverage. You need tests on the parts that would embarrass you if they broke. Test the core business logic, the tricky edge cases, and the input validation the brief asked for. Skip testing framework glue and trivial getters.
test("rejects a negative quantity", () => {
expect(() => addItem({ id: "a", quantity: -1 })).toThrow();
});
test("merges duplicate items by id", () => {
const cart = addItem(addItem(empty, { id: "a", quantity: 1 }), {
id: "a",
quantity: 2,
});
expect(cart.items).toHaveLength(1);
expect(cart.items[0].quantity).toBe(3);
});
Two or three meaningful tests that cover the real risks say more than fifty shallow ones. They tell the reviewer you know what is worth protecting.
Write the README that frames your work
The README is your cover letter for the code. Keep it short and put it in this order: how to run it, what you built, the decisions you made and why, and what you would do with more time. That last section is powerful. It lets you show awareness of the gaps without having to fill them.
A good "with more time" section reads like this:
With more time I would add rate limiting on the write endpoints, move the store to Postgres, and add integration tests for the checkout flow. I left these out to stay within the time box and keep the focus on the core ordering logic.
That paragraph answers the questions a reviewer would otherwise raise in the debrief.
On using AI assistants honestly
Many candidates now use AI tools to draft parts of a take-home. The reasonable position is to use them the way you would on the job, then own every line you submit. Problems show up when candidates paste code they cannot explain. Some teams now add a short follow-up call where they ask you to walk through your own submission or extend it live. If you cannot defend a decision in your code, it does not matter who or what wrote it. Treat the assistant as a faster way to your own understanding, not a replacement for it.
Final pass before you submit
Spend the last fifteen minutes as a reviewer would. Clone your own repo into a fresh folder and follow your own README exactly. Run the tests. Read the diff top to bottom and remove dead code, stray console logs, and commented-out blocks. Check that file and function names still match what they do after your last changes. Then write a short submission message that points the reviewer at the README and names one thing you are pleased with. A calm, complete, well-explained small project beats an ambitious unfinished one in almost every loop.
Continue your prep
Pair this with role-specific question sets and sample answer outlines: