Test tasks are a topic where two opposite positions sound equally confident. "Never work for free, it's exploitation" and "reasonable people do test tasks, it's industry standard." Both are wrong, because test tasks are not one thing: one takes an hour and helps both sides decide whether working together makes sense; another is three days of work on the client's real project, unpaid.
So the question is not "should I do test tasks at all" but how to tell the two apart in ten minutes. Below: the criteria, the questions to ask before starting, and what to do in each case.
When a Test Task Makes Sense
From the client's side the logic is clear: a portfolio shows results but not how someone thinks, how they respond to a brief, or whether they hit deadlines. Sometimes that genuinely cannot be assessed otherwise:
- No relevant work in your portfolio — you are moving into a new area.
- A specific format you have not done: a particular tone, platform or task type.
- A competition for ongoing work, where the stakes are high on both sides.
- You are new and a test task is your chance to show your level without a track record.
In those cases a small test task is a sensible investment of time. Often more effective than another message saying "please look at my portfolio."
Red Flags
Signs this is not a test but free labor. One is enough to be cautious; two are enough to decline.
- It is a real production task. A finished landing page for an actual product, a clip for the next campaign, an article that will obviously be published. A test should not be something that ships.
- Large scope. Anything taking more than a couple of hours is work, and work is paid.
- No brief and no criteria. "Show us what you can do" with no task, audience or constraints makes the result impossible to evaluate — and therefore pointless.
- A tight deadline on unpaid work. "Needed by tomorrow" on a test task signals a hole being plugged.
- Many candidates doing the same task. Twenty free versions is not selection, it is crowdsourcing.
- "Do it and if we like it, we'll hire you." A promise with no obligation.
- They ask for a full package: concept, rationale, several options, source files.
- They dodge questions about payment or about what happens to the result.
- A test task instead of a conversation. A reasonable client talks to you first and only then, if needed, asks to see something specific.
A simple rule: if the output of the test task could be used in the business as is, it is not a test — it is work.
Green Flags
What a reasonable test task looks like:
- Small. An hour or two, half a day at most.
- Abstract or anonymized. A fictional product, a study example, a fragment with no real brand.
- With a clear brief and criteria — you know what is being assessed.
- Identical for all candidates.
- Paid, if the scope is more than symbolic.
- With feedback — you get an answer rather than silence.
- The client answers questions about the test as readily as about the project.
Five Questions to Ask Before Starting
These questions are themselves a filter: a reasonable client answers calmly, while someone after free work usually drops out by the second one.
- How long do you expect this to take? If the answer is "a couple of days," we are now discussing payment.
- Will the result be used in your work? If yes, this is a job, not a test.
- What criteria will you assess it against? No answer means it will be judged on taste.
- How many other candidates are doing this task? Twenty is a reason to decline.
- When and in what form will I get feedback? A reasonable answer is a specific date.
Also clarify the deadline: a test due "by tomorrow" is almost always covering someone's gap.
How to Do a Test Task and Win It
If you decide to go ahead, a few things decide the outcome more than the quality of the work itself.
- Do not do more than asked. It earns no points, eats your time and creates an expectation that you always over-deliver. One well-made screen beats five shallow ones.
- Show your thinking, not just the result. A few sentences: how you read the task, what options you considered, why you chose this one. That is what distinguishes you, because many candidates' outputs will look similar.
- Ask clarifying questions before starting. Not "being difficult" but the strongest signal of professionalism — the same signal clients use to choose specialists generally, as covered in How to choose a freelancer.
- Hit the deadline. A late test answers the client's main question, and answers it badly.
- State your assumptions. "I assumed a B2B audience; if not, the solution changes" shows you see the variables.
- Do not lower quality because it is unpaid. If you took it on, do it at your level — otherwise the time is simply wasted.
- Keep the work for your portfolio. Even if you are not chosen, you keep a case study — provided the task was abstract and no agreement forbids it.
Rights to Test Work
The point almost everyone skips.
- By default the result is yours. You transferred no rights and were not paid — using your work without an agreement is not legitimate.
- Raise it directly if the task resembles production work at all: "Just to confirm, the result isn't used without a separate agreement?"
- Watch the wording. If you are sent a document assigning all rights to "submitted materials," this is no longer a test.
- Check afterwards. If you see your work published, you are entitled to demand payment or removal.
- Do not present others' material as your own in a test: if you used a stock photo or template, label it.
How to Decline Without Losing the Opportunity
Declining a test task does not mean declining the project — the key is offering an alternative.
Portfolio instead of a test:
"Thanks for the brief. The scope looks like a full piece of work, so I won't do it unpaid. Instead I can walk you through three similar cases with the process explained — that's usually enough to judge the approach."
Offering to do it paid:
"Happy to take this on. At that scope I work paid — roughly N hours at rate X. If that works, I can deliver by [date]."
Offering a smaller scope:
"I'm glad to do a reduced version — one screen instead of five. That should be enough to judge the level and takes an hour instead of a day."
Offering a paid pilot:
"Let me suggest a different format: we take a small real task as a paid first stage. You'll see the quality, how I communicate and how I handle deadlines — far more informative than a test."
The last option is often best for both sides: the client learns more than any test can show, and you get paid work and a potential case study.
What if I'm new and a test task is my only chance?
Then doing it is often worthwhile — with two conditions.
First, assess it realistically: if it is three days of work, in the same time you could build your own case study that stays with you permanently and works for every future enquiry rather than one client. You hand a test task over once; a portfolio case works for years.
Second, even when agreeing, ask the questions above. It does not reduce your chances — the opposite: the client sees that you understand the process. And if questions about assessment criteria and use of the result scare someone off, that is precisely the client the work would have been hard with.
From the Client's Side: How to Set a Test Task Properly
If you are hiring, these rules improve the quality of responses without scaring off strong candidates:
- Keep the scope to an hour or two and say so explicitly.
- Give a real brief — task, audience, constraints, criteria.
- Do not use production work. Using a free result is the fastest way to damage your reputation in the community.
- Pay if the scope is more than symbolic. Strong specialists are usually busy and do not do unpaid tests.
- Give feedback to everyone who completed the task. Five minutes, and it builds your reputation as a client.
- Consider a paid pilot instead. You will see the work, the communication and the deadline discipline — everything a test does not show.
Common Mistakes
- Doing a large test with no questions asked. The most common way to lose two days.
- Over-delivering to impress. It does not work, and it raises expectations.
- Lowering quality because it is unpaid. Then it would have been better not to start.
- Not asking about use of the result. This is where most abuse happens.
- Agreeing to a "competition" with dozens of entrants. A lottery, not a selection.
- Missing the deadline. It cancels out any quality of work.
- Declining bluntly, with no alternative. You lose a project where another format could have been agreed.
- Not keeping the test work. Even an unsuccessful one is portfolio material.
Key Takeaways
- The question is not whether to do test tasks but how to tell a test from free labor.
- The main criterion: if the result could be used in the business as is, it is work and it is paid.
- A reasonable test: an hour or two, abstract, with a brief and criteria, identical for all, with feedback.
- Ask the five questions before starting — they filter out bad-faith clients by themselves.
- Do not do more than asked; show your thinking and your clarifying questions instead.
- Rights to unpaid test work remain yours — raise this explicitly.
- The best alternative to a test task is a small paid first stage.
- Keep even an unsuccessful test as a case study, if it was abstract.
FAQ
Should I do a test task for free?
If it takes an hour or two, is abstract rather than the client's real task, and has clear criteria — usually yes, that is normal practice. If it is a full piece of work spanning days, or the result will obviously ship, then no: that is a job and it gets paid. The criterion is simple: anything that could be used in the business as is, is not a test.
How do I know a test task is really free labor?
Red flags: a real production task instead of an abstract one, scope beyond a couple of hours, no brief or assessment criteria, a tight deadline, many candidates doing the same task, and evasion around payment and use of the result. Two of those are enough to decline.
Who owns the rights to completed test work?
If there was no payment and you signed no transfer of rights, the result remains yours and the client cannot use it without an agreement. Raise this explicitly before starting, especially if the task resembles production work. If you later see your work published, you are entitled to demand payment or removal.
How do I decline a test task without losing the project?
Offer an alternative rather than a flat no: walk them through relevant cases with the process explained, do a reduced version in an hour, do the test paid, or propose a small paid first stage of the real project. The last option usually suits both sides best: the client sees quality, communication and deadline discipline.
What to Do Next
Next time you receive a test task, spend ten minutes on the five questions above — the cheapest filter there is. Half of questionable briefs fall away at the answering stage.
If you decide to proceed, do it at your level, add a few sentences on your reasoning, and keep the result as a case study. And to be asked for tests less often, nothing beats a strong portfolio with explained decisions: see How to make a portfolio, and for those with no client work yet, Portfolio with no experience.
Ready to act?
- Add a case to your portfolio: https://searchtalent.dev/en/projects/new
- Talent catalog: https://searchtalent.dev/en/talents
- Browse other specialists' projects: https://searchtalent.dev/en/projects
- More articles: https://searchtalent.dev/en/articles
