How to Build a Hiring Scorecard That Actually Filters

The highest-leverage step in screening happens before any software is involved, and it takes about forty minutes.

Almost every complaint about automated screening — it rejects good people, it rewards keyword stuffing, the rankings feel arbitrary — traces back to the same root cause: the criteria were not checkable in the first place. A model given a vague requirement does not report that the requirement is vague. It produces a number anyway.

The test that matters

Could two reasonable people read the same resume and agree on whether this is met?

If no, it is not a criterion. It is a feeling, and it will either add noise to your ranking or quietly get replaced by a proxy — which is how postcode and university end up doing work you never authorised.

Apply the test:

Notice how many entries on the left simply have no right-hand equivalent. That is the useful outcome. "Culture fit" and "detail-oriented" are not criteria that need better wording — they are criteria that cannot be assessed from a document and should be assessed later, in a structured interview, or not at all.

Building the scorecard

1. Separate hard from scored

Hard requirements are binary and disqualifying. Work authorisation, a required licence or certification, a security clearance, a genuine location constraint. There should be very few — usually zero to three — and each one should be a thing you would genuinely never hire without.

The common failure is putting a degree in this bucket out of habit. Ask whether you would actually reject an otherwise outstanding candidate for lacking it. If the answer is no, it is not a hard requirement.

Scored requirements are the five to eight that differentiate. These get weighted.

2. Write each as observable evidence

Each scored requirement should name what would count as evidence:

Requirement: Has run a migration of a production database. Evidence: A role description mentioning migration, replatforming, or a named database transition, with ownership language ("led", "owned", "designed") rather than participation language.

That level of specificity feels excessive until you watch two people screen the same pile with and without it.

3. Weight, and make the weights add up

Assign each scored requirement a weight out of 100. Two rules:

• Nothing gets more than 30. If one requirement is worth more than 30, it is really a hard requirement — move it.
• Nothing gets less than 5. If it is worth less than 5, it is not affecting the ranking. Delete it.

The exercise of making them total 100 is where the honest conversation happens. Hiring managers who insist all eight requirements are critical discover, when forced to allocate, that three of them are actually preferences.

4. Define the threshold before you look at candidates

Decide what score puts someone in the "read properly" pile — before you see the distribution. Set it afterwards and you will unconsciously set it wherever produces a comfortable number of candidates, which defeats the purpose.

5. Use bands, not positions

This is the one most teams get wrong.

A ranked list implies precision that scores do not have. If your top forty candidates score between 71 and 78, that spread is inside the noise — but presented as an ordered list, whoever reads it will stop around fifteen, and a two-point difference becomes a hard boundary.

Everything above the threshold goes in one pile, and the whole pile gets read. If the pile is too big, tighten a requirement. Do not just read further down the list.

A worked example

Senior Backend Engineer:

Hard requirements

• Authorised to work in the UK

Scored requirements (100 total)

Threshold: 60.

Every one of those can be checked against a resume, and every rejection can be explained to the candidate in a sentence. That last property is what makes the process defensible — both to a disappointed applicant and, increasingly, to a regulator. See AI hiring compliance in 2026.

What this buys you

Automation becomes safe. Software given checkable criteria produces checkable results. Software given "strong communicator" produces a plausible-looking number with nothing behind it. See AI resume screening.

Bias becomes measurable. You can ask which requirement is driving a disparity in selection rates, and whether that requirement is genuinely necessary. You cannot do that analysis on intuition.

Disagreements get faster. When a hiring manager and a recruiter disagree, they are now disagreeing about a specific weight rather than about a candidate's vibe. That is a resolvable conversation.

Your job description improves. Almost every team that does this exercise discovers their posting lists requirements nobody would actually enforce. Removing them widens the applicant pool at zero cost.