The take-home assignment is the interview format with the worst stated-vs-actual time discrepancy. "A few hours" routinely means 8-15. "Two-hour challenge" frequently absorbs a weekend. The companies issuing them rarely measure how long they actually take, and the candidates doing them are usually too anxious to push back on the framing.

This post is the practical handling: how to scope before you start, how to set a hard ceiling, when to cut scope rather than extend time, and the small number of cases where declining is the right call.

What the stated time actually means

The stated time is almost always the time the engineer who designed the take-home spent solving it once they already knew the answer. It doesn't include reading the brief carefully, asking clarifying questions, environment setup, formatting, writeup, or the polish pass that separates a passable submission from a strong one.

A "four-hour take-home" in practice breaks down roughly as: 1 hour reading and scoping, 1 hour setup, 4 hours actual work, 3 hours polishing and writeup, 2 hours review. That's 11 hours, and it's not because the candidate is slow. It's because the stated estimate omits everything except the core work.

The implication: if the company says 4 hours, the honest math is closer to 8-12. Budget accordingly. Companies that say "8 hours" mean 16-20. There are honest exceptions — well-designed take-homes that come close to the stated time — but they're the minority.

The decision flow before you start

A working approach starts before the keyboard. Five gates:

Confirm the time budget in writing. "Just to confirm — the team estimates 4 hours and there's no hard deadline beyond submitting by Friday?" Locks in the expectation. Gives you something to point at if the assignment turns out to be much larger than stated.

Ask 1-2 scoping questions. "Should I optimize for breadth or depth?" "Is there a specific stack you'd like me to use, or can I pick?" The questions accomplish two things at once: they save hours of guessing later, and they signal that you read the brief carefully — which most candidates don't.

Set a hard ceiling at 2x the stated time. If they said 4 hours, cap at 8. Beyond 2x, the marginal hour rarely improves the rating. The reviewer can usually tell whether a submission was 4 or 8 hours of work; they often cannot tell whether it was 8 or 16. The extra time mostly improves your own anxiety, not your rating.

Cut scope before extending time. If you're over budget at the 80% mark, ship a smaller, cleaner version with a "what I'd do next" section. Reviewers consistently reward judgment about scope more than they reward brute-forcing completeness. "Here's the core; here are three things I'd add next" reads as senior; "I tried to do everything and it's half-done in three places" reads as junior.

Submit with a brief writeup. One or two paragraphs: what you built, what you'd add with another 4 hours, one specific tradeoff you made. This is where strong candidates separate from passable ones. The work demonstrates ability; the writeup demonstrates judgment.

When it's reasonable to decline

Most take-homes are worth doing if the role is interesting and the company isn't otherwise red-flagged. But a small set of cases are reasonable to decline or counter:

Take-homes that exceed 8 stated hours. Beyond this point, the opportunity cost (another company's loop) usually exceeds the marginal information the company gets. A working counter: "I'd love to do the take-home but my schedule is tight given other loops. Could we substitute a 60-90 minute live working session?" About half of companies accept the swap; the ones that don't are revealing something about how they treat their employees' time.

Take-homes that are clearly disguised work. "Build us a small version of this real feature we're considering shipping" is the canonical case. The company is getting free work and has no obligation to evaluate it fairly. Decline cleanly: "I'd be happy to do a synthetic version of this problem rather than work on a live feature."

Take-homes after a single phone screen. A 4-hour ask before the company has invested any of their own time is asymmetric. Counter: "I'd be glad to do this after we've had a chance to talk through fit. Could we schedule a 30-minute call first?"

For the broader phone-screen prep that precedes most take-homes, see phone-screen-what-recruiters-evaluate.

How to actually finish

A few mechanics that consistently help:

• Timebox the setup. If environment setup is taking more than 90 minutes, you're optimizing the wrong thing. Use whatever tooling lets you start the actual work fastest.
• Write the README first. Even a draft. It forces you to clarify the scope you've committed to and exposes scope creep early.
• Ship a checkpoint at the time-budget midpoint. A working but minimal version. Anything beyond that point is polish on a working submission rather than a desperate sprint to make something work.
• Sleep before submitting if possible. A 30-minute morning review catches the embarrassing errors that the tired-evening-you missed.

What the writeup actually does

The 1-2 paragraph writeup is the highest leverage component of the submission. A working structure:

• One sentence on what you built. "I implemented a small REST API that handles CRUD on the resource described, with basic input validation and unit tests on the core paths."
• One sentence on the most interesting tradeoff. "I chose to keep the storage layer in-memory rather than wire in a real DB because the test scope doesn't require persistence, and the abstraction is set up to swap in if needed."
• One sentence on what you'd add next. "With another 4 hours I'd add pagination, integration tests against a real DB, and rate limiting on the write endpoints."

Reviewers read this writeup before the code. The candidate who can articulate scope choices reads as senior even when the code is comparable to other submissions.

What this isn't

A few clarifications:

• It's not a license to skip the brief. Reading the brief carefully, twice, is the highest-ROI hour of the whole exercise. Most candidate failures here are misreads.
• It's not graded on completeness. Reviewers grade on judgment, scope choices, and code quality more than on feature count. A polished 60% is usually better than a chaotic 95%.
• It's not a place to show off unusual tools. Use what you know best. Take-home is not the place to learn Rust because you've heard the company likes it.

The short version: confirm the time, scope it, cap at 2x, cut scope before extending time, include a writeup. Decline the few cases where the ask is unreasonable. The work is graded on judgment as much as on output — and judgment is what most candidates don't budget time for.