Boolean Search

Boolean search is a small language and most of it can be learned in a few minutes.

Brackets are what make longer strings behave. Without them, a search for payroll OR wages AND compliance is ambiguous, and different platforms resolve the ambiguity differently, so the same string returns different results in different places.

The habit worth forming is to bracket every OR group, always, even when it seems unnecessary. It costs nothing and removes an entire category of silent error.

Most people reach first for AND, and it is the operator least likely to help.

The reason is that job titles are not standardised. The same role is a talent acquisition partner at one employer, a recruiter at another, a recruitment consultant at a third and a hiring specialist at a fourth. A search for one of those finds a quarter of the market and misses the rest, and the miss is invisible.

The productive pattern is to build an OR group for each concept in the requirement, then combine the groups with AND.

So a search for someone doing payroll compliance work becomes a group of title variants, combined with a group of subject variants, combined with any hard requirement. Each group widens, and the combination narrows. That is nearly always better than a narrow search that was precise about the wrong words.

The same applies to qualifications, tools and locations, all of which people describe inconsistently.

NOT is satisfying, because it removes the profiles cluttering the results, and it is the operator most likely to remove someone you wanted.

The problem is that it excludes on a mention, not on a meaning. Excluding the word agency to avoid agency recruiters also removes the in-house recruiter who once worked at an agency, the person who wrote that they reduced agency spend, and anyone whose employer has the word in its name.

Two habits make it safer. Use NOT only for terms that cannot plausibly appear for an innocent reason, and run the search with and without the exclusion to see what it removed. If the count drops sharply, the exclusion is doing more than intended.

Where a term is genuinely ambiguous, it is usually better to leave it in and filter by eye than to exclude it and never know.

Nobody writes a good search in one go. The sequence that works is to start too wide and narrow deliberately.

• Write the requirement as concepts rather than as a job title. Two or three concepts is usually enough.
• For each concept, list every term a candidate might plausibly use, including abbreviations and older names for the same thing.
• Build each concept as a bracketed OR group.
• Combine the groups with AND, then look at the count.
• Narrow one group at a time, checking what disappears at each step rather than adding several conditions at once.

If the result set is very small, the usual cause is a concept expressed too narrowly rather than a genuinely rare skill. Widening the weakest group first is more productive than removing conditions at random.

Keeping the strings that worked is worth doing. Most organisations hire the same handful of role types repeatedly, and rebuilding the search each time wastes the learning from the last one.

Boolean support is not consistent, and the failures are quiet.

Some platforms require operators in capitals and treat lowercase and as an ordinary word. Some support AND implicitly between terms and ignore it if typed. Some do not support NOT at all and simply drop it, returning a result set that looks plausible and is wrong. Character limits on search fields truncate long strings without warning.

The practical defence is to test a string whose result you can predict before trusting it on a real search. A search that should return almost nothing, returning thousands, tells you an operator was ignored.

Internal databases are worth checking separately. A search across your own applicant records frequently behaves differently from the job board it was written for, and past applicants are usually the cheapest source in the funnel and the least searched.