| Good trial task | Bad trial task |
|---|---|
| Pagination and search on an admin list that already exists | An intermittent production bug nobody has diagnosed |
| An importer for a CSV format you already receive | A feature still being argued about in Slack |
| A second payment provider behind the existing interface | Anything that starts with the words “just clean up” |
| One of your people could do it in a day | Nobody internally knows what finished looks like |
| You could throw the result away | The launch depends on it |
You are about to hire your first developer. The only evidence you have is an hour of conversation and a CV.
That hour measures how well somebody talks about building software. It is a different skill from building it. Some excellent engineers are quiet and slow in a call, and some very fluent interviewees produce work you’ll spend a year unpicking.
The usual patch is a take-home test, and it is where strong candidates start saying no. The task is invented, so it shows you how somebody handles invented problems. It is unpaid, so you are asking a working professional for a free evening. And it is graded against a rubric they never see.
A paid trial on real work fixes all three. It is also easy to run badly.
Almost everybody who reaches this stage can write code. That is not the question.
The question is whether this person can take a request with holes in it and turn it into something shippable without daily hand-holding. Whether they ask before writing four hundred lines in the wrong direction. Whether you could read their pull request without booking a call.
Those are working habits, not talent. Habits are exactly what an interview cannot show you and a CV cannot prove.
The table above is the short answer. Three things behind it are worth spelling out.
Use something real. Invented tasks have invented constraints, and candidates can smell them. Real work carries the mess you want to watch somebody handle: the half-documented endpoint, the config that only makes sense historically.
Keep it self-contained. No production data, no credentials that take a week to provision. A candidate who spends six of their ten hours waiting for a database login has been tested on your onboarding, not on their work.
Put it in writing first. A one page contractor agreement covers it: the rate, the cap in hours, confidentiality, and an assignment to you of everything they write.
That last one gets skipped constantly and it matters more than it looks. Without a signed assignment, the person you paid usually still owns the copyright in that code. You find this out at the worst possible moment.
Five lines, one page.
That fifth line does more work than the other four together. A brief that specifies everything tests obedience. A brief that names two or three decisions and hands them over tests judgement, which is the thing you are actually trying to buy.
Ten hours suits most roles. Long enough to hit one real obstacle and a second working session, which is when habits show. Short enough to fit into somebody’s week.
Under four hours you only learn how fast somebody moves on something easy. Past two weeks you are running an unpaid probation, and the strong candidates will have accepted another offer while you deliberated.
At the $50 to $80 an hour senior contractors bill, ten hours costs roughly $500 to $800. Pay it whether or not you hire them. Not a token, not a gift card, not equity.
Agree the cap up front and pay on completion rather than on outcome. If the work ran to twelve hours because your brief was vague, pay for twelve and fix the brief.
An unpaid task cannot be managed, only received. Paying is what buys you the standing to set a deadline and ask for a revision.
One caution. Plenty of employment contracts restrict paid outside work, so let the candidate decide when to do it rather than assuming their evenings are free.
The finished code is the least interesting output. By the time you read it, the interesting part is over.
The first two hours. Strong engineers open with questions, and what they ask tells you more than anything else in the exercise. Somebody who wants to know what happens when the input is empty has shown you how they will handle a real ticket. Somebody who goes quiet for a day and returns with a confident wrong answer has told you something too.
What happens when they get stuck. Everyone does. The split is between people who go quiet and people who say what they tried, what they expected, and what happened instead.
The shape of the work. Small commits with readable messages, or one enormous drop at the deadline. A note about what they chose not to do, or silence about the corners they cut.
How correction lands. Ask for one revision, even a minor one, purely to see the response. Defensiveness on day three doesn’t improve on day ninety.
Read the pull request as if you had to maintain it. If you need a call to understand what changed, that call will be needed every week for as long as they work with you.
Most of those signals survive without a technical reader. The questions, the response when blocked, the commit rhythm, the tone of the revision, all of it is legible to anyone.
For the code, borrow an engineer for forty minutes and ask one question: would you be happy to maintain this. You don’t need a score. You need somebody who can tell you whether the next person to touch that file will curse.
Then ask the candidate for a five minute walkthrough. Somebody who can explain what they built, in plain language, to a person who cannot read the diff has demonstrated the skill you’ll rely on every week.
Being clear about the limits is what separates a useful trial from a superstition.
Treat a good trial as permission to proceed, not proof you were right.
If it went well, say so fast. Strong candidates are talking to other companies, and a week of silence after somebody did real work for you is a reliable way to lose them.
If it did not, pay in full anyway, say no clearly, and give one concrete reason. Not a rubric, not a lecture. “The approach was sound, but the pull request took three rounds to become readable, and that pace doesn’t fit where we are right now.” People remember being told the truth briefly, and this industry’s small.
Then ask what was unclear in the brief. The candidate has just spent ten hours finding out exactly where your instructions were vague.
One last decision: how many people to run this with. One finalist keeps it cheap and honest. Two in parallel gives you a comparison, at double the cost and some awkwardness if both do well. Three usually means the interview stage isn’t doing its job.
If you would rather not build this process yourself, it is roughly what we do before a client ever sees a profile. Tell us what you are hiring for and the candidates you meet will already have been through it.
Privacy is important to us, so you have the option of disabling certain types of storage that may not be necessary for the basic functioning of the website. Blocking categories may impact your experience on the website. More information
