The Reasonable Take-Home Standard, and What Fails a Cap

This is a gradeable standard for one decision a candidate makes under time pressure: which take-home assignments to do, and how many hours one is worth. It is written for anyone facing a coding challenge, a product exercise, or an open-ended "build this and send it back" brief, and it gives you a fixed cap, a scope check, and a clear line for when the work should be paid. Read it once, adopt the checklist, and you can grade any incoming take-home the same way twice.

A take-home assignment is unsupervised work a candidate completes on their own time and submits for evaluation. The trouble is that the brief almost never describes the real cost, and the real cost is where candidates get exploited or quietly filtered out. A standard fixes that: it turns "does this feel reasonable" into criteria two people would grade the same way.

What makes a take-home reasonable

A take-home is reasonable when it fits inside a stated time cap of roughly two to three hours, tests a competency the job actually uses, and produces nothing the company can ship. Everything past that line moves toward unpaid labor, and you should either get it paid or decline it.

The most-cited practitioner threshold is two hours. A DEI consultant writing for RecruitingDaily recommends a two-hour limit specifically to avoid equity issues, and recommends paying candidates for anything longer. A separate hiring guide frames the ceiling as "under two to three hours of real effort" and, importantly, says to evaluate against the stated cap so that someone who stopped at the limit is not penalized against a candidate who spent ten hours polishing. A named practitioner writing for Dscout aims for about three hours with a one-week completion window.

So the reasonable band is narrow and well-attested. The failure is not usually a brief that asks for eight hours in writing. The failure is a brief that says "two hours" and costs eight.

The three tests, stated so they can be graded

A take-home passes the standard only if all three hold. Each test names what it proves and what it looks like when it lies to you.

The relevance test matters because it is not fair to ask candidates, who may have limited knowledge of your company or industry, to solve your specific problems. If you cannot name the competency the task measures, the task is measuring your patience.

The cap is a floor, not a ceiling

The stated cap tells you the least the task will cost, not the most, because effort on a take-home is unbounded and ambition sets the real time. This is the single most important thing to internalize before you agree to anything.

The evidence is consistent. One hiring manager who kept a take-home in the process and asked candidates how long they actually spent got answers ranging from 4 to 12 hours on a task billed as short. A named product manager described a task pitched as "an hour or two" that ran to several hours each night for a week plus at least eight hours the final day, for a total of 20 to 30 hours. The mechanism is plain: the company can say it only wants two to three hours, but someone trying to nail the interview will put in as much as they can.

That means the brief's number is not a promise about your evening. It is the company's stated preference, which no one enforces. Your only defense is a personal hard-stop, which is why the procedure below timeboxes execution and submits at the cap with assumptions documented rather than chasing completeness.

The stated cap tells you the least a take-home will cost, never the most, because no one enforces a stop.

Here is the same idea as the shape of the problem: the brief points down, real effort points up.

Setup is the real tax, not the problem

The hidden cost of most take-homes is environment setup and unfamiliar tooling, not the problem itself, so screening the tooling before you agree is higher-leverage than screening the question. Scope this in Step 3 or you will lose the cap before you write a line of the actual answer.

One candidate reported spending 5 hours on environment setup and another hour watching tutorials on the company's tools, all before starting the "1-2 hour" data task itself. That is not perfectionism. That is a brief that quietly assumes you already run their exact stack.

Before you commit, answer three questions in writing:

• What has to be installed or configured? If the answer is a full local environment for a stack you do not use daily, the setup alone may exceed the cap.
• Which tools are unfamiliar? Tutorials count against your time even though the brief never mentions them.
• Can you finish setup in a fraction of the cap? If setup is more than a quarter of the stated cap, the real task cannot fit inside the cap.

When a take-home should be paid

A take-home should be paid when the work benefits the business or resembles a multi-day build, because in US law the load-bearing question is benefit to the business, not the word "unpaid." Short hypothetical exercises are the normal, unpaid step. Value-adding output is compensable.

The FLSA, enacted in 1938, establishes minimum wage, overtime for hours worked beyond 40 per week, and recordkeeping requirements. Employment attorneys draw the line at benefit: they advise using non-served hypotheticals, the equivalent of asking a chef to cook a meal that is not sold, so the business gains nothing from the unpaid work. When a candidate performs actual work that adds value, minimum wage generally applies, and the designation "voluntary" does not negate labor law if the individual's work added value.

The practical threshold for you:

One documented case shows the shape of exploitation: a candidate reported doing 7 to 10 days of unpaid product "consulting" work for a single company and then not being hired. That is not a take-home. That is free consulting wearing a take-home's clothes.

The seven-step decision

Run this in order the moment a take-home arrives. Steps 1 through 5 are the decision; steps 6 and 7 are how you execute once you have decided to do it. The whole decision costs about an hour, which is cheap insurance against a 20-hour mistake.

On the last two steps, the difference between candidates who get hired and those who do not is a mindset shift from "task completion" to "problem framing." The strong ones use the assignment to show the hiring manager exactly how they would approach a complex problem on day one. Include a README that explains your approach and reasoning, and ask clarifying questions in writing even on a take-home. Building exactly what is written, without asking anything, is a documented way to get rejected for not probing the requirements.

A script for negotiating scope

When the ask exceeds your threshold, do not refuse flatly and do not silently overspend. Offer a cheaper way to prove the same thing.

Thanks for the brief. I want to give this a fair shot and also respect both our time.

As written, this looks like it runs well past the couple of hours a take-home usually takes once setup is included. Two options that work well for me:

1. I'm glad to walk you through my approach to this exact problem live, on a call, showing how I'd frame and solve it. No prep cost to either of us.

2. If you'd prefer a built artifact, I can produce a focused version capped at [2 hours]. Anything beyond that starts to resemble project work, which I'd ask to have compensated.

Happy to proceed either way. Which fits your process best?

Where the take-home should sit in the process

A take-home belongs after a recruiter screen or first interview, once you have shown baseline interest and fit, but before a full interview loop. A take-home requested before any human conversation fails the standard and is worth declining or deferring.

Consensus is clear on placement. Most teams put a take-home after an initial screen, once a candidate has shown baseline interest, but before investing in a full loop. A named product writer argues it should come even later, once both sides feel the role is a plausible fit. The reason is symmetry: neither side should sink hours before establishing that the match is worth exploring.

There is genuine disagreement worth naming. Some staffing practitioners advise clients against take-homes entirely for competitive markets, on the grounds that strong candidates simply drop out. That disagreement is your leverage. When you decline a badly-placed take-home, you are on the same side as recruiters who think the practice loses good people. One candidate who was asked to do a home assignment before even interviewing declined outright, reasoning that it made no sense to invest before knowing whether the role was even a fit.

How this goes wrong

The standard exists mostly to catch the cases where a take-home looks reasonable and is not. These are the failure modes and the false positives that make each one hard to spot. This is the section to reread before you accept anything.

Trusting the stated estimate. The brief says two hours, so you plan two hours. The lie: setup and tooling are invisible in the estimate. Check by scoping setup first; documented cases ran 5 to 12-plus hours.

Perfectionism inflation. You tell yourself you "chose" to spend 20 hours. The reality: motivated candidates over-invest by roughly an order of magnitude regardless of the cap. Check by setting a hard stop at the cap and submitting what you have.

Company-specific free consulting. The task feels like real, current business work, which flatters you into doing it. Check by asking whether solving it produces something the company could ship. If yes, treat it as paid work.

Assuming "unpaid" is always legal. The brief calls the work voluntary, so you assume it is fine. Check the mechanism instead: value-adding work can trigger minimum-wage obligations regardless of the label.

Skipping requirement-teasing. You build exactly what is written and get rejected for not asking questions. Check by sending clarifying questions in writing even on a take-home.

Availability bias against you. An unemployed rival polishes for a week; you stop at the stated time and look weaker by comparison. The longer the completion window, the more it favors candidates with free time. Check by confirming they grade against the cap, not against maximum effort.

Doing it too early. An assignment lands before any human conversation. Check placement: decline or defer until at least a screen.

Your leverage depends on the market

Your ability to decline or counter a take-home scales with how deep the candidate pool is for your role, so read the supply before you push back. Deep supply cuts both ways: the employer has substitutes, but so do you, and an exploitative multi-day unpaid ask is one you can walk from.

In Refolk's index of professional profiles, the US software engineering pool is large and the senior tier is more than half of it. That depth is why a candidate can reasonably decline an exploitative ask: there are other roles, and the exploitative employer is choosing to burn goodwill in a market full of alternatives.

Market thinness abroad changes the calculus. In Refolk's index, Germany shows only 21,647 "Software Engineer" profiles against roughly 16 times that in the US. In thinner markets employers have more incentive to keep take-homes short to avoid drop-off, which means your counter for a shorter or paid task lands on more receptive ears. Knowing where you sit in the supply tells you how hard to push.

If you want to see who has actually navigated these rounds before you commit, Refolk turns a plain-language ask into a list of real people you can learn from or reach out to.

The rise of skills assessment, and why the standard matters more

Skills-based hiring is rising, so you will face more assessments over time, which makes a repeatable rule for grading them more valuable, not less. The specific prevalence of unpaid coding take-homes is not established publicly, so treat the trend as directional.

Among employers in NACE's Job Outlook 2026 survey, 70% report using skills-based hiring, up from 65% the prior year. Adjacent survey data points the same direction, though from different populations and so not a single clean series.

Read these as directional, not as one trend line, because they come from different surveys and populations. The takeaway is only that assessments are becoming a more common gate, which is exactly why a fixed personal standard beats deciding case by case under pressure.

The verification checklist

Run this before you accept a take-home and again before you submit. If any item fails, go back to the matching step. Refolk uses the same discipline when it tailors an application: verify against the record before you send.

Keeping the standard current

The numbers in this guide are stable, but re-check two things whenever you use it. First, the legal line: whether a specific take-home is compensable is fact-specific and turns on benefit to the business, so confirm your own jurisdiction's rule before relying on the FLSA framing here, since state law can add requirements. Second, your own cap: if you keep blowing past two or three hours on tasks you accepted, the problem is your screen in Steps 1 through 4, not your discipline in Step 6. Tighten the scope check, not the all-nighter.

The standard's whole job is to make one decision boring. When a take-home arrives, you should not deliberate about whether it is fair. You should run the three tests, size the market for your leverage, and either timebox it or send the scope counter. That is what a document you keep open is for.