Hiring a developer from a proposal is hard. Pitches, portfolios and quotes all describe what someone says they can do. None of them show how that person would handle your actual project. A small, well-defined trial task gets you much closer to the truth.
1. Choose a task that's small but real
Pick one slice of your actual project that takes a day or less. It should test the things that matter, such as how they structure the work, handle unclear requirements and communicate, not just whether they can follow instructions. A generic coding puzzle tells you less than a piece of your real problem.
2. Write a brief that someone else could follow
State the outcome you want, not the technology. "Visitors can book a session and pay a deposit" is clearer than "build a booking system". Include a budget, a deadline, and any assets the developer needs (copy, logos, example data). A good brief makes the results easy to judge.
3. Use the same task for every candidate
If you try more than one person, give each the same brief, assets and time limit. Then any differences come from the work, not the instructions. Keep the number small, because every extra candidate costs you review time.
4. Pay for the trial
Asking someone to do real work for free is unfair, and the best developers will decline. Agree a fair fee for the trial up front, and agree who owns the result. Paying also makes it easier to be honest about what you did and didn't like.
5. Decide how you will judge it before you start
Write down your criteria first. Useful ones are: does it work, is it clear how it works, did they ask sensible questions, did they say what they left out, and how do they price the full project. Scoring each candidate against the same list keeps the decision fair.
6. Agree the terms in writing
Put the scope, price, payment dates, cancellation rules and what happens if you disagree into a short written agreement before work starts. It protects both sides, and it is cheaper than a dispute.
What to watch for
Be wary of anyone who won't do a paid trial at all, who ignores the brief, or who delivers something polished that doesn't run. A rough version that works and an honest list of what's missing is usually a better sign.
Top comments (0)