A code assessment has two jobs and they pull against each other. It has to tell you something about how a person works, and it has to be worth doing for someone who has other offers. Most tests are designed as though only the first job exists.
Why the traditional test loses people
The familiar format is an algorithm puzzle under a timer, on a platform that takes the code away at the end. It is cheap to administer, which is why it spread, and it selects for recent interview practice more than for engineering.
The cost lands unevenly. Someone between jobs will grind through it. Someone employed, well-regarded and quietly curious about you will not, and that second group is the one you were hoping to reach.
Test the job, not the interview
Work sample tests, meaning tasks drawn from the actual work, have held up across decades of validity research, though the updated meta-analysis puts their predictive power more modestly than the older literature did.
Most engineering work is reading before it is writing: understanding code someone else left, finding where a change belongs, making it without breaking the things around it. A test that starts from an empty file skips all of that.
- Give them a small existing codebase and a change to make in it.
- Include one thing that is mildly wrong, and do not mention it. Whether they notice is more informative than whether they finish.
- Ask for a short note on what they would do next with more time. This is where judgement shows.
- Allow documentation, search and an AI assistant. You are hiring someone who will work with all three.
Be honest about the time
State a budget, design for it, and say plainly that you do not expect work beyond it. Then check that the task actually fits by doing it yourself, or by asking someone on the team to. The gap between the stated time and the real time is the fastest way to lose the goodwill of the people you want.
If it takes a weekend, it is not an assessment
It is unpaid work with a selection effect. The people who can give you a weekend are not the people who are hardest to hire.
The question you cannot avoid any more
Candidates have AI assistants. So does everyone on your team, and so will the person you hire, on their first day. A code assessment designed to detect assistance is measuring compliance with a rule that does not exist in the job.
The useful move is to design a task where assistance does not answer the question. Any model will produce a plausible function from a clear prompt. None of them can tell you why this codebase does something the unusual way, or which of two approaches fits the constraint you did not write down. Put the judgement in the task and the assistant becomes what it is at work: a faster keyboard.
- Ask for the reasoning alongside the code. A short note on what they rejected and why is the part that does not autocomplete.
- Base the task on code with a history. Real constraints live in the parts that look odd.
- Follow up on one specific decision in the interview. Someone who made the decision can defend it; someone who accepted a suggestion usually cannot.
- Say explicitly that assistants are allowed. Otherwise honest candidates handicap themselves and the rest do not.
Take-home or live
A take-home respects timezones and nerves, and costs the candidate unpaid hours. A live session costs an hour of theirs and an hour of yours, and shows you how someone works when a plan meets reality.
The usual mistake is choosing one and pretending the trade-off is not there. A short take-home followed by a live conversation about it is the version that keeps most of both: the candidate works in their own time, and you spend your synchronous hour on something you have already read rather than on setup.
Reviewing consistently
Write down what a good submission contains before you send the first one. Review against that list rather than against the previous candidate. Score the dimensions separately: correctness, structure, and the quality of the note about what comes next.
Reviewing everyone on one dimension before moving to the next is slower to organise and considerably harder to bias, which is the trade worth making.
What a good submission actually contains
Teams often struggle to score a task they designed, because "good code" is not a criterion, it is a feeling. Breaking it into things you can point at makes the review faster and the disagreements shorter.
- It works, and the candidate knows it works. Evidence of having checked counts for more than a lucky pass.
- It fits the codebase. A change written in the idiom of the surrounding code is a change the next person can maintain.
- The scope is right. Solving exactly the stated problem is a skill; a refactor nobody asked for is a warning.
- The unclear parts are named. A submission that says "I assumed X because the brief did not say" is showing you how the person will behave on a real ticket.
- The note about what comes next is specific. "More tests" tells you nothing. "No test for the empty case, which is the one that will happen" tells you a lot.
Notice that only the first of those is about the code being correct. By the time someone reaches a take-home, correctness is table stakes; the reason to look at real work is everything after it.
What you owe the candidate
They spent real hours. Tell them the outcome quickly, and tell the people who did well what stood out. This costs one paragraph and it is what they repeat to other engineers, which is the channel you cannot buy.