How AI Matches Candidates to Jobs

Candidate-to-JD matching used to mean keyword search: count how many words in the resume match words in the job description, rank by hits. Modern AI matching is several layers more sophisticated, and the layers are worth understanding because they explain both why it works and where it breaks.

The five-stage matching pipeline

1. Parse

Both the resume and the job description are parsed into structured data. Skills, dates, employers, education, location for the resume; required skills, nice-to-haves, seniority indicators, location, comp band for the JD. Modern systems handle 95%+ of standard formats and 80 to 90% of edge cases (heavy graphics, scanned PDFs, non-English).

2. Map to ontology

Skills are mapped onto an ontology, a graph of how skills relate. “PostgreSQL” equals “Postgres.” “React” sits under “JavaScript framework experience.” “Stripe API” implies “payments integration.” The ontology is what stops the same candidate from looking different to a keyword search depending on what words their resume happens to use.

3. Semantic match

Beyond skills, the model evaluates the experience narrative: did the candidate actually do the work, or just list the technology. Did the seniority of their projects match the seniority of the role. Did their trajectory suggest they are ready for this level. The semantic layer is where modern AI noticeably outperforms keyword scoring.

4. Rank against the rubric

The matched signals are scored against the role rubric: must-have weights, nice-to-have weights, disqualifiers. The rubric is set per role family, not per req, so the calibration work compounds across reqs in the family.

5. Explain the ranking

The output is not just a score; it is a score with reasoning. “Ranked at the top because: 7 years Python, distributed systems experience at scale, recent contributions to relevant open-source projects.” The explanation is what lets recruiters and hiring managers trust or override the ranking.

The pipeline is layered. Skipping a layer is what makes a system feel either dumb (no ontology, missed equivalents) or generic (no semantic match, every candidate looks the same). Both are common in less-mature platforms.

Where the pipeline still gets things wrong

• Career-changers: the model anchors on past role rather than skill trajectory
• Bootcamp candidates and non-traditional paths: under-ranked when seniority is read as years
• Tier-2 employer experience: real skill but lower prestige signal weighted too heavily
• Non-English resumes: parsing accuracy drops, ranking drops with it
• Niche or executive roles: the rubric has fewer training signals to learn from

What separates good matching from average

• Ontology depth: how many skill equivalents and hierarchies the system recognises
• Semantic depth: does the model actually read the experience or just count tokens
• Rubric expressiveness: can recruiters set weights, must-haves, disqualifiers cleanly
• Explanation quality: can the system tell you why a candidate ranked where they did
• Override behaviour: does the recruiter override become training data, or just a one-off

How to test matching during evaluation

Pull 5 candidates you know well from a closed role: the hire, the runner-up, two strong-but-not-hired, and one who would never have made it. Run them against the brief in the new platform and look at the ranking and the reasoning. The platform that ranks them roughly the way you would, with reasons that match your own thinking, is the one that will calibrate well in production.

For accuracy benchmarks, see how accurate AI resume screening is. For the related question of customising the JD to get better matches, see customising job descriptions for better matches.