Using a Small Paid Task to Evaluate a Freelance Developer

Interviews and portfolios tell you how a developer describes their work. A small paid task shows you how they actually do it: how they ask questions, how they handle an unfamiliar codebase, what their pull requests look like, and whether they deliver when they said they would. Done well, a trial task is fair to the candidate and far more informative for you. Done badly, it is unpaid labour in disguise or a test that measures nothing. This guide digs into designing one that works.

Principles before details

• Pay for it. A real task with real deliverables is work. Agree on a fixed amount upfront, whatever the outcome. This also signals that you take the candidate's time seriously, which attracts better candidates.
• Keep it small. Something an experienced person can finish in two to six hours. Longer than that and you are commissioning a project, not running a trial.
• Make it real but non-critical. A genuine issue from your backlog teaches you more than a puzzle, but it should not be on your launch's critical path.
• Decide the scoring before you see results. Otherwise you will rationalise whichever result you liked.

Step 1: Choose the right kind of task

Good trial tasks share a shape: a clear starting point, a definable end, and room for judgement in between. Examples that work well:

1. Fix a specific, reproducible bug and add a test that would have caught it.
2. Add one small feature end to end, for example an "export to CSV" button, including server-side validation.
3. Review an existing module and write a short report of risks, ordered by severity, with one of them fixed.
4. Write the row level security policies for two tables, with SQL that demonstrates they work.

Avoid tasks that depend on access you cannot safely grant, tasks so vague that any output is defensible, and anything you plan to ship without review.

Step 2: Write the brief like a mini contract

The brief should fit on one page and include:

• Context: what the app does, the stack, and where the relevant code lives.
• The task: the specific outcome, with reproduction steps for bugs.
• Acceptance criteria: what you will check, in testable terms.
• Deliverable format: usually a pull request against a branch, plus a short written note.
• Time and fee: the agreed amount and the date it is due.
• Access: a sandbox or staging environment with test data, never production credentials.

Ask candidates to raise questions before starting. The questions themselves are part of the evaluation.

Step 3: Score what matters

Use a simple rubric and fill it in for each candidate. A five-row table is enough:

Area | What to look for

Correctness | Does it meet the acceptance criteria when you test it yourself?

Communication | Did they ask useful questions, flag assumptions and report progress?

Code quality | Readable changes, sensible naming, no unrelated rewrites, tests where appropriate

Judgement | Did they notice adjacent problems and mention them without silently expanding scope?

Delivery | Was it on time, or did they warn you early if not?

Pay attention to the written note accompanying the pull request. A developer who explains what they changed, what they did not change and why, and how to verify it, is showing you exactly the habit that keeps longer projects on track.

Step 4: Combine the trial with the track record

A trial task is one data point. Combine it with evidence of sustained work: how many past engagements a person has completed, whether clients came back, and whether they delivered on agreed dates. Self-written portfolios are hard to verify, so look for records tied to actual contracts where you can. On Workli, for example, a freelancer's Work Passport lists only contracts recorded on the platform, with jobs completed, repeat clients and on-time delivery calculated from dated milestones, and nothing self-reported. Workli has no star ratings or written reviews, so you read the record rather than an average score. Whatever source you use, a strong trial plus a consistent history is a much better signal than either alone.

Finally, run the trial fairly. Give every candidate the same brief, the same environment and the same deadline. Respond to questions promptly, since slow answers penalise the candidate for your delay. Pay promptly once the work is delivered, regardless of whether you hire them. And give short, honest feedback; developers remember clients who do this, which matters when you want to work with them again.

A well-run paid trial costs a few hours of a developer's time and an hour of yours. In return, you replace guesswork with direct evidence of how someone works on your actual code. For any engagement longer than a couple of weeks, that trade is almost always worth making.