A recruiter opening 400 applications for one role isn't reading all 400 closely, no matter how the process is described on a company's careers page. Automated screening exists because that math never worked. What most people don't see is how the ranking actually happens under the hood, and it matters, because the two dominant approaches fail in different ways.
"Resume screening AI" covers two genuinely different systems, and knowing which one you're dealing with changes what actually gets a resume through.
Keyword and rules-based matching is the older, still widely deployed approach. The system parses a resume into structured fields (skills, titles, dates, education), extracts terms, and scores against a checklist derived from the job posting, sometimes with simple synonym expansion (e.g. matching "JS" to "JavaScript"). It's fast, cheap to run, and easy to audit, but brittle: a candidate who describes the exact skill the job wants using different words than the checklist expects can score poorly despite being qualified.
Embedding-based semantic matching is the newer approach, and it's meaningfully different. Instead of exact keyword hits, the resume and the job description are both converted into dense vector embeddings (using a language model trained to capture meaning, not just surface text), and candidates are ranked by vector similarity, cosine similarity between the resume embedding and the job embedding, typically. This catches paraphrases and related-but-differently-worded experience that keyword matching misses ("built ETL pipelines" scoring reasonably against "designed data ingestion workflows," for instance), but it introduces its own failure mode: it can surface superficially similar resumes that don't actually match on the specifics that matter, and it's much harder for a recruiter to audit why a given resume scored the way it did, because there's no explicit rule to point to.
The honest case for either system is time, not fairness. They cut through volume fast, so recruiters spend attention on candidates who cleared a bar instead of skimming everything. Whether either approach reduces bias is a more contested claim than vendors usually present it as: a system scoring purely on skills and qualifications against a job description can sidestep some forms of human bias, but only if the underlying model wasn't trained on historical hiring decisions that already encode that bias. A model trained to predict "which resumes did past recruiters advance" learns whatever pattern was already present in those decisions, including bias, without needing an explicit protected-class feature to reproduce it; school prestige, zip code, and employment gaps can all function as indirect proxies.
The core risk with keyword-based systems is straightforward: a strong candidate whose resume doesn't happen to match the system's expected phrasing gets filtered out before a human ever sees it. That's not a rare edge case, it's the direct, predictable consequence of optimizing for keyword or format match instead of judgment, and it narrows the applicant pool in ways that are genuinely hard to notice from the hiring side, because the rejected resumes simply never surface for review.
Parsing failure is a separate, more mechanical problem that affects both approaches: multi-column layouts, tables, text embedded in images, and unusual fonts can all defeat a parser regardless of how sophisticated the ranking model behind it is. A resume that a parser can't extract clean text from effectively doesn't exist to the system, no matter how strong the underlying candidate.
| Tool | Stage | Approach |
|---|---|---|
| LinkedIn Talent Solutions | Sourcing / initial screening | Hybrid keyword and profile-graph matching |
| HireVue | Screening + video interview analysis | Resume screening paired with structured video assessment scoring |
| Most modern ATS platforms (Greenhouse, Lever, Workday) | Application intake and ranking | Increasingly embedding-based, layered on top of legacy keyword rules |
Both LinkedIn Talent Solutions and HireVue are built around the same underlying trade-off described above: speed at some cost to recall on candidates who don't fit the system's expected pattern, whether that pattern is keyword-based or embedding-based.
Write for the parser first, then for the human, not because the human doesn't matter, but because a resume the parser can't read never reaches the human at all. Use standard section headers (Experience, Education, Skills), avoid tables, columns, and text boxes that break parsing, and match the language in the job posting where it's honest to do so, since both keyword systems and embedding-based systems reward phrasing that's closer to the posting's actual wording. A visually clever resume that a screening tool can't parse correctly never reaches the recruiter, regardless of how good the candidate is.