How to test a candidate's skills fairly

Short answer: test the skill the job really needs with a small task close to the real work, keep it to one to three hours, use invented material, write a clear brief and deadline, pay when the task is long, score every candidate against the same criteria, and reply to everyone with a line of feedback. A fair test gives you better information and keeps good candidates in your process.

Skills tests are the part of hiring that people dislike most when done badly. Candidates in Morocco and elsewhere have all met the unpaid three-day assignment that vanished into silence, and many now refuse them. Good candidates have options, so a clumsy test costs you the people you most want. Done well, it is the best predictor you have, far better than a conversation or a list of past employers.

Decide what you need to learn

Before designing anything, list the two or three abilities that decide whether someone succeeds in this job. For a developer it may be writing clear code and debugging. For a support agent, tone and accuracy under pressure. For a designer, the reasoning behind choices. For a virtual assistant, organisation and attention to detail. A test should check those abilities and nothing else.

A common mistake is testing what is easy to test instead of what matters. Trivia about a framework, a speed typing test for a role that never types fast, or a riddle with no link to the work tells you little. If you cannot say what a result will teach you, drop that test.

Choose the right format

There are four formats that work, each with a different cost to the candidate.

A short work sample. A small task drawn from the real job, done on their own time. It shows actual output, and candidates can do it at a calm hour, which suits different time zones.

A live exercise. You solve a small problem together on a call. It shows how someone thinks and takes hints. It can stress people, so explain the format beforehand and make it clear you are not looking for a perfect answer.

A portfolio review. For designers, writers and developers with public work, a conversation about two or three pieces can replace a test. Ask what the person's part was, what they would change and what they learned. This respects experienced candidates who do not want to repeat work they have already proved.

A trial period or paid pilot. For important or senior roles, a short paid project is the fairest test of all, because it looks exactly like the job.

Use one of these, not all of them. Keep the test as one step in a short process, not the whole of it.

Keep it short and relevant

One to three hours of candidate time is a sensible limit for a first test. Longer asks make strong candidates drop out, and they reward people with spare evenings rather than people with talent. If you need to see more, split the process: a short test first, a deeper paid piece for the final two.

Make the task a smaller version of the job, not a disguised piece of real work. Ask for a landing page layout using a made-up company, not your actual next campaign. Ask a support candidate to answer three sample tickets you invented, not live ones. Using real client data in a test is both unfair to the candidate and a privacy risk for you, and asking for finished work you then use is simply getting free labour.

Pay when it is long or valuable

A fair rule: if the task takes more than about two hours, or produces something with real value to your business, pay for it. Say the amount and how it will be paid before the candidate starts. Candidates in Morocco may invoice you as independent workers, so ask what they need. Paying also changes who applies: serious people respond to it. Our guide on hiring Moroccan remote talent legally explains how payments and status work for independents.

If paying is not possible, shorten the task until it is reasonable to ask for free.

Write a brief that anyone could follow

Ambiguity is the main source of unfair results. A good brief includes:

• The goal of the task in one or two sentences.
• The inputs, such as files, data or a scenario, and what is allowed (tools, AI assistance, searching the web).
• The deliverable and its format.
• The time you expect it to take, and the deadline, with a time zone.
• How you will judge it.
• A contact for questions, and a promise to answer within a day.

Say plainly whether tools such as AI assistants are allowed. Many people use them at work already, and the real question is whether the person can judge and improve the output. If you ban them, explain why. If you allow them, ask the candidate to describe how they used them.

Give a realistic deadline. Candidates may have a job, family duties, or a connection that drops. A few days is fair for a two-hour task. Remember that deadlines around Moroccan public and religious holidays can be harder to meet. Our guide on working across time zones with Morocco helps you pick dates that make sense.

Score it against criteria

Write the criteria and the scale before you open the first submission. Four to six criteria and a scale of one to five are enough. For a customer support test, they might be accuracy, tone, clarity, speed of reply and following the policy you gave. Score each submission alone, and ideally with the name hidden, so that a familiar school or accent does not nudge the result.

If two people score, let them score separately and then compare. Disagreement is useful: it shows you where your criteria are vague. Keep notes of the evidence for each score. A line such as "handled the refund case correctly but missed the apology" is more useful than a number.

Compare candidates on scores, then decide. Notice when you feel pulled toward someone for reasons not in the criteria, and check whether they belong there.

Fairness across backgrounds

Candidates come from different schools, languages and levels of access. A few habits help:

• Test the language level the job needs and no more. A developer who documents in English does not need perfect spoken English.
• Do not penalise a slow connection or a short outage. Allow a re-send.
• Accept answers in more than one reasonable form. There is rarely only one right way.
• Offer the same support to everyone: the same brief, the same time, the same chance to ask questions.
• Offer an alternative where needed, such as an extra day or another format, for people with disabilities or other constraints.

Remember that candidates are also judging you. If you want to see how they prepare, see our advice to candidates on passing take-home tests: they are told to ask about scope, payment and use of their work. Be ready for those questions.

Give feedback and decide quickly

Reply to every person who completed the task, even if briefly. Two sentences are enough: what went well, and the main reason you are not moving forward. It costs you five minutes and protects your reputation among a community where people talk to each other. Tell your chosen candidates quickly too. For help on what to offer, see our guide on what to offer remote hires in Morocco.

When you are ready, post a job or look through Moroccan talent to build your shortlist.

FAQ

How long should a skills test be?

Between one and three hours for a first test. If you need more, pay for it or split it into stages so that only finalists do the longer piece.

Should I let candidates use AI tools in the test?

Decide and say so in the brief. Many roles use these tools daily, so allowing them and asking how they were used can show judgment. If the goal is to see raw skill, say that tools are not allowed and why.

Is it fair to ask for unpaid work?

Only for short, invented tasks. If the work is long or could be used by your business, pay for it.

What if a candidate refuses to do the test?

Offer another way to show their skill, such as a portfolio walk-through or a paid mini project. A refusal is not always a bad sign, especially from experienced people.