A take-home coding assignment is the interview stage where strong engineers most often eliminate themselves, not by writing bad code, but by misjudging what the company is actually evaluating. This guide covers what take-home assignments really test, how to structure your submission, how long to spend, and the submission patterns that advance to the next round.
What is a take-home coding assignment?
Take-home coding assignment: a work-sample exercise sent to candidates to complete independently, typically within 24–72 hours, designed to evaluate technical ability outside the pressure of a live coding session.
Take-home assignments appear at all levels, from junior engineer to senior staff. They're used as a replacement for or supplement to whiteboard interviews, and the format has become more common as remote-first hiring has become standard. Most companies that use take-homes see them as more predictive of job performance than live coding puzzles.
What does a take-home assignment actually evaluate?
Most candidates focus entirely on correctness. Companies are also evaluating three things that don't show up in pass/fail tests:
Code quality and organization. Is the code readable? Are functions well-named? Is there appropriate separation of concerns? This is what a pull request reviewer at the company would care about. That is exactly who reviews take-home submissions.
Decision-making under ambiguity. Most take-homes leave requirements intentionally vague. The way you handle ambiguity, whether you document assumptions, ask a clarifying question, or pick a reasonable interpretation and explain it, tells interviewers how you operate with incomplete specifications.
Scoping and judgment. Did you scope the work to the time limit, or did you overbuild? An engineer who delivers a focused, working solution beats an engineer who started three features and finished none.
Hiring manager insight
"According to research summarized in the Harvard Business Review on structured hiring processes, work samples (including take-home coding exercises) are among the most predictive assessments of on-the-job performance. The research found that work sample tests have a validity coefficient of 0.33, placing them among the strongest predictors of future job performance available to hiring teams, more predictive than unstructured interviews or reference checks."
— Harvard Business Review: How to Design a Better Hiring Process
How long should you spend on a take-home assignment?
The company tells you the time expectation in the brief (typically 2–4 hours). Take their estimate seriously. Spending 20 hours on a 4-hour assignment signals poor scoping and time management, not thoroughness. Spending 1 hour on a 4-hour assignment signals you didn't prioritize it.
If you finish in half the expected time and the solution is solid, use the remaining time to review edge cases, clean up the code, and write a strong README. If you're running over the expected time, scope down rather than extend the deadline: a working subset beats a broken feature set.
Exception: if the brief says "there's no hard time limit, but we typically see candidates spend 4–6 hours," then 6–8 hours on a senior-level problem is reasonable.
What should a take-home submission look like?
A take-home submission has two parts: the code and the README. Both are evaluated (sometimes the README more than the code).
The code
- Runs without modification on a fresh checkout (exact commands in README)
- No commented-out debugging artifacts left in
- Sensible naming and structure throughout
- Tests for core business logic, not 100% coverage for its own sake, but tests that cover the cases that matter to the product
The README
This is often more impactful than the code itself. Reviewers read the README before running anything. A good README covers:
- How to run it: exact commands, dependencies, OS assumptions
- What you built: a 2–3 sentence summary of what the solution does
- Assumptions and tradeoffs: what requirements you interpreted, what you chose NOT to build and why
- What you'd do with more time: the improvements you scoped out, showing you know what "good" looks like
- Known limitations: better to name them than have the reviewer find them
The "assumptions and tradeoffs" section is where senior engineers differentiate. A candidate who documents their decisions ("I chose a simple in-memory cache over Redis because the brief didn't specify persistence requirements and adding infrastructure would require more setup time than the assignment warranted") demonstrates engineering judgment, not just coding ability.
How do you handle ambiguous requirements?
Clarify once, early. Send one concise email within the first few hours of receiving the assignment: ask 2–3 specific questions about truly ambiguous requirements. This demonstrates that you seek clarity before building.
If you don't get a response before your deadline, document your interpretation in the README and build against it. Don't use ambiguity as a reason to do less work: pick a reasonable interpretation and execute it.
What not to do: send 12 questions, ask things you could answer yourself with 5 minutes of thought, or submit without acknowledging the ambiguity at all.
What mistakes eliminate strong candidates from take-home submissions?
Over-engineering loses to focused solutions
Senior engineers sometimes treat take-homes as architecture showcases. A 2-hour assignment is not the place for a full microservices setup, Docker Compose infrastructure, and full observability coverage. Deliver the simplest solution that works correctly and is clearly organized. "What I'd add with more time" in the README is where you demonstrate architectural thinking, not in the submission itself.
Missing obvious edge cases signals incomplete thinking
If the brief mentions "handle invalid input," handle it. If it doesn't mention it, handle the obvious ones anyway: it signals defensive programming. An unhandled null, an empty array, or an obviously invalid input that crashes the app tells reviewers you didn't think through the problem boundaries.
Ignoring the README costs you points even with good code
A polished README takes 20–30 minutes and significantly improves reviewer first impressions. Companies explicitly discuss README quality in hiring committee reviews. Candidates who skip or minimize the README lose points even when their code is solid.
A broken build is an immediate rejection reason
Test your submission on a fresh clone before sending. "It works on my machine" is not a submission: it's an error. Broken setup instructions, hardcoded absolute paths, or missing dependencies are common rejection reasons that have nothing to do with engineering ability.
Key takeaways
The README is evaluated as seriously as the code
Reviewers read the README before running the code. A clear README that documents assumptions, explains tradeoffs, and outlines what you'd improve with more time shows engineering maturity that the code alone can't demonstrate. Candidates who skip or minimize the README lose points even when their implementation is strong.
Respecting the time estimate is itself an evaluated skill
The company's time estimate is a scoping constraint, not a suggestion. Delivering a focused, working solution within the stated time range demonstrates prioritization ability, a skill directly relevant to the role. Running significantly over suggests difficulty scoping work, which is exactly what senior engineers are hired to do well.
Ambiguity in the spec is intentional: your handling of it is observed
Most take-home assignments leave some requirements underspecified. The company wants to see how you handle incomplete information: do you make reasonable assumptions and document them, ask one targeted clarifying question, or freeze and either overbuild or underdeliver? Your approach to spec ambiguity predicts your approach to real sprint work.
Frequently asked questions
Should I use a framework or write vanilla code for the take-home assignment?
Use the framework specified in the brief. If none is specified, use whatever you're most productive with, noting the choice in the README. If the company primarily uses React and you submit a Vue app, explain the decision. Don't use an unfamiliar framework to impress: it typically results in worse code and more time spent struggling with the tool.
Is it okay to use Stack Overflow or documentation during the assignment?
Yes. Take-home assignments are open-book by design. Treat it like real work. You can use documentation, Stack Overflow, your own past code, and reference implementations. The exception: don't copy-paste complete solutions you don't understand. Interviewers ask you to explain your code in the follow-up interview, and gaps in understanding surface immediately.
What if the assignment takes much longer than expected?
Email the recruiter or hiring manager before the deadline. Explain that you're estimating more time than the brief suggested, and ask if there's flexibility or if you should submit a scoped version by the deadline. Don't exceed the stated time by 3× without communicating. It reads as poor estimation, which is exactly the skill take-homes are partly designed to evaluate.
What if the assignment requires technologies I haven't used?
Tell the recruiter immediately: "I noticed the assignment uses [technology]. I don't have direct experience with it. Is it okay if I complete the assignment using [alternative I know well]?" Most companies are flexible if you ask upfront. They're often more interested in how you approach problems than the specific tool.
Does a take-home assignment mean I'm close to an offer?
Take-homes appear at different stages depending on the company. Some send them early as a first screen (replacing a phone screen); others send them after a recruiter screen and before a full loop. Ask the recruiter where this sits in the process so you can calibrate the expected time investment. If you're running multiple concurrent job searches, use a tracker like Hire.monster to log all take-home deadlines alongside your other interview prep milestones.
Bottom line
- Write the README as carefully as the code: document assumptions, tradeoffs, and what you'd improve with more time
- Scope to the stated time limit. A focused, working solution on time beats an over-engineered partial solution.
- Handle ambiguity by asking one clear clarifying question early, or by documenting your interpretation in the README
- Test your submission on a clean checkout before sending. Broken builds are a common rejection reason that has nothing to do with your engineering ability.
- Track take-home deadlines alongside your applications: Hire.monster's free tracker keeps interview stages organized