The Take-Home Test Filters for Free Time, Not Engineering Ability

The take-home exercise has one property its defenders rarely state: it is the only stage of your hiring process where you cannot verify who did the work. Everything else in the pipeline happens under observation. The take-home does not, and it is simultaneously the stage you weight most heavily.

That was a tolerable trade when the worst case was a friend helping out. It is not tolerable now that a competent model will produce a clean, tested, well-structured solution to most four-hour exercises in a single prompt. The exercise still measures something. It just no longer measures what you designed it to measure.

What the take-home actually selects for

Start with who completes one. A senior engineer with two children and a current job will decline an eight-hour unpaid exercise. A candidate between roles will accept. A candidate with three competing offers will accept from whoever they want most and decline the rest. Your completion rate is therefore inversely correlated with candidate seniority and demand, which is the opposite of what you want.

Among those who complete, the finished artefact tells you less than it appears to. You see the code. You do not see how long it took, which parts were hard, which decisions were considered and rejected, or how much of it came from somewhere else. Two identical submissions can come from a strong engineer working for an hour and a weak one grinding for twelve, and nothing in the repository distinguishes them.

Then there is the polish problem. Take-home submissions are optimised for review, so they arrive with a README, sensible commit messages and reasonable test coverage, because candidates know that is what gets marked. None of that reflects how the person works under a deadline with an ambiguous ticket, which is the condition you are actually hiring for.

The honest summary is that the take-home measures conscientiousness, availability, and familiarity with the conventions of take-home submissions. Those correlate weakly with engineering ability, and the correlation has weakened further as generated code has become indistinguishable from careful code at a glance.

The failure modes are asymmetric

The two ways a hiring filter fails are not equally costly, and the take-home fails in the more expensive direction.

Failure mode	Take-home	Live technical conversation
Strong candidate rejected	Common: they decline the exercise or rush it	Rare: the format costs them an hour
Weak candidate advanced	Common: unverifiable authorship	Rare: probing questions expose depth quickly
Candidate time cost	4 to 8 hours, unpaid	45 to 75 minutes
Your engineering time cost	30 to 60 minutes reviewing an artefact	45 to 75 minutes, in the room
Signal on reasoning	None: only the outcome survives	Direct: reasoning is the thing observed
Signal on collaboration	None	Direct

Note the fourth row. The commonly cited defence of the take-home is that it saves engineering time. It does not save much. Reviewing a submission properly, reading the code, running it, forming a judgement, takes most of an hour. The saving is roughly fifteen minutes of a senior engineer's day, purchased with eight hours of the candidate's and the loss of every signal in the bottom two rows.

What replaces it

The substitute is a structured technical conversation built on code that already exists. Not a whiteboard puzzle, not a live algorithm exercise under a timer, both of which have their own well-documented problems. A conversation with an artefact in the middle of it.

Three formats work, and each takes under an hour.

1. Code reading. Put a two hundred line file from a real codebase, with a real bug in it, in front of the candidate. Ask them to explain what it does, then to find the problem. Reading unfamiliar code is what engineers spend most of their week doing and it is almost never assessed. Strong candidates orient themselves by tracing data flow. Weaker ones read top to bottom and lose the thread.
2. Their own past work. Ask a candidate to bring something they built and walk you through a specific decision inside it. Then push: why that data model, what broke first in production, what they would change now. Nobody can narrate design trade-offs in work they did not do. This is the cheapest authorship check that exists and it takes twenty minutes.
3. Extension under constraint. Give them a small working system and a change request with a deliberate ambiguity in it. Watch whether they ask about the ambiguity or invent an answer. That single behaviour predicts more about how someone performs on a distributed team than any amount of syntax fluency.

The mechanics of running these well, including how to score them consistently across interviewers, are set out in the guide on assessing a developer without a take-home test. The part most teams get wrong is consistency: if each interviewer improvises their own questions, you have replaced an unreliable filter with an unrepeatable one.

Why the cost argument is backwards

The reason organisations keep the take-home is a belief that live assessment does not scale. It scales fine, because the pipeline is narrower than people assume by the time anyone reaches a technical stage. If you are running fifty take-homes a month you have a screening problem upstream, not an assessment problem.

There is also a subtler cost that never appears on the ledger. Every candidate who declines your exercise is invisible to you. You never see their code, never interview them, and never learn that they existed. Your process feels like it is working because you only ever observe the people it did not filter out. A hiring funnel that quietly excludes senior, employed, in-demand engineers will look healthy right up to the point where you notice the team is junior.

This is worth thinking about when you are choosing how to add capacity at all. If assessment is the bottleneck, one option is to change the assessment; another is to change who does it. The trade-offs between running your own hiring versus taking a team that comes pre-assessed come down to where you want the selection risk to sit. Working with a dedicated development team moves that filtering upstream, though it does not remove your responsibility to evaluate the people you get. Ask any partner how they assess, and treat a take-home based answer as a signal in itself.

Whatever route you take, the assessment question does not end at hire. The same evidence that tells you whether someone can reason about unfamiliar code tells you whether they will be able to hand it over later, which is why planning knowledge transfer and exit before you need it belongs in the same conversation as hiring rather than eighteen months after it.

What to change first

Run the arithmetic on your own funnel. Count how many candidates were sent a take-home in the last six months and how many returned one. If completion is below seventy per cent, the exercise is your largest source of candidate loss and you are losing from the top of the distribution, not the bottom.

Then pick one of the three formats above, write down five questions in advance, and run it in parallel with your existing exercise for a month. Compare the rankings. If the live conversation and the take-home disagree, the disagreement is where all the useful information is, and it is almost always the take-home that was wrong.