Why Your Candidate Search Returns Irrelevant People: Retrieval Is Not Qualification

Direct answer

When a search returns people who are obviously wrong, the instinct is to add requirements. That usually makes it worse. Retrieval decides who is eligible to be seen; qualification decides who is worth contacting. Adding a qualification constraint to fix a retrieval failure narrows the pool without removing the noise, because the noisy profiles often satisfy the new constraint too.

The distinction that fixes most searches

Retrieval is a matching operation over text that exists on a page. Qualification is a judgment about whether a person meets a requirement. A search engine cannot perform the second one. When you write "Senior Linux Administrator with 7 years experience", the retrieval layer sees tokens; it has no representation of seniority or duration. The years-of-experience clause does almost nothing to your result set except exclude people who did not happen to write that phrase.

Title collisions

Titles are the most overloaded tokens in sourcing. "Architect" returns software architects, solutions architects, enterprise architects, and licensed building architects. "Engagement Manager" returns consulting delivery leads and customer success staff. "Principal" returns senior individual contributors and school principals. The fix is not a longer title list; it is pairing every title with a disambiguating evidence term drawn from the work itself, so the title stops carrying the whole burden.

The Linux administrator example

A real pattern worth naming: searching for "Linux Administrator" as a title misses a large share of the people who do that work, because their titles are Systems Administrator, Systems Engineer, Infrastructure Engineer, Site Reliability Engineer, or Platform Engineer. Meanwhile the title search returns people whose only Linux exposure is a line in a skills list. Title recall is low and title precision is low at the same time, which is the signature of searching the wrong field. The fix is to search the evidence, RHEL, kickstart, satellite, systemd, Ansible, kernel tuning, and treat title as a secondary filter.

Skill terms that mean two things

Ambiguous surface forms are a persistent source of noise. TS/SCI is a clearance to a federal recruiter and TypeScript to a parser. "Go" is a language and a common verb. "R" is a language and a letter. "Spark", "Flink", "Beam", and "Storm" are all ordinary English words. Any of these will pull in unrelated documents unless paired with a term that only occurs in the intended context. Pair the ambiguous term with a companion that disambiguates it rather than hoping the engine infers your meaning.

Location noise

Location fields describe where a profile says someone is, which is not the same as where they work, where they are willing to work, or where they were when they did the work you care about. Metro-area labels swallow enormous geography. A search anchored on a metro label will return people two hours from the work site and exclude people who list a neighboring town. For on-site and cleared work, anchor on the facility, the installation, or the named community rather than the metro, and accept that you will need a second lane for people whose location is stated imprecisely.

A diagnostic you can run in ten minutes

Take twenty results from a search that feels wrong. Sort them into three piles: right person, wrong person, and cannot tell. For each profile in the wrong pile, find the single term that caused it to be retrieved. If most of them share one term, you have a retrieval defect and you should fix that term, not add a requirement. If the wrong pile is caused by many different terms, your query is too broad and needs a structural change rather than an edit. If the cannot-tell pile is the largest, the problem is not the search at all; it is that the sources you are searching do not carry the evidence the requirement needs.

When the answer is that the evidence does not exist

Some requirements cannot be retrieved from public sources at all. Clearance status, willingness to relocate, notice period, and compensation expectation are not reliably present in public text. Searching harder will not surface them. The correct move is to stop treating them as search constraints, move them to the screening conversation, and tell the hiring manager which requirements are being verified by conversation rather than by search. That is a calibration output, not a failure.

SourcingOS workflow

Boolean Doctor audits an existing string for over-constraint, ambiguous surface forms, and terms that are doing no work. BooleanOS builds lanes that separate title-led, evidence-led, and adjacency-led retrieval so you can see which lane is producing the noise. Candidate Search keeps retrieval terms and candidate evidence strictly separate, so a term you searched for never appears as something a candidate claimed.

Copy-paste starting strings

("Systems Administrator" OR "Systems Engineer" OR "Infrastructure Engineer") AND (RHEL OR "Red Hat" OR systemd OR kickstart) -recruiter -"looking for"

("Site Reliability" OR "Platform Engineer") AND (Ansible OR Terraform) AND ("Annapolis Junction" OR "Fort Meade" OR Odenton)

(TS/SCI OR "TS SCI") AND (polygraph OR "full scope" OR CI) -TypeScript -"type script"

FAQ