Clarify scope and time first, deliver a small working core before any extras, and treat the README as part of the submission: how to run it, decisions, trade-offs and what you would do with more time. Reviewers judge clarity, correctness and judgement, not how many features you squeezed in.
What people tell me
A company sent me a take-home assignment: build a small app or API in a few days. I either over-build it, spending the whole weekend adding features, or I panic and submit something rushed. I have had one rejected with no feedback and I do not know what reviewers were looking for. I also wonder whether it is fine to use AI tools, and how much time I should really spend.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Ask about scope, time expectation and evaluation criteria before starting. It is a normal question.
- Ship a small, correct, well-structured core first. Extras only after that works.
- The README is part of the assessment: setup, decisions, trade-offs, known gaps.
- Respect the suggested time. A reviewer notices judgement more than extra features.
- Follow the company's rules on AI tools and be ready to explain every line in a follow-up call.
What reviewers are actually looking for
A take-home is a sample of how you work when nobody is watching. Reviewers usually have a rubric that looks something like this:
| Area | What they check |
|---|---|
| Correctness | Does it do what was asked? Do edge cases break it? |
| Structure | Is the code organised in a way a teammate could extend? |
| Readability | Clear names, small functions, no dead code |
| Testing | A few meaningful tests on the core logic |
| Judgement | Sensible scope, trade-offs explained |
| Communication | README, commit history, how you describe decisions |
Notice that "number of features" is not a row. Candidates who over-build often score worse, because the core is weaker and the code is harder to review.
Before you write any code
- Read the brief twice and list every explicit requirement.
- Ask clarifying questions by email if anything is unclear. Asking about expected time, evaluation criteria and whether libraries are allowed is normal and shows good judgement.
- Check the rules on AI tools. Some companies allow them, some do not. Follow what they say.
- Decide your time box. If they say three to four hours, aim for that, with maybe a little extra for the README.
- Sketch a plan: data model, main modules, what "done" means.
Build in layers
| Layer | Goal | Stop point |
|---|---|---|
| 1. Walking skeleton | Project runs, one route or screen works end to end | You can demo the main flow |
| 2. Core requirements | Every explicit requirement works | All listed features pass manual checks |
| 3. Quality | Validation, error handling, tests on core logic | Tests pass; obvious edge cases handled |
| 4. Polish | README, clean-up, consistent naming | A stranger can run it in five minutes |
| 5. Extras (optional) | One small bonus, only if time remains | Mention it clearly |
If time runs out, you stop at a clean layer, not halfway through a fancy extra.
The README matters more than people think
Many reviewers read the README first. Include:
- How to run it, in three to five commands, tested on a clean machine or container
- What is implemented against the brief
- Key decisions and trade-offs: "I used an in-memory store to keep setup simple; in production I would use PostgreSQL because..."
- What you would do with more time, as a short list
- Assumptions you made where the brief was vague
- How you used any tools, if their rules ask for it
A clear README can turn a solid submission into an easy yes.
Tests: enough, not everything
Write a handful of tests around the core logic and one or two for the main API or user flow. Reviewers want to see that you know what is worth testing, not 100 percent coverage. Five kinds of API test is a good reference for choosing.
Commits tell a story
Small, well-named commits ("add booking model and validation", "handle overlapping slots") show how you think. A single commit named "done" hides it. Do not rewrite history to look perfect; just commit as you go.
Using AI tools
If AI tools are allowed, you can use them to speed up boilerplate, but:
- You must understand and be able to explain every line. Many companies follow up with a call where they ask you to extend or change your code live.
- Review generated code carefully. Subtle bugs and unused code are common.
- If the rules ask you to disclose tool use, do it plainly.
If they are not allowed, do not use them. Integrity problems end processes quickly. The broader question of healthy AI use is covered in this answer.
A practice plan before your next one
| Week | Practice task | Focus |
|---|---|---|
| 1 | A small REST API with validation, in four hours | Layers and README |
| 2 | A frontend list with search, filter and loading states | Structure and edge cases |
| 3 | Redo week 1 in three hours, with tests | Time boxing |
| 4 | Ask a friend to review one as if they were hiring | Feedback on readability |
The Backend and Frontend cheat sheets are handy for checking you have the usual concerns covered.
When a take-home is unreasonable
A few hours is normal. If a company asks for several full days of unpaid work that looks like a real product feature, it is reasonable to ask whether a shorter version is possible, or to decline. You do not have to accept every request.
The follow-up call
Many processes include a review call. Prepare to:
- Walk through your structure in two minutes
- Explain one trade-off you made and why
- Discuss what breaks at scale
- Make a small live change
Practise explaining your code aloud before the call.
Common mistakes
- Over-building. Ten half-finished features lose to four solid ones.
- Not running it from scratch before submitting. A missing environment variable can sink an otherwise good submission.
- No README, or a default template one.
- Ignoring the brief to show off a favourite technology.
- Leaving secrets or commented-out code in the repository.
- Submitting late without a word. If you need more time, ask early.
If you are still stuck
Six rules that keep a codebase worth working in covers the structure reviewers like to see. If take-homes keep coming back as rejections, join Sefism (free to learn, credits on joining, first roadmap free) and, as a member, book a 1:1 session to go through one of your submissions together.
Was this answer helpful?
Read next
- Six Rules That Keep a Codebase Worth Working InSix clean code principles, separation of concerns, DRY, KISS, YAGNI, test-driven design and writing for the next reader, each with what it protects against, where it came from and how it goes wrong.
- Five Kinds of API Test and When Each One Earns Its PlaceThe five types of API testing that do most of the work: functional, integration, regression, load and security. What each catches, what each misses, how to spread your effort, and the one-minute check OWASP ranks as the top API risk.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.