Skills-Based Hiring: Why Keyword Matching Is Dead and What Replaces It

Skills-based hiring means evaluating candidates on evidence that they can do the work, not on whether their CV contains the words in your search string. Keyword matching fails for a structural reason: a CV is a marketing document written in whatever vocabulary the candidate happened to choose, and a keyword filter rejects the person who described the same skill a different way.

It gets worse. Keyword matching does not only reject good people, it promotes weak ones. The candidate who lists every term in the job ad is very often the one who has done the least with any of them, because listing terms is cheap and doing the work is not.

I ran a recruitment agency before I built Pickr, and spent years writing Boolean strings I was quietly proud of. They were the wrong instrument. The failure is identical whether you are an agency filling client mandates or an in-house team filling your own requisitions. Here is what replaces it, and how to start without new software.

Why a CV cannot carry a keyword search

Four failures sit underneath, and none is fixable with a better search string.

Vocabulary is arbitrary. Field sales, outside sales, territory sales and the German Außendienst are the same job written four ways. A candidate writes "modern JavaScript frameworks" where your ad says React, or "P&L responsibility for a business unit" where your ad says budget ownership.

The CV was written for a different reader. Most people write one CV and send it everywhere. It is not an answer to your brief. It is a summary optimised for a stranger doing a first pass in seconds; the widely cited Ladders eye-tracking study put that pass at roughly seven.

Absence is not evidence of absence. Senior people under-list. They detail the last three roles, compress the previous decade into two lines, and drop whatever seems too obvious to mention. The person who has written SQL every day for nine years is the least likely to put it in a skills box.

Presence is not evidence of competence. This one costs you interview time rather than candidates. A word on a CV tells you the person has heard of the thing.

A keyword filter measures the overlap between two vocabularies. It has never measured capability, and no amount of Boolean craft will make it.

The four things that replace keywords

1. Evidence of a skill, not mention of a skill

The question is never "does this CV contain Kubernetes". It is "what did this person build with it, for how long, who was responsible when it broke at 3am, and what did they change afterwards". Evidence is a claim specific enough that a reference call could confirm or destroy it. So read the lines under each role that describe scope and ownership, not the skills box.

2. Adjacent and transferable skills

Adjacent skills sit close enough to your requirement that the transfer cost is weeks, not years. Someone who has shipped production Kotlin can very likely ship Java.

Write the adjacency list down before you see candidates, so it is a hiring standard rather than a rationalisation for the one person you already like. Then ask one question of every requirement in the brief: is this the skill, or a proxy for it? Proxies are fine as signals. They are indefensible as filters.

3. Levels of evidence

Two candidates who both list the same skill are usually three levels apart. Grading them is the whole game.

Level	What it looks like	What you can conclude
Mentioned	The word appears in the skills list at the bottom	Nothing at all
Exposed	A course, a bootcamp project, a two-week internal spike	Knows the vocabulary, needs supervision
Applied	Shipped real work with it, in a scope someone else owned	Can execute when the problem is already shaped
Owned	Responsible for it in production across years and failures	Can make the calls, including the bad-news ones
Taught	Sets the standard: reviews, onboarding, internal docs	Raises everyone around them

Write the level you need next to each skill in the brief. Most roles need one or two at Owned and the rest at Applied. Briefs demanding Owned on nine skills are why roles stay open for months.

4. Skills decay at different rates

Treating every skill as equally durable is why teams reject people over a two-year gap in a tool that changed twice in that period anyway. The brackets below are a working rule of thumb, not a measured finding.

Skill type	Rule-of-thumb half-life	Example
Specific tool or version	1–2 years	A build pipeline, a vendor's console workflow, a named model version
Platform or ecosystem	3–5 years	The JVM ecosystem, a major cloud, CRM administration
Domain and market knowledge	5–10 years	How medical device procurement works, how DACH mid-market buys
Reasoning and craft	Effectively no decay	Statistical reasoning, debugging under pressure, discovery questioning

The rule: filter hard on the slow-decaying rows and treat the fast-decaying ones as onboarding cost, not entry requirements.

What skills-based screening looks like for a backend engineer

The brief says Java, Spring Boot, Kafka, AWS, five years.

Candidate A has six years on the JVM writing Kotlin, uses Ktor rather than Spring, runs an event pipeline on RabbitMQ, and deploys to Google Cloud. Keyword match: one of four, so most filters drop them before a human looks. On evidence: six years owning production JVM services, message-driven design including idempotent consumers and replay, and a pager for a live system. Kotlin and Java share the same bytecode and tooling, so the transfer cost is a fortnight.

Candidate B lists all four terms. Read the lines underneath: Java is a nine-month junior role, Kafka appears once in a tutorial project, and AWS is a certification with no production work behind it. Keyword match: four of four, ranked top of your list.

The filter did not merely miss Candidate A. It put Candidate B in front of your hiring manager, who spent an hour discovering what the CV could have told you. That is how a healthy pipeline produces a bad shortlist.

What it looks like for a field sales role

The brief says enterprise field sales, Benelux, five years, native Dutch.

A candidate spent six years selling a similarly priced product into mid-market manufacturers across DACH, on a five-month average cycle with four to six stakeholders per deal, building the territory from a cold base.

What transfers: multi-stakeholder qualification, running procurement in a conservative European buying culture, building a territory from nothing, and the pattern recognition for which deals are real. What does not: the personal network, which takes a year to rebuild, and the language if buyers do business in Dutch.

So split the brief. Native Dutch is a hard constraint if the buyers speak Dutch. Benelux experience is a proxy for it, not the constraint itself. Keep at most five hard constraints per role and demote everything else to a scoring signal. In my experience that single edit widens a defensible longlist more than any sourcing change, and it starts with writing the job brief around real requirements rather than a copy of the last ad.

How to start on Monday without new software

1. Rewrite one open brief as a list of skills, each with a required evidence level and a decay class. Delete anything you cannot describe evidence for.
2. Write the adjacency list with the hiring manager before sourcing starts. Ask who succeeded in this team without the standard background, and why.
3. Split the requirements into hard constraints and proxies. Cap the constraints at five.
4. Interview for level, not familiarity. "Walk me through the last time this broke in production and what you did" usually separates Applied from Owned in two answers. Put the evidence, not the impression, into the interview scorecard.
5. Audit your rejections, not your hires. Pull fifty CV-stage rejections from last quarter, re-read ten against the skills list, and count how many you would now take to a call. That number is the filter's cost.

Where software actually helps

The manual version works. It stops holding up at volume: grading evidence level on 400 applications by hand is not something a team does at 5pm on a Thursday.

Pickr is the AI-native recruiting platform that scores every candidate on evidence of skills, including adjacent and transferable ones, instead of keyword presence in a CV, and it does that continuously rather than when someone remembers to run a search. Candidate data is hosted in Germany. That is one part of a broader idea about what an AI recruiting brain is for. Before changing software, the free recruiting audit reads your real hiring history and shows where drop-off happens. When the largest single loss in the funnel sits at the CV screen, the filter is not protecting the process. The filter is the process.

You do not have to buy anything to fix this. You do have to decide whether you are hiring people who can do the work or people who wrote down the right words, because the two lists are not the same list, and the difference shows up a year later in your placement rate or your retention numbers.