Skills assessments for hiring: what they measure and how to run one

A skills assessment in hiring is a structured test of whether a candidate can do specific parts of a job, scored the same way for everyone who takes it. It is evidence you generate yourself, about work you defined, which is what separates it from a résumé claim or an interview answer.

Two other things share the name and neither is this. Career self-assessment helps someone work out what job to look for — the instruments published by government labour departments are almost all of this kind. Workforce development assessment measures the skills of people you have already hired, to plan training. Both are legitimate; neither predicts whether a candidate should get an offer.

The confusion is worth naming because it sends teams to the wrong tool. A published skills inventory designed for career exploration will produce a tidy report about a candidate and tell you nothing about whether they can do the job you are hiring for.

If you take one thing from this page, take the distinction in the middle column.

A quick test for anything you are handed: if the output is a profile of the person rather than a judgement about work they produced, it is not a hiring assessment regardless of what it is called.

The word "skills" hides a distinction that decides whether your test predicts anything. There are skills that are cheap to verify and skills that decide the hire, and they are rarely the same list.

• Declarative knowledge — facts and syntax. Easy to test, easy to look up, and it dates. Worth almost nothing on its own, which is why multiple-choice batteries feel rigorous and predict poorly.
• Procedural skill — can they carry out the task end to end. This is the floor, and a scoped work sample measures it directly.
• Judgement — do they make good calls when the brief is incomplete. This is the thing that actually varies between a competent hire and a strong one.
• Communication of the work — can they explain what they did to someone who needs to act on it. Most screens skip this entirely, and it is why hires who passed the test still disappoint.

A test that only reaches the first two levels sorts candidates confidently on the dimension that matters least. If your assessment can be passed by someone who memorised the right things, you have built a knowledge quiz and labelled it a skills assessment.

Start from the failure, not from the skill list. Ask what went wrong the last two times someone did not work out in this role — that is the thing your assessment exists to catch.

• Pick three competencies, not nine. Nine produces a form nobody completes carefully and a score that averages away the signal. Three forces you to decide what the role is actually about.
• Use a real task. Something from the last month of the actual job, stripped of the context that requires knowing your systems. Hypotheticals measure imagination.
• Keep it under an hour, including reading time. Past that the strongest candidates decline, which selects against exactly the people you were hoping to find.
• Leave one thing under-specified. What a candidate does with genuine ambiguity is the highest-signal observation available, and it is free.
• Ask for a short note with the submission — what they assumed, what they cut, what they would do next. This is where judgement and communication become visible.

For technical roles specifically, the design question has a well-worn wrong answer — what to test instead of a puzzle covers what to measure at each seniority level and why coding-puzzle screens mispredict.

Write the rubric before the first submission arrives. Written afterwards it will describe the candidate you already liked, which feels like rigour and is its opposite. For each competency, describe what weak looks like and what strong looks like in a sentence each.

Score in a batch rather than as results come in. The first submission you read sets an anchor the next four are measured against without you noticing, and the effect is larger than most people expect. Where you can, review the work without the name attached.

Keep the evidence, not just the number. One line per competency saying what in the submission produced that score is what makes the decision reviewable a month later, and what you fall back on if a rejected candidate asks.

• The test that grew. A ninety-minute task described as "about an hour". Completion rates fall, and they fall hardest among candidates with jobs and caring responsibilities.
• Testing the stack instead of the skill. Screening for your exact framework measures who used it last, not who is good. It transfers in a fortnight.
• Scoring by impression. No rubric, a general feeling of quality, and a shortlist that correlates with who writes most confidently.
• Running it too late. An assessment after three rounds of conversation is a formality confirming a decision already made, and everyone involved can feel that it is.
• Assuming the submission is theirs. Unproctored written work no longer tells you who produced it — why detection fails and what still works is the honest version of that problem.

It is one hour of solo work under artificial conditions, produced by someone who knows they are being judged. It will not tell you whether they are still motivated in month eight, how they behave when they disagree with someone senior, or whether they finish things once the interesting part is over.

It also systematically underrates people who work slowly and think well, because the time limit was set for your convenience rather than the job's. Treat a strong result as a reason to proceed and never as a guarantee. For how this method compares with the alternatives, see what candidate assessment is and how to choose a method; for the software that runs them, the tools compared.