The take-home exercise arrived as a fix for a real problem. Whiteboard interviews measured whether someone could perform algorithms under social pressure, which is not a thing most jobs require. Letting candidates write code at their own desk, in their own editor, on a problem resembling actual work, was obviously better.
Then it grew. Four hours became a weekend. "Just build a small service" became a brief with acceptance criteria. And the thing being measured quietly changed from can they do the work to how much unpaid time can they spare.
Who fails a six-hour task
Not the people you think. Consider two candidates with identical ability. One is between jobs, lives alone, and has a free Saturday. The other has a full-time job, a four-year-old, and about ninety minutes after bedtime on a good day.
The second candidate submits something rushed, or asks for an extension, or withdraws. None of those outcomes tells you anything about how they would do the job — where they would have eight hours a day, colleagues, and no artificial deadline. You have measured their domestic circumstances and recorded the result as a technical score.
This is not a hypothetical failure mode. It is the most predictable consequence of the format, and it lands hardest on exactly the candidates most hiring processes claim to be trying harder to reach.
The other failure: you cannot tell who wrote it
A take-home is an unsupervised assessment with no record of how the work happened. You get an artefact. You cannot see whether it took forty minutes or fourteen hours, whether a friend helped, or whether it came out of a model in one shot.
Every mitigation makes it worse. Ban AI assistance and you are asking for a promise you cannot verify while testing a skill the job no longer requires in isolation. Add a follow-up interview to check they understand their own submission and you have added the interview back on top of the task, which is the cost you were trying to avoid.
What to do instead
Three changes, in order of how much they help.
Cap it at forty-five minutes and mean it
Not "should take about an hour" — a task you have watched three of your own engineers finish inside the limit. If you cannot assess someone in forty-five minutes, the problem is the task design, not the duration. Long tasks are usually long because they are vague.
Make it a real thing, small
The best short task is a bug in code the candidate has not seen, with a failing test. It measures reading unfamiliar code, forming a hypothesis, and fixing without breaking anything else — which is what the job is, most days. It cannot be answered from memory, and a model helps roughly as much as it would help on the actual job.
Watch the process, not just the artefact
Run the task in an environment that records how it went: when the tests were run, what changed between runs, where the time went. Not to catch anyone out — to see the thing you actually care about. A candidate who wrote a failing test first, watched it fail, then fixed it, has told you more than a green checkmark ever will.
Then say so, plainly, before they start. Candidates are fine with a recorded session. What they resent is discovering afterwards that they were being watched in ways nobody mentioned.
Pay for anything longer
If the task genuinely needs a day, pay for the day at a contractor rate. Some teams find this clarifies things immediately: a task worth £400 of someone's time gets scrutinised in a way a free one never does, and usually gets shorter.
The one thing worth keeping
The instinct behind take-homes was right. Watching someone write code in conditions resembling their job predicts performance far better than watching them recite complexity classes at a whiteboard. Keep that. Drop the part where the price of admission is a free weekend.