You have 3,000 candidates in a spreadsheet and 80 open roles to fill. A recruiter can manually review maybe 50 candidate-role combinations per day with any real attention. At that rate, evaluating every possible pairing would take 13 years.

Nobody does that, of course. Recruiters use keyword searches, filters, and gut instinct to narrow the field. But keyword search misses qualified candidates who describe their experience differently than the job description. Filters are binary — a candidate either has “5 years experience” or they do not, with no credit for 4 years and 10 months. And gut instinct does not scale.

The matching approach is different: compute similarity across every candidate-role pair, rank by fit, and surface the top candidates per role. The challenge is making this work at scale without drowning in false positives or missing strong candidates who use different vocabulary.

The anatomy of a candidate-to-job match

A good match between a candidate and a job requirement is rarely about a single field. It is the combination of multiple signals, each carrying different weight depending on the role.

Matching signals and their reliability for candidate-job fit
Signal Matching method Reliability Common pitfall
Skills overlap Embedding similarity High Keyword matching misses synonyms (React vs React.js)
Experience level Numeric comparison High Ignoring adjacent levels (Senior vs Lead)
Industry background Embedding similarity Medium Over-weighting industry when skills transfer
Location / remote String pre-filter High Not accounting for relocation willingness
Education String match + extraction Low-Medium Treating it as a hard filter when role doesn't require it
Title progression AI enrichment Medium Matching current title only, ignoring trajectory
Compensation fit Numeric range High Missing when one side doesn't disclose

Reliability reflects how often the signal correctly predicts a strong hire, not how easy it is to match.

The key insight for anyone building a matching workflow: no single signal is sufficient. Skills overlap is the strongest individual predictor, but a candidate with perfect skills and wrong seniority is not a match. Location matters until the role is remote. Education matters for some industries and not at all for others.

A matching workflow needs to combine these signals with configurable weights, so the same infrastructure can handle a junior developer search (skills-heavy, location-flexible) and a hospital CFO search (industry-heavy, seniority-critical, location-fixed).

Step 1: Structure both sides of the match

The first obstacle is that candidate data and job data are almost never in the same format. Job descriptions are prose paragraphs. Candidate data is a mix of structured fields (name, email, location) and unstructured content (resume text, “about me” summaries).

Before matching can happen, both datasets need to be in a comparable format.

For job requirements, this means extracting matchable attributes from job descriptions:

Extracting structured fields from a job description
Raw text (excerpt) Extracted field Extracted value
We're looking for a Senior Backend Engineer... Seniority Senior
...with 5+ years of experience in Python or Go Min experience 5 years
...strong experience with distributed systems, Kafka, and PostgreSQL Skills Distributed systems, Kafka, PostgreSQL, Python, Go
...based in our Austin office or remote US Location Austin, TX / Remote US
...reporting to the VP of Engineering Reports to VP of Engineering

AI extraction converts prose job descriptions into structured, matchable columns.

For candidate data, the same extraction applies to resume text or PDF files. If the candidate dataset has a “Resume” column containing free text or a file column with uploaded PDFs, AI extraction can parse out skills, experience years, education, and other structured attributes.

The extraction step is what makes matching possible between two datasets that do not share a common schema. After extraction, both sides have comparable structured columns: skills, experience, location, seniority.

Step 2: Pre-filter to reduce the search space

With 3,000 candidates and 80 roles, the full cross product is 240,000 pairs. Most of those are obviously wrong — a data scientist candidate should not be evaluated against every marketing manager opening. Pre-filters eliminate impossible matches before the expensive AI evaluation runs.

Effective pre-filters for talent matching:

Location filter. If the role requires on-site presence in a specific city, exclude candidates in other cities. This is a string pre-filter — fast, binary, and eliminates a large percentage of pairs.

Seniority filter. A junior candidate should not match against a director-level role. Map both sides to a seniority scale (Junior, Mid, Senior, Lead, Director, VP, C-level) and allow matches within one level in either direction.

Function filter. If your candidate pool spans multiple functions (engineering, marketing, sales, operations), filter candidates to roles within their function. This can be a string contains filter on title or department.

Pair reduction after sequential pre-filters
No filters 240,000 pairs (3,000 × 80)
100% of total
Location filter ~108,000 pairs remaining
45% of total
+ Seniority filter ~52,800 pairs remaining
22% of total
+ Function filter ~19,200 pairs remaining
8% of total

Pre-filters typically eliminate 80-95% of candidate-role pairs before AI matching runs. Exact reduction depends on data distribution.

The pre-filters cut the candidate pairs from 240,000 to roughly 19,000 — a 92% reduction. This matters because the expensive steps (embedding similarity, LLM evaluation) now run on 19,000 pairs instead of 240,000. The cost and runtime drop proportionally.

Step 3: Embedding similarity for semantic matching

After pre-filtering, the surviving candidate-role pairs go through embedding-based similarity. This is where the matching gets intelligent.

Embedding models convert text into high-dimensional vectors where semantic meaning is preserved. “5 years of Python and Django experience” and “senior Python developer with web framework background” end up close together in vector space because they encode overlapping concepts, even though they share almost no exact words.

For talent matching, the fields that benefit most from embedding similarity are:

  • Skills — handles synonyms, abbreviations, and related technologies
  • Job title / role — “Software Engineer II” vs “Mid-level Developer”
  • Industry / domain — “fintech” vs “financial services technology”
  • Summary / bio — overall profile-to-description semantic similarity

Fields that should not use embedding similarity:

  • Location — “San Francisco” and “San Diego” are semantically similar but geographically different. Use string matching.
  • Years of experience — numeric comparison is more precise.
  • Compensation — numeric range comparison.

The output of this step is a similarity score per candidate-role pair, typically between 0 and 1. Candidates scoring above your threshold (say 0.65) advance to the next step. Those below are excluded.

Step 4: LLM confirmation for nuanced evaluation

Embedding similarity catches semantic overlap but misses nuance. Two candidates might score identically on skills similarity, but one has directly relevant project experience while the other has the skills in a different context.

LLM confirmation adds a reasoning layer. For each candidate-role pair that passed the similarity threshold, an LLM receives the candidate profile and job description and evaluates the fit with structured reasoning.

A well-designed LLM confirmation prompt for talent matching looks something like:

Given this candidate’s profile and this job description, evaluate fit across three dimensions: (1) skills alignment — does the candidate have the required and preferred skills? (2) experience relevance — is the candidate’s experience in a relevant domain and at the right level? (3) overall fit — considering all factors, is this candidate likely to succeed in this role? Respond with a rating (Strong fit / Moderate fit / Weak fit) and a one-sentence justification.

The LLM’s reasoning becomes part of the output. When a recruiter reviews the shortlist, they see not just a match score but an explanation: “Strong fit — candidate has 6 years of Python/Django experience in fintech, matching the role’s requirements for senior backend engineering in financial services. Has led a team of 4, relevant for the team lead responsibilities mentioned.”

This reasoning is what turns a ranked list into an actionable shortlist. The recruiter can evaluate the LLM’s reasoning and decide whether to advance the candidate, rather than interpreting a naked similarity score.

Step 5: Rank and deliver

The final output is a ranked list of candidates per job, with match scores and (optionally) LLM reasoning. The format depends on what the client needs:

Sample matching output — Senior Backend Engineer role
Rank Candidate Match score Top signals LLM verdict
1 Priya Sharma 0.91 Python 8yr, distributed systems, fintech Strong fit
2 James O'Brien 0.87 Go/Python 6yr, Kafka, payments domain Strong fit
3 Lin Zhang 0.82 Python 5yr, PostgreSQL, e-commerce (adj. domain) Moderate fit
4 Amara Osei 0.78 Python/Java 7yr, microservices, healthcare Moderate fit
5 Carlos Ruiz 0.74 Node.js/Python 4yr, startup experience Moderate fit — experience slightly junior

Output includes rank, score, key matching signals, and LLM evaluation. Recruiters use this as a shortlist, not a final decision.

For a consultant running this as a service, the output CSV is the deliverable. For an in-house recruiting team, it feeds into their existing ATS workflow. Either way, the matching has reduced 3,000 candidates to a handful of ranked shortlists per role — work that would have taken weeks of manual screening compressed into a configured matching run.

Handling the edge cases

Real-world talent matching has complications that simple tutorials skip over.

Career changers. A product manager transitioning to UX design has the soft skills but not the portfolio. Embedding similarity on skills alone will rank them low. Adding a “transferable skills” extraction step — pulling out communication, stakeholder management, user research from their PM experience — can surface these candidates as moderate fits when the LLM evaluates holistically.

Overqualified candidates. A VP of Engineering applying for a senior IC role will score high on skills but the seniority mismatch matters. A seniority pre-filter catches the extreme cases, but borderline situations (Staff Engineer applying for Senior) need LLM reasoning to evaluate whether the candidate is genuinely interested in the role level.

Thin profiles. Some candidates have minimal data — a name, email, current title, and nothing else. With sparse data, embedding similarity produces unreliable scores. Flag these candidates separately rather than ranking them against candidates with rich profiles. They need manual outreach before matching can evaluate them.

Multi-role candidates. A full-stack developer might be a strong match for both a frontend role and a backend role. The matching output should allow candidates to appear on multiple shortlists, with different match scores and reasoning per role.

Putting it together

A complete candidate-to-job matching workflow combines extraction, pre-filtering, embedding similarity, and LLM confirmation into a pipeline that processes thousands of pairs and outputs ranked shortlists. Each step is configurable — different clients, different roles, and different candidate pools all need different configurations.

The workflow does not replace recruiter judgment. It replaces the hours of keyword searching, manual filtering, and spreadsheet sorting that precede judgment. When a recruiter receives a shortlist of 10 candidates ranked by multi-signal fit with explanations, they can spend their time on the work that actually requires human expertise: evaluating culture fit, selling the opportunity, and managing the relationship.

Match Data Studio handles the full pipeline — CSV ingestion, AI extraction from resumes and job descriptions, configurable pre-filters, embedding similarity, LLM confirmation, and ranked output. Upload your candidate and job data, configure the matching strategy, and get shortlists with scores and reasoning. Try it with your data —>

Keep reading