In short
A take-home test is a price you charge a candidate before they are allowed to be considered, and senior engineers with other options decline to pay it. In 2026 it is also a weaker signal than it was, because a model will help anyone produce the visible part. Replace long exercises with a short working session on a real problem.
Most hiring teams think of the technical exercise as something they give a candidate. The candidate experiences it as something they are asked to pay, in evenings, before anyone has committed to anything in return.
That framing matters because it tells you who stops paying first. An engineer between jobs will do an eight-hour exercise. An engineer who is happily employed, has two other conversations running and is the person you most want, will not. So a long take-home filters for availability rather than quality, and quietly removes the strongest part of your pipeline before you ever see them.
The signal got worse while the price stayed the same
The exercise used to buy you something real: a sample of how a person structures code when nobody is watching. That sample has degraded. A 2026 Karat survey of 400 engineering leaders found 71 per cent believe technical skills have become harder to assess, with take-home signal rated as degrading fastest of any method.
The reason is not mysterious. The visible output of most take-homes, a working service with tests and a tidy README, is exactly what a model is good at helping produce. What the exercise was meant to reveal, how someone decides what to leave out, what they do when the requirements are ambiguous, how they reason about a failure, never appeared in the submission anyway. It appeared in the conversation afterwards, if there was one.
So the trade has moved against you on both sides. The candidate pays the same eight hours. You learn less from what they send.
A long take-home selects for the engineers with a free weekend.
What candidates say about it
In our own conversations the same complaints come up repeatedly, and none of them is "it was too hard". They are about ambiguity and proportion. Exercises where the scoring was never explained, so the candidate could not tell whether to optimise for polish or speed. Case studies that grew into a small consulting engagement. Practical tasks in an unfamiliar format with no indication of what good looked like.
The pattern that works, by contrast, is also consistent: a fast process where the candidate understood what was being assessed and heard back quickly. Talent Board's candidate experience research puts poor communication alone as enough to make 47 per cent of candidates withdraw, and an exercise with no stated criteria is poor communication in its purest form.
What it costs you
The candidate's time is not the only cost. A take-home adds calendar days, usually a week for the candidate to find the time and a few more for someone on your team to review it. Those days are not free.
For a senior software engineer in Sydney at the AUD 160-190k band, the fully loaded cost at the midpoint is about AUD 210,788 once superannuation, NSW payroll tax and other on-costs are in. On the conservative assumptions in our cost of vacancy calculator, the open role costs roughly AUD 11,018 a week in output not produced and time absorbed by the team covering it. A take-home that adds ten working days to the process costs about AUD 22,000 before you have learned anything, and that is before counting the candidate who took another offer in the meantime.
Those figures rest on assumptions you can argue with, and the calculator lets you put your own in. The point survives any reasonable version of them: the exercise is not free for you either.
What to do instead
You still need evidence that someone can do the work. The question is how to get it without charging the candidate a weekend for a weak signal.
- A paired working session, 60 to 90 minutes. A real problem from your codebase or a close relative of one, worked through together. You see how they read unfamiliar code, what they ask, and how they change course, which is most of the job and none of it is in a submission.
- A code review instead of code writing. Give them a pull request with real flaws and ask for the review they would leave. It takes under an hour, it is very hard to outsource to a model convincingly in the room, and it tells you a great deal about judgement.
- A design conversation about something they built. Their system, not yours. Ask what broke, what they would change, and what they deliberately did not build. People who did the work have specific, slightly weary answers.
If you keep a take-home
Some teams have good reasons to, particularly for early-career roles where there is less track record to discuss. If yours is one of them, make it a fair trade:
- Cap it at two hours, and mean it. If your honest estimate is longer, the exercise is too big.
- Say how it is scored before they start. Polish or speed, tests or features, whether a partial solution counts.
- Pay for anything longer than a couple of hours. It changes who will do it, and it signals that you value the time you are asking for.
- Give written feedback whatever the outcome. A candidate who spent an evening on your problem is owed more than a template rejection.
- Discuss it in the next round. The conversation about the submission is where the signal lives, so a take-home with no follow-up is time spent for almost nothing.
The same logic applies to the advert that comes before any of this. If you want the job description checked for the phrases that cost you applications, the JD grader scores it and names the phrase behind each point lost. It is rule-based, so the same advert always scores the same, and it runs entirely in your browser.
FAQ
Are take-home coding tests still worth using in 2026?
Rarely for senior roles. They cost candidates evenings before anyone has committed to them, which removes the engineers with the most options first, and the signal has weakened because a model can help produce the visible output. A 2026 Karat survey of 400 engineering leaders found take-home signal was degrading fastest of any assessment method. A short paired session or a code review exercise usually gives better evidence in less time.
How long should a take-home test be?
No longer than two hours of genuine work, with the scoring criteria stated before the candidate starts. If your honest estimate is longer, the exercise is too large. Anything beyond a couple of hours should be paid, and every submission should get written feedback and a follow-up conversation, since that conversation is where most of the useful signal is.
What is a good alternative to a take-home test?
A 60 to 90 minute paired working session on a real problem, a code review exercise where the candidate reviews a pull request with genuine flaws, or a design conversation about a system the candidate built. All three show how someone reasons, reads unfamiliar code and handles ambiguity, which is most of the job and rarely visible in a take-home submission.
How much does a slow technical assessment cost an employer?
For a senior software engineer in Sydney at the AUD 160-190k band, an open role costs roughly AUD 11,018 a week on conservative assumptions about lost output and the time the team spends covering it, so an exercise that adds ten working days to the process costs about AUD 22,000. The figure depends on assumptions you can change in a cost of vacancy calculator, and it excludes the cost of a candidate accepting another offer while waiting.