A take-home coding challenge looks like the most comfortable round in the loop. No one is watching, you use your own editor, and you can look things up. But it's really two interviews in one: the assignment, and the conversation about it afterwards. Many candidates put all their effort into the first and arrive unprepared for the second.
This guide covers what a take-home assignment is, how to scope and timebox it, what reviewers look at, and how to prepare for the review call.
What a take-home assignment is
A take-home assignment (also called a take-home test, coding challenge, or work sample) is a small project you build on your own time and submit for review. Typical briefs:
- Build a small API with a few endpoints and some business rules
- Build a small frontend that fetches and displays data, with some interaction
- Process a data file and produce a report
- Extend or fix a small existing codebase
The brief usually suggests a time limit, often a few hours, and a deadline of a few days to a week. After you submit, there's usually a review call where an engineer walks through your code with you, asks about your decisions, and sometimes asks you to change something live.
Companies use take-homes because they show how you work without someone watching every minute: how you scope a brief, structure a project, write code a teammate could maintain, and decide what's worth testing.
Before you start: read the brief twice
Read it once for what to build and once for how it'll be judged. Look for:
- Explicit requirements. The must-haves. List them.
- Explicit non-requirements. "You don't need authentication" is a gift: don't build it.
- The suggested time. This tells you the expected scope. A three-hour brief doesn't want a microservices architecture.
- Language and framework constraints. If they say any language, use the one you know best, unless the job is in a specific stack and you're fluent in it.
- How to submit, and whether they want a README, tests, or instructions to run it.
If something important is ambiguous, it's fine to email and ask. If it's minor, make a reasonable assumption and write it down. You'll put those assumptions in the README later.
How long to spend
Stick to the suggested time, or close to it, and say in the README if you went over. It's tempting to spend a weekend polishing a three-hour task, but it usually doesn't help as much as you'd hope:
- Reviewers generally prefer a focused, finished core to a sprawling project.
- A stated timebox makes your scoping decisions easier to understand. "I spent three hours, so I prioritised X and left Y" reads as judgement; a half-built Y with no explanation reads as running out of time.
- It's fairer to you. A take-home that eats a week of evenings isn't a good trade, especially if you're in several processes.
A reasonable split for a three-hour task: 15 minutes reading and planning, two hours building the core with tests, 30 minutes on the README and cleanup, and 15 minutes rereading everything as a reviewer would.
Scope: core first, extras last
Build the required features first, completely, with tests. Only then consider extras, and only if they're cheap and clearly useful.
Untested extras next to an unfinished core read worse than a smaller, polished submission. If you have ideas you didn't build, list them in the README under "what I'd do next". That shows the thinking without the risk.
What reviewers look at
Reviewers usually read in roughly this order, so this is also the order of first impressions:
- The README. Can they run it? Do they understand what you assumed and why?
- The structure. Is it obvious where things live? Does the layout fit the size of the problem?
- The tests. Do they cover the important behaviour and the obvious failure cases?
- The code. Naming, readability, error handling, and whether it does what the brief asked.
The README
A good take-home README is short and has five parts:
- How to run it, in a couple of commands, and how to run the tests
- What you built, briefly, against the brief
- Assumptions you made where the brief was ambiguous
- Decisions and tradeoffs: why you chose this structure, this library, this approach
- What you'd do next with more time, in priority order
Write the assumptions down as you make them while building. They become the README almost by themselves, and they answer the reviewer's first questions before the call.
Tests
You don't need full coverage. You need enough to show the important behaviour works and the obvious failure cases are handled: a few well-named tests for the core logic and its edge cases. A test called rejects_transfer_when_balance_is_insufficient says more than ten tests of trivial getters.
Code
Write it as if a teammate will maintain it. Clear names, small functions, consistent formatting, and errors handled deliberately rather than ignored. Avoid over-engineering: layers of abstraction that a small problem doesn't need make the code harder to review, not more impressive.
Take-home coding challenge examples
Briefs vary, but most fall into a few shapes. Here's what each is usually looking for, and where people tend to over- or under-invest:
| Brief | What it's looking for | Where to be careful |
|---|---|---|
| A small REST API (e.g. a booking service) | Data modelling, validation, error handling, tests | Business rules and edge cases matter more than frameworks |
| A frontend that fetches and shows data | Component structure, state, loading and error states | Polish the core flow before adding animations |
| A data-processing script or report | Correctness, handling messy input, clear output | Malformed rows and empty files; say what you assumed |
| Extending an existing codebase | Reading unfamiliar code, matching its conventions | Change what's needed; don't rewrite what you'd do differently |
| A small command-line tool | Clean interfaces, argument handling, testability | Useful error messages are part of the brief |
Whichever shape you get, the same principle applies: a smaller scope done carefully, with the important behaviour tested and the decisions explained, reads better than an ambitious scope rushed to fit the time.
Using AI tools on a take-home
Many engineers now use AI coding assistants in their daily work, and companies' policies on using them for take-homes differ. Some allow it, some ask you to disclose it, and some ask you not to. Read the brief, and if it doesn't say, ask. Whatever the policy, you'll be expected to explain every line in the review call, so don't submit code you couldn't have written and can't defend.
The review call
This is the second interview, and it's where many candidates who did well on the code stumble. The review call is usually 30 to 60 minutes. Expect:
- A walkthrough. You'll be asked to explain the structure and the main flow.
- "Why" questions. "Why did you choose this structure over a single module?" "Why this library?" "Why didn't you handle this case?"
- Scaling and failure questions. "What would break first with a thousand concurrent users?" "What happens if the external API is down?"
- A live change. "Add input validation to this endpoint." "Handle this new requirement." You'll make it while talking through what you're doing.
How to prepare for the review
- Reread your own code the day before. It's surprising how quickly the details fade.
- Be ready to explain any line and the alternative you didn't choose.
- Prepare your "what I'd do next" list in order, with a reason for each. It will come up.
- Know the weak spots. If there's a part you're not happy with, say so before they find it, and say how you'd improve it. That reads as self-awareness.
- Practise a live change. Pick a plausible extension and implement it while talking out loud. The skills overlap heavily with live coding; see how to prepare for a live coding interview and our guide to thinking aloud while you code.
When a reviewer questions a decision, don't get defensive. "That's a fair point. I chose this because of X, but if Y mattered more, I'd do it this way" is a strong answer. It shows you understand the tradeoff and can change your mind with new information.
A checklist before you submit
- Every required feature done and working
- Tests for the core behaviour and the main edge cases, all passing
- README with run instructions, assumptions, decisions, and what you'd do next
- Time spent noted, if you went over
- Code reread as a reviewer, with leftover debugging and dead code removed
- A clean commit history, if the brief asks for a repository
Take-homes usually sit in the technical screen stage of an interview loop, sometimes in place of a live coding round. Our guide to preparing from the job description covers spotting one in the posting ("work sample", "take-home") before the recruiter mentions it.
Hardmode's take-home round gives you a scoped, realistic brief to build on your own time, then runs the review call: about 30 minutes in which a reviewer reads your submission, asks why you made your choices, and asks for a change.