Your best candidates are the ones with the least free time. They already have a job, probably a good one, and they are talking to two or three other companies. So when your process hands them a take-home assignment that "should take four to six hours" (it takes ten), you have just built a filter that removes exactly the people you wanted to keep.
This is not an argument against work samples. A well-designed exercise is still one of the most predictive tools in hiring. The problem is the default version most teams ship: too long, too vague, and scored by whoever happens to be free. Here is how to fix it.
First, admit what the assignment actually costs
Run the math on a typical funnel. If you send a six-hour assignment to twenty candidates, you have asked for 120 hours of unpaid work to fill one seat. Half of those people will quietly drop out, and the half that drop are disproportionately the employed, the senior, and the parents.
Now compare that to what you learn. Most take-homes are reviewed for twenty minutes by an engineer who skims the README and runs the tests. The ratio of candidate effort to signal captured is badly out of balance, and candidates can feel it.
Cap it at two hours, and mean it
The single highest-impact change is a hard time limit that you actually enforce in the design of the task. Two hours is enough to see how someone structures a problem, names things, handles an edge case, and explains a tradeoff. It is not enough to build a full application with authentication, and that is the point.
To keep the cap honest, ask candidates to stop at two hours and write a short note on what they would do next. That note is often more revealing than the code. It shows prioritization, self-awareness, and whether they can communicate unfinished work, which is what real engineering looks like most days.
Make the task look like the job
Generic puzzles test puzzle-solving. If the role involves cleaning messy data, hand over a messy dataset. If the role involves working inside an existing codebase, give them a small repo with a bug and a feature request rather than a blank file.
This does two things. It makes the exercise a preview of the work, so candidates can self-select in or out with accurate information. And it gives your reviewers something they can evaluate against a real standard instead of personal taste.
One caution: never use a live problem your team is currently stuck on. Candidates notice, and it turns an assessment into free consulting.
Write the rubric before you send the first assignment
If you cannot describe what a strong submission looks like in advance, you are not ready to send the task. Sit down with the hiring manager and write four or five criteria with a plain description of what "meets the bar" means for each one. Correctness, readability, handling of edge cases, communication in the write-up, and reasonable use of time is a solid starting set.
Then have two reviewers score the first few submissions independently and compare. If they disagree by more than a point on any criterion, the rubric is unclear, not the candidate. Fix the wording and try again. Consistency between reviewers matters more than any single reviewer's expertise.
Pay for anything longer than the cap
Some roles justify a deeper exercise. Senior and staff positions, design roles with a portfolio component, or specialized technical work sometimes need more than two hours to evaluate properly. If that is the case, pay for the time.
A modest stipend changes the dynamic completely. It signals respect, it keeps employed candidates in the process, and it forces you to be disciplined about who receives the assignment. Teams that pay for take-homes send far fewer of them, and the ones they send are to candidates they are serious about.
Give every candidate a debrief, including the rejected ones
Most companies send the assignment, go silent for a week, and then send a one-line rejection. Candidates who spent a weekend on your task will remember that, and they will tell their friends.
Instead, commit to a short written debrief for everyone who submits: two or three sentences on what was strong and one specific thing that would have improved the result. It takes a reviewer five minutes. For candidates who advance, the debrief becomes the opening of the technical interview, which is a far better use of that conversation than re-explaining the code.
Offer a live alternative
Not everyone does their best work alone at a kitchen table at 11pm. Some strong candidates freeze on open-ended asynchronous tasks and shine in a paired session. Offering a choice between a two-hour take-home and a 90-minute live pairing exercise, scored on the same rubric, widens your funnel without lowering the bar.
It also produces a useful data point. If a candidate picks the live option, you get to see how they think out loud, ask questions, and respond to hints. That is information a take-home can never give you.
What to measure once you change it
After you shorten and restructure the assignment, track three numbers for the next quarter: completion rate (how many candidates who receive the task actually submit), reviewer agreement (how often two scorers land within a point), and offer acceptance rate for candidates who went through the new version.
If completion rises, agreement tightens, and acceptance holds or improves, the change is working. If completion rises but agreement stays loose, the rubric needs another pass. Either way you will know, which is more than most teams can say about their current assessment.
The goal is not to make the exercise easy. It is to make it fair, short, and genuinely useful to both sides. Candidates will do a small amount of work for a company that clearly respects their time; they will not do a large amount of work for one that does not.