Semantic matching vs Boolean search for resume screening

What does Boolean search actually do?

It retrieves documents matching a logical expression over terms: Java AND (Kafka OR RabbitMQ) NOT junior. The result set is exactly the set of documents satisfying that expression — no more, no less, and no ordering beyond whatever the index provides.

Its virtues are real and often undersold. It is deterministic: the same query returns the same set today and next year. It is auditable: anyone can read the query and understand why a résumé did or did not appear. It is fast, cheap, and needs no model. And a skilled recruiter writing a careful query is genuinely hard to beat on a well-specified role.

Where does Boolean search fail?

On vocabulary. The query can only contain the words you thought of, and résumés are written by people who chose different ones. A candidate who spent four years building "ledger reconciliation at scale" does not contain the string "payments", and a query for payments experience will never see them.

It also fails on structure. Boolean has no concept of seniority implied by scope, or of a skill demonstrated rather than listed. "Led a six-person platform pod" is a tech-lead signal that no term match will find, and "migrated a monolith to services" implies distributed systems experience that the résumé never names.

The usual mitigation — longer queries with more synonyms — makes precision worse rather than recall better, because each added OR term drags in documents matching only that term.

How does semantic matching work?

Both sides are embedded into a vector space where distance approximates similarity of meaning, and candidates are ranked by proximity to the requirement. The résumé does not need to share vocabulary with the job description to score well; it needs to be about the same thing.

That is the whole trick, and it is why the reconciliation candidate surfaces for the payments role. It is also why the approach degrades differently from Boolean: instead of missing candidates, it returns plausible-looking ones that are subtly wrong.

Where does semantic matching fail?

On hard constraints, and this is the failure that matters. A vector space has no notion of "must". A candidate with outstanding relevance and the wrong work authorization sits close to the requirement, ranks high, and gets surfaced — because ranking is all it does.

It also fails on recency and duration. "Kubernetes" in a 2018 role and "Kubernetes" as the last three years of someone’s career embed similarly, and the requirement usually cares enormously about which one it is.

And it is harder to explain. A recruiter who cannot see why a candidate ranked third will stop trusting the ranking, which is a product failure even when the ranking is right.

Why must hard filters sit outside the ranking?

Because anything inside the ranking is negotiable by definition. Weight work authorization at 0.9 and a sufficiently strong candidate still outranks their own ineligibility; the model is doing exactly what a weighted sum is supposed to do.

The correct architecture runs the gates first — work authorization, location and remote policy, availability window, rate ceiling — and ranks only what survives. Shortlists get shorter and every row in them is submittable, which is the trade worth making.

This ordering also makes the system cheaper. Embedding and scoring only the eligible set removes a large fraction of the work on most requirements.

How do you make a semantic score trustworthy?

By showing the mapping rather than the number. A score of 0.83 tells a recruiter nothing they can act on. The specific evidence behind it does: this phrase in the résumé maps to this requirement, this one to that, and here is what the requirement asked for that nothing in the résumé supports.

Named gaps matter as much as matches. "No explicit Kubernetes — flagged for screening" turns a ranking into a screening agenda, and it lets the recruiter overrule the score with information rather than instinct.

It also improves the submission itself. A package that names its own gaps converts better than one that hopes the client does not notice, because the client will notice.

Should you use both?

Usually, yes, and in a specific order: hard filters, then semantic ranking, then Boolean as a recruiter-driven override on top of the ranked set.

The override matters. When a recruiter knows something the system does not — this client insists on a specific certification, this end client rejects anyone without financial-services exposure — a term filter over the ranked set is the fastest way to express it, and it is auditable in a way that adjusting weights is not.

• Gates first: authorization, location, availability, rate. Non-negotiable, no scoring.
• Semantic ranking over the survivors, with visible evidence per candidate.
• Boolean narrowing on top, driven by the recruiter, for constraints the system cannot know.
• Named gaps carried into the screen and into the submission package.

How do you evaluate a matching system honestly?

Not on precision at rank one, which is easy to game and not what the desk cares about. The useful measure is submittal-to-interview ratio segmented by route, compared against your own baseline from last quarter.

Watch for the specific failure of semantic systems: a rising ratio combined with a falling number of distinct consultants submitted. That pattern means the model has found a small set of strong generalists and is surfacing them for everything, which flatters the ratio while leaving most of your bench untouched.

And check the gates independently of the ranking. The question "did any ineligible candidate appear in a shortlist this quarter" should have a logged, provable answer, and that answer should be zero.

What does semantic matching cost to run?

More than Boolean and less than people fear, provided the ordering is right. Embedding a résumé is a one-off cost per document version, not a per-search cost, so the expensive part amortises across every requirement that candidate is ever considered for.

The per-search cost is embedding the requirement once and running a vector comparison over the eligible set. Running the hard filters first is what keeps that set small — on a typical requirement, work authorization and location alone remove most of a large candidate pool before anything is scored.

The cost that surprises teams is re-embedding. Change the embedding model and every stored vector is stale, which means a full re-index of every résumé. That is a real migration with a real bill, and it is worth choosing a model with the expectation of living with it rather than chasing benchmark improvements.

Against all of that, the comparison worth making is not Boolean-versus-semantic on infrastructure cost. It is either approach against the margin lost to a consultant sitting an extra three days because the right candidate never surfaced.