How Long Should a Take-Home Coding Assignment Be?
The short answer
Screen stage: 60–90 minutes, hard cap. Onsite stage: 2–3 hours if you must use a take-home; otherwise prefer live formats at this stage. Final stage: never. Senior candidates should not be doing 4-hour take-homes for a final-round.
These numbers assume the candidate is following the time cap. In practice many candidates spend 1.5–2× the stated time. Design your task assuming the stated cap, and trust the rubric to handle variance.
Why under 90 minutes for screen stage
Three reasons:
- Pipeline width. Every additional 30 minutes of take-home time drops your conversion rate from invitation to submission by roughly 5–10 percentage points, with bigger drops at the high end.
- Variance in time spent. Longer take-homes have higher variance in actual time spent, which means you're measuring availability as much as skill.
- Marginal signal. A well-designed 90-minute test produces 80% of the signal a 4-hour test would. The remaining 20% is not worth the candidate cost.
When longer is appropriate
- Onsite-stage paid assignments. A 4–8 hour scoped project, paid at a fair rate, late in the loop, optional. Some teams use this for senior+ roles to replace a half-day onsite. Acceptable if paid and optional.
- Trial weeks. Different category. Reasonable for senior hires with notice periods, executive roles, or contract-to-hire arrangements.
- Roles that genuinely require an artifact. Some roles (technical writing, design) need a portfolio-style artifact at the screen stage. Even then, scope to 3 hours max.
What to fit in 60–90 minutes
A scoped task with one clear deliverable:
- Add a feature to a provided codebase
- Fix three documented bugs
- Analyze a provided dataset and produce a 1-page writeup
- Refactor a provided messy module with a stated goal
Avoid open-ended scope ("build a small app to do X"). Variance in scope interpretation will kill your rubric.
What to do about the time cap
Ask candidates to track and self-report time spent. Believe them, but rubric-anchor: a candidate who self-reports 90 minutes and produces 4 hours of polished work has effectively spent 4 hours. The rubric should reward the right amount of completion for the stated time.
ClarityHire timestamps assessment sessions and surfaces the actual elapsed time alongside the candidate's self-report. The discrepancy is signal: not in the punitive sense, but as context for the reviewer.
What never to do
- "We expect 4–8 hours of work." This is a polite lie. The candidate either spends it (and you lose them to faster competitors) or doesn't (and you've miscalibrated).
- "Open-ended, take as long as you need." Worst possible framing — encourages the most engaged candidates to overspend.
- "We'll evaluate based on quality, not speed." Means the candidate optimizes for polish over signal, which is the wrong incentive.
The structural alternative
If you find yourself wanting longer take-homes, the underlying need is usually "I want to see real engineering judgment, not just a small fix." The right response is rarely "make it longer." It's usually "add a walk-through interview."
A 90-minute take-home + 30-minute walk-through produces dramatically more signal than a 4-hour take-home alone. The walk-through tests the candidate's reasoning about their own work — which is what the longer take-home was implicitly trying to measure. Get there directly.