Boolean retrieval was formalised in the early 1970s for librarians querying bibliographic databases over teletype. It was a good design. It is still the interface most recruiters use to find people, which is roughly like navigating with a sextant because it worked for the Admiralty.
The problem is not that operators are bad. The problem is what a keyword string assumes: that the words in your head are the words on the profile. In sourcing, they almost never are.
Where the string breaks
Here is a real query, lightly anonymised, for a senior infrastructure role:
("site reliability" OR "SRE" OR "infrastructure engineer")
AND (kubernetes OR k8s) AND (terraform OR pulumi)
AND NOT (junior OR intern OR "student")
It is a competent string. It also silently excludes:
- The engineer whose title is "Platform Engineer" because that is what her company calls the team
- The engineer who has run production Kubernetes for four years but wrote "container orchestration" on his profile
- The engineer who has never touched Terraform because her employer standardised on CloudFormation, and who would be productive in Terraform in a week
- Anyone at a company where the infrastructure team sits inside a product org and the titles reflect the product
And it silently includes anyone who put Kubernetes in a skills list after a weekend tutorial, because a keyword match cannot tell the difference between having done something and having mentioned it.
The vocabulary problem is not solvable with more OR
The usual response to a miss is to widen the string. Add "Platform Engineer". Add "container orchestration". Add CloudFormation. This works for the specific miss you noticed and does nothing for the class of misses it belongs to, because you are enumerating a vocabulary that has no fixed size.
Job titles in particular are a moving target. We track roughly 40,000 distinct engineering titles across the profiles we index, and the long tail is not noise. It is companies naming things after their own architecture. "Developer Experience Engineer" and "Build Systems Engineer" and "Internal Tools Engineer" are frequently the same job, and no string contains all three unless someone thought of all three.
That last figure comes from a small internal exercise. We took twelve strings written by experienced sourcers, ran them against a pool where we had manually labelled who was genuinely qualified, and measured what the string returned. The median string found 42 percent of the qualified pool. The sourcers, shown the misses afterwards, agreed with the label in almost every case.
Recall you cannot see
The deeper issue is epistemic. A search interface shows you what it found. It has no way of showing you what it did not, so there is no feedback signal telling you your string is too narrow. You get results, the results look reasonable, and the eighteen people you missed never enter the conversation.
Recruiters compensate with volume, running six strings instead of one and sourcing from three platforms, which raises recall a little and raises effort a lot. It also means the same person surfaces four times and gets deduplicated by hand.
What replaces the string
Not natural language search as a marketing phrase. What actually has to change is the unit of matching. A string matches tokens. What you want is a system that matches a description of a person against the evidence in a profile, which requires two things a keyword index does not have:
- A representation that survives paraphrase. "Ran production Kubernetes" and "operated containerised workloads at scale" need to land in the same place. This is what embeddings are genuinely good at, and it is why a semantic index finds the Platform Engineer without anyone having thought to type "Platform Engineer".
- A judgement step over the retrieved set. Retrieval gets you a candidate pool that is broad and noisy. Something then has to read each profile against your actual requirements and say why it does or does not fit. Without that second pass you have replaced a precise-and-narrow tool with a fuzzy-and-wide one, which is not obviously an improvement.
The combination is what makes the difference. Broad retrieval means you stop missing people for vocabulary reasons. Evidence-based judgement over that pool means the breadth does not turn into a thousand profiles to sift.
Keep the operators
None of this is an argument for taking Boolean away. There are constraints that are genuinely binary and should be expressed as such. Work authorisation, a hard location boundary, a security clearance, a licence. Handing those to a language model is worse in every respect: slower, more expensive, and less predictable than an index lookup that has been correct since 1974.
The right shape is a filter for the things that are actually filters, and a description for the things that are actually descriptions. Most sourcing tools force everything into the first category, which is why sourcers spend their afternoons writing parentheses instead of talking to people.
