Paid Trials for Engineering Hires: How to Run One

Why trials outperform interviews

Interviews measure how somebody describes work. Trials measure the work. That distinction sounds obvious and it is routinely underweighted, because interviews are cheap and trials are not, so hiring processes optimise for the cheap instrument and then express surprise when it predicts poorly.

The specific things a trial reveals are the ones interviews systematically miss: how somebody behaves when a task turns out to be more tangled than described, whether they ask for help at the right moment, whether their code is comprehensible to the person who reviews it, and whether they finish. None of these can be assessed from a conversation, and all of them determine whether the following six months go well.

There is also a symmetry argument that matters more than it is usually given credit for. A trial lets the engineer evaluate you: your codebase, your review culture, how decisions get made, whether the problem is as described. Candidates who have been burned before value this, and offering it is a genuine differentiator in a competitive market.

Scoping a trial fairly

One to two weeks is the right length. Shorter than that and the work is too shallow to reveal anything an interview would not; longer and you are asking somebody to defer other opportunities on speculation, which biases your pipeline toward candidates with no alternatives.

The deliverable should be real, self-contained and genuinely useful. Real, because artificial tasks produce artificial behaviour. Self-contained, because a task requiring three months of context measures onboarding rather than capability. Useful, because paying somebody to build something you will discard is disrespectful and both parties know it.

Write down what success looks like before the trial starts, and share it. This is the step most often skipped and it is what converts a trial from an assessment into a vibe check. Without written criteria, the evaluation defaults to whether the person felt like a good fit, which is precisely the bias the trial was meant to avoid.

Running it so it produces signal

Treat the engineer as a member of the team for the duration. Give them full access on day one, include them in the relevant discussions, and review their work the way you would review anybody's. A trial run at arm's length measures how somebody performs when isolated and under observation, which is not a situation the actual job involves.

Assign a named reviewer with time allocated. The most common way a trial fails to produce useful signal is that nobody had capacity to engage with the work, the engineer was left to guess at conventions, and the output was then judged against expectations that were never communicated.

Check in at the midpoint against the written criteria. If something is off track, say so then rather than at the end. This is fairer, it gives you information about how the person responds to correction, and it occasionally converts a trial that was heading for a decline into a successful hire.

What to actually evaluate

• Did they finish, and if not, did they communicate that early and accurately?
• Is the work comprehensible to a reviewer who was not involved in writing it?
• How did they behave when the task turned out to be more tangled than described?
• Did they ask for help at a sensible point rather than too early or far too late?
• Did they scope sensibly, including deciding what deliberately not to do?
• Does the written communication reduce work for the reader or add to it?
• Would the reviewer choose to work with them again, and can they say specifically why?

Ending a trial well

Some trials do not work out, and how you handle that determines your reputation in a small market far more than the successful ones do. Pay in full and promptly, regardless of outcome. Give specific feedback rather than a generic decline, because the person spent two weeks on your problem and has earned an actual reason.

Be honest about which side the mismatch sat on. Frequently the engineer is capable and the fit is wrong — the problem was different from the description, or the codebase needed a specialism nobody identified. Saying so is both accurate and considerably kinder than implying a capability judgement you do not hold.

And decide quickly. A trial that ends with a fortnight of silence while stakeholders deliberate costs you the candidate anyway and produces a story they will tell. Deciding within two working days is achievable if the success criteria were written down at the start, which is another reason to do that.

Part of the Vetting & Technical Assessment cluster · Read the pillar page