The short answer: a take-home assignment is a task you complete on your own time, usually a small coding project, a data analysis, a product or marketing plan, or a business case. Reviewers care less about perfection than about judgment: did you solve the core problem, make sensible trade-offs, stay within the time limit, and explain your thinking clearly? Clarify the scope, timebox your work, do the core well before any extras, write a short README or summary, and be ready to walk through it in a follow-up interview.
What reviewers look for
- The core requirement works, or is clearly answered.
- Sensible scope: you did what was asked, not a sprawling side project.
- Clarity: code or documents are easy to read and follow.
- Judgment: your assumptions and trade-offs are stated, not hidden.
- Communication: your README or summary explains what you did and why.
- For code: reasonable structure, some tests, and it runs with simple instructions.
Before you start
- Read the brief twice. Highlight the must-haves, the nice-to-haves and the deliverables.
- Ask clarifying questions early, in one short email. Reviewers often count good questions in your favor. If they don’t reply, state your assumptions in the README.
- Confirm the time expectation. If it says “about 3 hours,” aim for about 3 hours. If there’s no guidance, ask.
- Check the deadline and plan when you’ll do it.
Timebox and prioritize
- Plan first (10%): list the steps and decide what’s in and out of scope.
- Build the core (60%): get the main requirement working end to end.
- Polish (20%): clean up, handle obvious edge cases, add tests or check your numbers.
- Write up (10%): the README or summary.
If you run out of time, stop and write down what you’d do next. A working core with a clear “next steps” list beats an unfinished pile of extras.
Coding take-homes
- Follow the requested language and framework, unless you’re told you can choose.
- Keep the structure simple and consistent. Clear names over clever code.
- Add a few meaningful tests for the core logic, not 100% coverage.
- Make it easy to run: one command if possible, with setup steps in the README.
- Commit in small steps with clear messages, if you’re submitting a repository. Reviewers may read the history.
- Don’t include secrets such as API keys in the code.
Case study and non-coding take-homes
For product, marketing, consulting, operations or data analysis take-homes:
- Lead with your recommendation, then the reasoning.
- Show your structure: the question, your approach, the analysis, the recommendation, the risks.
- State your assumptions where data is missing, and why they’re reasonable.
- Keep it short: a few clear slides or pages beat a long document.
- Check every number and chart label.
Writing the README or summary
Keep it to one page:
- What it does: one paragraph.
- How to run it (for code) or how it’s organized (for documents).
- Assumptions you made.
- Trade-offs: what you chose and what you left out, and why.
- What you’d do next with more time.
- Time spent, honestly.
Presenting it in the follow-up interview
Many companies follow the take-home with a review conversation. Expect:
- “Walk me through your solution.”
- “Why did you choose this approach?”
- “What would you change with more time?”
- “How would this handle 10 times the data or users?”
- “What would you test next?”
Prepare a two-minute overview, know your trade-offs, and be open about weaknesses in your solution. Saying “I’d change this, and here’s why” shows the judgment they’re looking for. See our guide to explaining a complex problem for how to structure it.
When the assignment is too big
A take-home that would take days of unpaid work is a fair thing to raise. You can politely ask whether a smaller scope is acceptable, propose one, or ask whether a live exercise is an option. How the company responds tells you something about how it treats people.
Mistakes to avoid
- Going far over the time limit to make it perfect
- Adding features nobody asked for before the core works
- No README, or instructions that don’t work
- Hiding shortcuts instead of stating them
- Submitting late without warning
