Boolean Search for Recruiters: What It Does Well, and the Five Things It Cannot Express

Boolean search has one real strength: it enforces facts precisely. Where it fails is not a syntax problem you can solve with more operators — it is that the criteria that decide most hires are not written on the page in any consistent form. Knowing exactly where that line sits saves a lot of wasted effort.

What boolean does well

Use it for facts that everyone writes the same way, and for pulling together the many names one job goes by. Syntax varies between platforms; the logic does not.

Gathering the titles that mean the same thing

The single highest-value use. One job, many labels:

("Senior Software Engineer" OR "Staff Engineer" OR "Principal Engineer"
 OR "Tech Lead" OR "Lead Developer" OR "Engineering Lead")

The same pattern for other functions:

("Head of Finance" OR "Finance Director" OR "Financial Controller"
 OR "VP Finance" OR "Head of FP&A")

("Account Executive" OR "Sales Manager" OR "Business Development Manager"
 OR "Enterprise Sales" OR "New Business Manager")

If you write only the title from the brief, you have already cut most of your pool.

Combining a title group with a hard constraint

("Product Manager" OR "Product Owner" OR "Senior Product Manager")
AND ("Berlin" OR "Munich" OR "Hamburg")

That is a good string. Titles gathered broadly, one genuinely hard constraint applied.

Excluding agency noise

... AND NOT ("recruiter" OR "recruitment consultant" OR "talent acquisition"
             OR "headhunter" OR "staffing")

Reasonable when you are hiring for an in-house role and agency profiles crowd the results. Note that this also removes in-house TA people, which matters if you are hiring one.

Certifications and languages

("CPA" OR "ACCA" OR "Chartered Accountant")
("native German" OR "muttersprachlich" OR "German (Native or Bilingual)")

These work because there are only a handful of ways to write them. That is precisely the condition under which boolean is reliable.

The five things boolean cannot express

Here is where more operators stop helping.

1. Scale

"Has run a team of twenty or more." There is no keyword for this. People write "led the engineering team" whether that team was four people or forty. The number is in their head, not on their profile.

The usual workaround is to filter on company size — which fails immediately, because a 2,000-person company contains plenty of people who led three.

2. Ownership versus participation

"Built the payment system" and "worked on the payment system" are the same keywords and completely different candidates. Boolean cannot tell you which one you are looking at. Only reading the surrounding sentences can.

3. Trajectory

"Progressing quickly", "has been in the same role too long", "moved up rather than sideways". These are patterns across dates, not words. No string expresses a shape over time.

4. Context

"Did this without a platform team." "Shipped in a regulated environment." "Operated with no budget." The candidate never says the absent thing, because absence is not something people list. You infer it from where they worked and when.

5. Absence itself

Boolean can only search for what is written. A criterion like "has not only ever worked at large companies" cannot be expressed at all — you can exclude specific employers, but you cannot ask a question about the shape of someone's whole history.

Why keyword proxies fail

Faced with the list above, the natural move is to find a keyword that stands in for the real criterion. This fails in both directions at once, which is what makes it so costly.

What you mean	The proxy	Who it wrongly lets in	Who it wrongly keeps out
Has scaled a team	"scaling" OR "hypergrowth"	Anyone who was present while a company grew	Anyone who did it without using those words
Fintech experience	industry = fintech	Marketing hires at fintech companies	People who built payments inside a marketplace
Startup experience	company size < 50	People at small but mature businesses	People who joined at 30 and stayed to 400
Owns systems	"architected" OR "designed"	Anyone repeating a job description	People who describe work plainly

Note the asymmetry in cost. The wrongly-included show up as noise in your list — annoying, but visible and cheap to reject. The wrongly-excluded never appear at all. You will never know they existed, which is why proxies feel like they work: the failure is invisible by construction. We go into that asymmetry in more depth in precision and recall in shortlists.

NOT is the most dangerous operator

Every exclusion is permanent and silent. Some common ones and what they actually do:

Exclusion	Verdict	Why
NOT "recruiter"	Usually fine	Clears agency noise, though it also removes in-house TA
NOT "intern" OR "student"	Fine	Genuinely disqualifying for a senior role
NOT "consultant"	Risky	Removes people who did the exact work under a consulting title
NOT [competitor name]	Bad	Removes anyone who mentions them in passing, including customers and partners
NOT "junior"	Bad	Removes senior people who once held a junior title at the same company

The rule: exclude a fact that disqualifies, never a word that correlates with something you dislike.

How to know your string is too tight

Three quick checks, none of which take more than a few minutes:

1. Remove one AND clause and re-run. If the count jumps a lot, that clause was doing heavy lifting — go and read twenty of the profiles it was excluding. If several are good, put the clause back only if it was a hard constraint.
2. Search for one person you know is right. Take someone you would definitely contact — a past placement, a person you already found by other means. Does your string return them? If not, it is too tight, and you have just proved it.
3. Look at the result count. If a wide-ish role in a decent-sized city returns fifteen people, the string is wrong, not the market.

The second check is the most useful and the least used. It converts an invisible failure into a visible one in about a minute.

The practical approach

Stop trying to encode judgement into the string. Use boolean for what it is good at, then do the rest by reading:

1. Gather titles broadly with OR. Every label that describes the job.
2. AND only hard constraints. Location, work authorisation, a required certification.
3. Use NOT twice at most, and only for genuinely disqualifying facts.
4. Accept a wide result set. If it feels uncomfortably large, that is roughly right.
5. Apply the judgement criteria while reading, against a written list — the process in building a shortlist from criteria.

A template to start from:

(title1 OR title2 OR title3 OR title4 OR title5)
AND (hard constraint)
AND NOT (one genuinely disqualifying term)

That is usually the whole string. If yours has six AND clauses, most of them are judgement criteria in disguise, and they are costing you good candidates you will never see.

Where this leaves you

Boolean gets you a wide, fact-correct pool. It cannot get you a shortlist, because the last mile is judgement and judgement requires reading. The only real question is who does the reading — and for a small team, that is the constraint that decides how many roles you can run at once.

If you are weighing up what should do that reading, our comparison of LinkedIn Recruiter alternatives for small teams sets out the four categories of tool and a 90-minute test that settles it on one of your live roles.

Hiris exists for that last mile: you keep the wide boolean pool, and the judgement criteria get applied at scale, with the supporting evidence attached to each profile so you are confirming rather than investigating. The strings above still matter — they are how you make sure the pool is wide enough to be worth evaluating.