Candidate matching is the step where a hiring team decides which profiles are worth a recruiter's time. For most of recruiting's history that meant Boolean search and keyword filters. Newer tools add semantic matching with embeddings and large language models, and many present the result as a single percentage or star rating. Each approach has strengths, but each also fails in predictable ways — especially in markets like India where resumes are written to pass filters.
This guide explains how the three main approaches work — keyword, semantic and evidence-based — why opaque fit scores cause more problems than they solve, and how to structure requirements into must-haves and good-to-haves so that matching produces shortlists a recruiter can actually explain to a hiring manager.
Keyword matching: fast, familiar and easy to game
Keyword matching looks for exact terms or Boolean combinations: 'Java AND Spring AND (Kafka OR RabbitMQ)'. It is transparent — you can see exactly why a resume matched — and it is fast across large databases. For narrowly defined roles with distinctive terms, such as 'SAP MDG' or 'Data Migration Cockpit', it can be surprisingly effective as a first filter.
Its weakness is that it measures vocabulary, not experience. A resume that lists every tool in a skills block will match more queries than one that describes three real projects in depth. Candidates and vendors know this, which is why keyword-stuffed resumes are so common. Keyword matching also misses synonyms and adjacent skills: someone with deep Azure Data Factory and dbt experience may be an excellent fit for a role that asks for 'ELT pipelines' but never uses those words.
Semantic matching: better recall, new blind spots
Semantic matching represents resumes and JDs as vectors (embeddings) so that related concepts land close together. 'Built streaming pipelines on Spark Structured Streaming' can match a JD asking for 'real-time data processing' even without shared keywords. Large language models can go further and reason about whether experience is relevant. This improves recall significantly, surfacing candidates keyword search would have missed.
The blind spot is that semantic similarity is not the same as meeting a requirement. Two resumes can be 'close' to a JD because they discuss the same domain, while only one has actually done the work at the required depth. Semantic models also tend to produce a single similarity value, which gets presented as a score and quietly becomes the ranking. Without a breakdown, a recruiter cannot tell whether a high similarity reflects the must-haves or just a lot of related vocabulary.
Evidence-based matching: requirement by requirement
Evidence-based matching starts from the JD rather than the resume. The job description is broken into discrete requirements — for example 'three or more years of production React', 'experience with S/4HANA greenfield or brownfield implementation', 'has deployed an LLM application with retrieval' — and each requirement is checked separately against the candidate's profile. The result is not a number but a table: for each requirement, is there evidence, partial evidence or no evidence yet, and where did that evidence come from?
This approach uses semantic understanding under the hood, so it still catches synonyms and adjacent phrasing, but it keeps the reasoning visible. A recruiter can see immediately that a candidate has strong evidence for four of five must-haves and nothing yet on the fifth, and can decide whether that gap is disqualifying or simply something to ask about on the call.
- Requirements are explicit and editable by the recruiter
- Each requirement shows its own evidence status
- Evidence links back to the resume line, project or document it came from
- Gaps become interview questions rather than silent rejections
- Hiring managers can review the same breakdown and disagree specifically
Why opaque fit scores fail
A single fit or hireability score is attractive because it sorts a list instantly. But it compresses many different judgements — skills, seniority, domain, tools, location — into one number with hidden weights. Two candidates with the same '82%' can have entirely different strengths and gaps, and a candidate at '64%' may be the only one who meets the hardest must-have. Recruiters under time pressure rarely look past the top of a sorted list, so the score effectively makes the decision.
Opaque scores are also hard to audit for fairness. If a model has learned proxies for protected attributes — a graduation year that signals age, a name, a college, a career gap — the score will reflect them without anyone noticing. When the reasoning is hidden, bias is hidden too. Requirement-level evidence does not eliminate that risk entirely, but it makes it far easier to spot when something irrelevant is influencing outcomes.
Must-have vs good-to-have: getting requirements right
Matching can only be as good as the requirements it is matching against. Many JDs in India are long lists copied from previous roles, with fifteen or twenty 'required' skills that no single candidate could plausibly have. The result is that matching tools either find nobody or reward whoever lists the most keywords. Splitting requirements into a short list of genuine must-haves and a longer list of good-to-haves fixes most of this.
A useful test for a must-have is: would you reject an otherwise excellent candidate who lacked it? For a senior SAP FICO consultant, end-to-end implementation experience may pass that test while a specific industry vertical may not. For a data engineer, production experience with at least one of Spark, Databricks or Snowflake may be a must-have while specific orchestration tools are good-to-haves that can be learned quickly.
- Keep must-haves to roughly three to six items
- Phrase requirements as capabilities, not just tool names
- Allow equivalents where they genuinely transfer (for example Airflow vs other orchestrators)
- Separate seniority expectations from tool lists
- Add practical constraints — location, notice period, work mode — explicitly
- Review requirements with the hiring manager before sourcing starts
How RecruitGPT approaches matching
RecruitGPT uses AI to structure the JD into must-have and good-to-have requirements and to structure each resume into skills, projects and experience. It then shows, per requirement, whether there is Evidence found, Partial evidence or No evidence yet, with provenance labels such as Candidate Provided, AI Extracted, Candidate Confirmed or Verified so recruiters know how much weight each item deserves.
There is no opaque fit or hireability score, no automatic rejection, and no inference of protected attributes such as age, gender, religion, caste, marital status or disability; photos are not used. Recruiters decide who moves forward, and candidates control who can see their profile.
A matching checklist for recruiters
Whatever tools you use, a few habits make matching far more reliable. Most of them are about being explicit — about requirements, about evidence, and about what the tool is and is not doing on your behalf.
- Agree must-haves with the hiring manager before searching
- Use keyword search as a first filter only for distinctive terms
- Check that each shortlisted candidate has evidence, not just mentions, for must-haves
- Treat 'no evidence yet' as a question to ask, not an automatic no
- Watch for duplicate profiles submitted by multiple vendors
- Record why each candidate was advanced or not, in terms of requirements
- Periodically review who is being filtered out and why
These habits make shortlists easier to defend, easier to calibrate with hiring managers and less vulnerable to resume inflation.
See evidence, not just keywords
RecruitGPT structures your job description into clear requirements and shows, for each candidate, the evidence behind every one — labelled by source and verification status. Recruiters make every decision.
Frequently asked questions
What is the difference between semantic and evidence-based matching?
Semantic matching measures how similar a resume is to a JD overall, usually producing one similarity value. Evidence-based matching breaks the JD into individual requirements and checks each one separately, showing where evidence exists and where it does not. Evidence-based matching often uses semantic techniques internally but keeps the reasoning visible.
Are AI fit scores ever useful?
A score can be a rough sorting aid, but it becomes risky when it replaces judgement. It hides which requirements were met and can carry hidden bias. A requirement-level breakdown gives recruiters the same speed benefit while keeping decisions explainable.
How many must-have requirements should a JD have?
Usually a small number — often three to six — that you would genuinely reject a strong candidate for lacking. Everything else belongs in good-to-have. Overloaded must-have lists tend to reward keyword stuffing and shrink the pool unnecessarily.
Does evidence-based matching help with keyword-stuffed resumes?
Yes, because a skill that is only listed, without any project, role or outcome attached, shows up as partial or no evidence rather than a match. That does not replace interviewing, but it pushes profiles with real, described experience to the recruiter's attention.
Can matching tools introduce bias?
They can, especially if they learn from past hiring decisions or use signals like names, photos, graduation years or addresses. Avoiding protected-attribute inference, excluding photos and keeping reasoning visible at the requirement level all reduce the risk. Regular human review of who is being filtered out is still essential.