Take-Home Coding Assignments: How Much Time Is Too Much?

You just got the email. Take-home assignment attached. Estimated time: two to three hours. You open it and it is a full CRUD app with authentication, a test suite, a README, and a deployment link. Three hours, sure. If you already had this exact app half-built somewhere.

Every contractor who has been in the market longer than a year has a version of this story. The question is never whether take-homes exist. They do, and some are genuinely useful signal. The question is where the line sits between a fair skills check and a company quietly outsourcing a sprint's worth of work to unpaid candidates.

This is an opinion piece, and the opinion is simple: most take-homes are scoped by people who have never had to complete one under real-life constraints. Here is how to tell the difference, how to push back without torching the opportunity, and when the only correct move is to walk.

Do the math the hiring manager didn't

A stated two-hour take-home rarely takes two hours. Add reading the prompt twice, setting up the environment, writing tests you were not told were optional, second-guessing your architecture, and polishing a README because you know it is being judged too. Real elapsed time is often double the estimate.

Now multiply that by how many assignments you are juggling this month. If you are actively interviewing at four places and two of them hand you a five-hour assignment, that is a part-time unpaid job stacked on top of your actual life. Nobody is compensating you for that math, and nobody will unless you name it.

Where the line actually is

There is no universal legal cap on take-home length, so this is a judgment call — but experienced consultants converge on similar numbers.

• Under 90 minutes: Reasonable for almost any level. A focused problem that tests reasoning, not stamina.
• 90 minutes to 3 hours: Acceptable for senior or highly specialized roles, especially if the company is transparent about time-boxing and does not expect production polish.
• 3 to 5 hours: Borderline. Ask why. This is where most red flags live.
• Over 5 hours, or open-ended: Treat as a warning sign, not a challenge to rise to.

What the assignment asks for matters more than the clock

A tightly scoped 90-minute problem that asks for genuine judgment can tell a team more than a sprawling 6-hour app. Time is only half the signal. The other half is whether the deliverable resembles real client-billable work.

The tell: does this look like real client work?

Here is the test that cuts through most of the ambiguity: would this deliverable be usable, as-is, in a production codebase or client demo?

If your assignment lands mostly in the right column, that is not a tough interview. That is unpaid interview work, and it deserves pushback.

How to push back without losing the opportunity

Pushing back does not mean refusing. It means negotiating scope like the professional you are being hired to be. Most reasonable hiring managers respect a candidate who manages scope — it is literally the job.

• Ask for the time estimate in writing, then hold them to it. Try: Happy to complete this. Can you confirm the expected time investment so I can plan around my current contract?
• Propose a scoped alternative. Try: Given the depth of this prompt, would a 90-minute version focused on [core skill] work as well for evaluation purposes?
• Offer a walkthrough instead of a build. Try: I have similar work in my portfolio — could I walk your team through the architecture and decisions live instead of building new?
• Ask what happens to the code afterward. A company with nothing to hide will tell you plainly it's deleted or ignored post-review.
• Name the stakes directly if needed. Try: I want to be a strong candidate, but I'm also mid-contract and can't commit more than two hours without compensation. Is there flexibility here?

None of this is confrontational. It is exactly the kind of scope conversation you would have with a client who asked for "just a small change" that was actually a rebuild.

When to just walk

Some situations do not deserve a negotiation. They deserve a polite decline.

• The assignment is functionally identical to a real, unsolved problem on the company's roadmap.
• Nobody can tell you how it is scored, by whom, or against what rubric.
• You have already done two rounds of interviews and this is round four, not round one.
• The recruiter gets defensive or vague when you ask about scope or time.
• The role is senior or staff-level and the "screen" ignores your track record entirely.

Walking away from a bad process is not burning a bridge. It is data. A company that treats candidate time carelessly before you sign anything will very likely treat contractor time carelessly after.

The one thing to remember

A take-home assignment should test whether you can think, not whether you are desperate enough to work for free. If the ask exceeds two to three hours without a clear, specific reason, it is fair — expected, even — to ask for less, ask for pay, or ask to pass. The strongest signal you can send a hiring team is that you value your own time exactly as much as they should value it.

Navigating vendor screens, technical loops, and assignment scope creep is easier with a staffing partner who has seen the pattern across hundreds of engagements. The Josh Pros LLC team helps consultants vet opportunities before they burn hours on them — reach out at contact@joshpros.com or visit https://joshpros.com if you want a second opinion on your next offer.

#TakeHomeCodingAssignment #ITInterviewAssignment #UnpaidInterviewWork #TechContracting #ITStaffing #JobSearchTips #TechInterviews #ContractConsultants #CareerAdvice #SoftwareEngineering #InterviewPrep #JoshProsLLC

Back to all insights