The technical test done at home, often called a take-home, has become a common step in developer recruitment, especially at startups and scale-ups. The company sends a brief (a small API, an interface, a data processing task), sets a deadline, then organises a session where you present your work. For the candidate, the difficulty is not only technical: you have to decide how much time to spend, what to deliver and how to present choices that are necessarily incomplete. This article takes the point of view of the team doing the reviewing, to help you hand in work you can defend.
What the team looks at when reviewing
The team that receives your submission is almost never looking for the perfect solution. It has often reviewed dozens of versions of the same exercise, and knows exactly what it wants to assess. Its scorecard, explicit or implicit, generally covers five points.
- Meeting the brief. Are the requested features present, and do they work? A submission that adds features nobody asked for but forgets a basic requirement scores poorly.
- Readability. Is the code easy to read? Are names clear, responsibilities separated, the structure consistent? A reviewer must be able to understand your logic in a few minutes.
- Tests. Are there any, and do they test what matters? A few well-chosen tests on the business logic are worth more than high coverage on trivial code.
- Choices and their justification. Why this architecture, this library, this data model? What did you leave out, and why?
- Ease of running it. Can the reviewer install and run the project by following your instructions, without guessing? A project that does not start begins with a serious handicap, whatever its quality.
This last point is often underestimated. Test your own installation procedure in a clean environment before sending the link.
How much time to spend on it
This is the most frequent question, and the trickiest. Briefs often give an indicative duration ("about three hours"), sometimes none.
A few reference points:
- Respect the order of magnitude announced. If the company says three hours, it has calibrated its scorecard for that time. Spending a whole weekend on it will not give you a proportional advantage, and some teams frown upon a submission that is obviously oversized.
- Note the time actually spent and state it in the README. It is useful information for the reviewer, who will judge your work in light of that time.
- Prioritise. Start with a complete path that works, even a simple one, then improve. An incomplete submission that works on the essentials is better than an elegant architecture that does nothing.
- List what you would have done with more time. It is the best way to show that you see further than what you delivered, without spending hours on it.
If the deadline or scope of the exercise seems disproportionate, for example because you are running several processes in parallel or you are currently employed, it is legitimate to raise it. Many companies accept extra time, a reduced version or another format, such as a pair programming session. Our article on preparing for a technical interview details the different exercise formats and what each one assesses.
The README that explains your choices
The README is the most important part of your submission after the code itself. It is the first thing the reviewer reads, and it frames the reading of everything else.
A good take-home README contains:
- a two- or three-line summary of what the project does;
- instructions to run it, precise and tested: prerequisites, installation commands, start command, test command, any environment variables;
- technical choices, with their rationale: "I chose an SQLite database to make it easy to run; in production, I would use PostgreSQL for concurrent access";
- the assumptions you made where the brief was ambiguous, rather than leaving them to be guessed;
- known limitations and what you would do with more time: pagination, fine-grained error handling, authentication, load testing;
- the time spent.
Example of a "choices and limitations" section:
I separated the pricing logic into a module with no dependency on the framework, unit tested, so that it can evolve independently of the API. The API validates inputs against a schema; errors return a consistent format. Not covered for lack of time: pagination of the bookings list and time zone handling, which I would address by storing all dates in UTC.
This paragraph tells the reviewer what you wanted to show, what you know is missing and how you would handle it. It also prepares the discussion during the debrief.
Tests, structure and Git history
Tests
Test the business logic first, that is, the part of the brief that involves rules: a calculation, a validation, a filter, a state transition. Add one or two integration tests on the main path (an API request that creates then reads a resource, for example). There is no need to aim for exhaustive coverage; aim for tests that show you know where the risks are.
Make sure the tests pass with a single command, documented in the README. A reviewer who has to search for how to run your tests may not run them at all.
Structure
Adopt a structure proportionate to the exercise. A small API does not need a full hexagonal architecture with ten layers of abstraction; it needs a clear separation between the HTTP layer, the business logic and data access. Visible over-engineering worries reviewers as much as messy code: it suggests a developer who complicates everything.
Also keep a clean configuration: an ignore file for dependencies and generated files, formatting and lint settings, no secrets in the code.
Git history
Many reviewers look at the commit history, which shows how you work. Commit regularly, with clear messages that tell the story of your progress: project setup, data model, first route, tests, error handling, documentation. A single giant commit called "submission" wipes out all this information. The Git book 🔗 recalls good practices if needed, and our article on the GitHub link on a resume details what a lead reads in a history.
Preparing the debrief
Most take-home tests are followed by a debrief session, from half an hour to an hour, with one or more team members. It is often what decides the outcome.
Be ready to:
- present your solution in five minutes: what you built, the architecture, the main choices;
- explain a choice you would make differently: reviewers almost always ask, and a clear-sighted answer is very well received;
- change the code live: add a feature, fix a deliberately introduced bug, handle a new case. Review your own code before the session so you can find your way around it quickly;
- discuss scaling: what would happen with much more data or many more users? Where would the bottlenecks be?
- take criticism: a reviewer may point out a weakness. Listen, acknowledge it if it is fair, explain your reasoning if not. The team watches your reaction as much as your code.
The debrief is also the moment to ask the team questions: how it works, how it does code reviews, how it tests. It is valuable information for your decision.
The technical test and your resume must tell the same story. If your resume claims a practice of testing and continuous integration, the submission must contain them. The full-stack developer resume template shows experience where end-to-end tests and continuous deployment are described precisely, which naturally prepares this kind of discussion. A clear resume, laid out by a tool that avoids the columns and graphic elements that recruitment software reads poorly, gets you to this stage: you can prepare yours before sending your applications.
Frequently asked questions
Can I use a coding assistant for a take-home test?
Read the brief: some companies allow it, others forbid it. In the absence of a rule, be transparent in the README about how you used it. Either way, you will have to explain and modify every line during the debrief.
Should I add features that were not requested?
Only once the brief is fully covered, and sparingly. A list of ideas in the README is better than an extra feature that introduces a bug. Reviewers assess what was requested first.
What if I do not finish in the time allowed?
Deliver what works, state clearly what is missing and how you would have done it. A partial but well-documented submission often scores better than a complete but fragile one sent late.
Can my take-home code stay public on GitHub?
Check the company’s instructions: many ask you not to publish the brief or the solution, so that they can reuse the exercise. When in doubt, use a private repository shared with the team, or delete the public repository after the process.