How do you set up a paid test task when hiring a developer?

You have a shortlist of developers. Their public code looks good, the first call went well, and you still don't know how they would handle your codebase. A paid test task for developers answers that question: a small piece of real work, paid whatever the outcome, done in conditions close to the job. This guide shows how to choose the task, write the brief, set the fee, give safe access and judge the result. It ends with the choice that follows: a trial contract or a direct hire.

Why a paid test task for developers tells you more than an interview

An interview shows how someone talks about code. A test task shows how they write it, ask questions and take feedback. In crypto, many developers work under a pseudonym, a stable online name that is not their legal name, and have no CV to check. For them, that evidence counts even more.

Paying for the task matters for two reasons. The developers you want are often busy with other work, and an unpaid task asks them to give you that time for free. Payment also turns the task into a small contract, with a scope, a deadline and a clear owner for the code.

The task does not replace the other checks. It comes after a look at their public work and a first call, and before any offer.

Choose a task from your real work

The best test is a small version of the job. Take it from your backlog, the list of work your team has already planned, rather than from a puzzle site. A real task shows how the person copes with your tools, your code style and the parts of your project nobody has documented.

Good test tasks share three traits:

• They take a few hours, not days, for someone with the right skills.
• Someone on your team can review them in under an hour.
• They have a visible result: a working feature, a fixed bug or a short written review.

For a smart contract developer, who writes the programs that run on a blockchain, a good task might add one function to an existing contract, with its tests. For a security role, it might be a review of a small contract with a write-up of the flaws found. For a front-end developer, it might connect one screen of your app to a wallet, the app that holds a user's crypto keys.

Avoid tasks that look like free consulting. A full feature you plan to ship next week, or an audit of your live contracts, is real work and should be priced as such.

Write the brief, the fee and the deadline down

Send the task in writing, in one short document. The candidate should know what success looks like before they start, and so should you. Include:

1. The goal of the task, in two or three sentences.
2. What you provide: access, documentation and a contact for questions.
3. What you expect back, such as a pull request, a proposed change to your code that you can review and accept.
4. The time you expect it to take, and the deadline.
5. The fee, when you will pay it, and in which currency or token.
6. Who owns the code once the task is paid.
7. How you will judge the work, and when the candidate will hear back.

Set the fee from the time you expect the task to take, at the rate you would pay for the role. Say you estimate four hours for a role you would pay 80 euros an hour: the fee is 320 euros, paid even if you do not hire. Pay it within a few days of delivery.

If the candidate asks to be paid in crypto, write the token, the network and the wallet address into the brief. The guide on paying developers in crypto covers the practical side. Keep a note of the payment details they give you at this stage. A change of address or payment platform before the start date deserves a question, because such changes during onboarding are one of the warning signs of fake remote IT workers.

Give access without handing over the keys

A test task needs some access to your code, but never to your funds or your live systems. Plan that access before you send the brief.

Work on a copy. Create a separate repository, the online folder that holds a project's code, with only what the task needs. On GitHub, you can add the candidate as an outside collaborator, a person outside your organisation who can reach only the repositories you choose. Remove that access on the day the task ends.

Use a test network for anything that touches a blockchain. A testnet is a copy of a blockchain built for testing, where the coins are meant to have no real value. On Ethereum, Sepolia is the recommended testnet for application development. A mistake there costs nothing, and the candidate never needs a key that controls real money.

Keep secrets out of reach. That means no production passwords, no private keys and no seat on your multisig wallet, the company wallet that needs several people to approve each payment. Apply the principle of least privilege from the first day: each person gets the access their work needs, and nothing more. Fake remote IT workers have copied company code to their own accounts and then held it to ransom.

How to judge the result

Review the work against the brief you wrote, not against a picture in your head. Ask the person who would work with the candidate every day to do the review.

Look at four things:

• Does it work? Run it, and run the tests the candidate wrote.
• Can your team read it? Clear names, small changes and short comments make code cheaper to maintain.
• How did they ask questions? A good question early often saves a day of wrong work.
• How do they take feedback? Leave one or two review comments and see how they respond.

Then book a short call to walk through the work together. Ask why they made one choice over another, and what they would change with more time. Someone who did the work explains it easily. Someone who did not will struggle with the details, which makes the call a useful check in its own right.

Give the answer you promised, on the day you promised. A candidate who does a good test task and then hears nothing for two weeks may well accept another offer.

Test task, trial contract or direct hire

The test task tells you whether to go further. It does not decide the form of the next step, and three options are common.

A trial contract is a short, paid engagement with a fixed scope, signed before any long-term arrangement. It suits a first technical hire, when nobody on your team can judge the work from a single task. It also gives a pseudonymous developer time to build trust before they share their legal identity, if the role needs it.

A direct hire suits a developer you already know, through past work or a trusted reference. Even then, widen their access in steps during the first weeks.

Strong candidates often have several options, so a long trial can cost you the hire. Keep a trial contract short, and say upfront what would turn it into a permanent role.

Where to start

1. Pick one task from your backlog that takes a few hours and can be reviewed in under an hour.
2. Write the brief: goal, deliverable, time, deadline, fee, payment method, code ownership and review date.
3. Create a separate repository with only what the task needs, on a testnet if it touches a blockchain.
4. Give the candidate access to that repository only, and note the date you will remove it.
5. Pay the fee within a few days of delivery, whatever you decide.
6. Review the work with the person who would work with them, then walk through it on a call.
7. Choose between a trial contract and a direct hire, and tell the candidate on the promised day.

Hiring developers with Other--Side

Other--Side recruits for businesses in regulated and complex markets across Europe, from a first hire to a full leadership team. Technology is one of the functions we cover, alongside compliance, operations, product and finance. Before you meet a candidate, we check them against the rules of your market, and we look at whether someone will stay before we look at whether they are free. See our services, or tell us about the role you need to fill.