Matching engineers to roles without letting the model decide

The problem

A technology employer received far more applications than its recruiting team could read. Keyword filters were the default triage, and they were bad in both directions: they rejected strong candidates whose résumés used different vocabulary, and they advanced weak candidates who happened to use the right words. Hiring managers complained about slate quality; recruiters were drowning; good applicants never heard back.

The hypothesis

Matching a candidate to a role is a semantic retrieval and evidence problem, not a scoring problem. A system that surfaced why a candidate might fit — with the specific experience that supports it — would let recruiters review far more people, far better, without ever handing the decision to a model.

The build

• Structured skill and experience extraction — parsing résumés and profiles into normalized skills, seniority, domains, and evidence spans, so "built distributed systems in Go" is recognized as related to a Go backend role even without keyword overlap.
• Requirement decomposition — the role's must-haves, nice-to-haves, and equivalents made explicit with the hiring manager, before any matching happens. Most bad matching is bad requirements.
• Evidence-first ranking — candidates surface with the specific experience supporting each requirement, and the gaps stated plainly. Recruiters read evidence, not a score.
• Deliberate blindness — names, photographs, ages, addresses, and institution prestige signals are excluded from the matching features. The model sees what the person has done.
• Adverse-impact testing in CI — selection rates across protected groups measured on every release, with the pipeline blocking on regression, plus periodic human audit of ranked slates.

Rollout

We ran shadow mode against historical requisitions with known outcomes, checking whether the system would have surfaced the people who were eventually hired — including the ones the keyword filter had missed. It did, which was the strongest argument for adoption. Fairness testing ran from day one rather than being added after launch.

Results

Recruiters review substantially more candidates in less time, hiring managers report better slates, and candidates who would have been filtered out on vocabulary now reach a human. Because the model never decides, the employer can explain its process to a regulator or a candidate in plain language.

What we'd tell you

• Fix the requirements before the model. Vague role definitions produce vague matches, expensively.
• Rank and explain; never auto-reject. It is better practice, better law, and a better feedback loop.
• Test for adverse impact in CI, not annually. Fairness is a regression risk like any other.
• Exclude prestige and demographic proxies deliberately — they leak in through features you would not expect.