Boolean search strings for recruiters, with real examples

A Boolean search string is a line of keywords joined by the operators AND, OR and NOT, with double quotes locking exact phrases and parentheses grouping alternatives, used to filter a large candidate database down to profiles worth opening. AND narrows, OR widens, NOT excludes; that is the entire grammar. The skill is not the syntax, it is feeding the syntax the right synonyms. Below: the five building blocks, one fully worked string for a senior React developer in Amsterdam with Azure experience, the LinkedIn quirks that silently break searches, and the point where Boolean stops being the right tool.

What do the five building blocks do?

Building block	What it does	Example
AND	Requires every connected term, narrows results	react AND azure
OR	Accepts any term in the group, widens results	(react OR reactjs)
NOT	Excludes a term or group	NOT recruiter
“quotes”	Locks a multi-word phrase together	“react developer”
( )	Groups terms and controls evaluation order	(senior OR lead) AND react

Two habits prevent most broken strings. First, always wrap OR groups in parentheses: senior OR lead AND react can be read as senior OR (lead AND react), which is a completely different search, and platforms disagree on which reading a bare string gets. Second, reserve quotes for phrases that genuinely must stay together. Quoting a single word adds nothing, and over-quoting is the fastest way to exclude good people who phrase things slightly differently.

How do you build a real string, step by step?

The brief: senior React developer, Amsterdam area, must have Azure experience. Build it in passes, running the search after each one.

Step 1: start from the hard requirements.

react AND azure

Huge and noisy, but it defines the correct universe. Everything from here narrows or cleans.

Step 2: expand the skill variants. People write React, ReactJS and React.js on their profiles, and a literal search treats those as three different words. Only expand where a variant does not already contain the base word: anyone writing Microsoft Azure or Azure DevOps still matches plain azure, so that side needs no group.

(react OR reactjs OR "react.js") AND azure

Step 3: add a title group. Job titles are the leakiest field in sourcing. The person you want may be a front-end developer, a frontend engineer, a JavaScript developer or a plain software engineer who happens to live in React all day. List the realistic variants with OR, and treat the longer tail of adjacent job titles and skills as a separate search rather than one monster string.

("react developer" OR "frontend developer" OR "front-end developer"
OR "front end developer" OR "javascript developer")
AND (react OR reactjs OR "react.js") AND azure

Step 4: handle seniority with suspicion. Senior is one of the least reliable words on any profile; plenty of eight-year engineers never write it, and plenty of two-year ones do. Add (senior OR lead) only if volume forces you to, and prefer a years-of-experience filter wherever the platform offers one.

Step 5: exclude the predictable noise. On platforms that match keywords against the whole profile, this string will surface recruiters who write about React roles all day. Close with a NOT group:

(senior OR lead) AND
("react developer" OR "frontend developer" OR "front-end developer"
OR "front end developer" OR "javascript developer") AND
(react OR reactjs OR "react.js") AND azure
NOT (recruiter OR "talent acquisition" OR intern OR student)

Collapse it to one line before pasting; the line breaks here are for reading.

Step 6: leave Amsterdam out of the string. A keyword location matches people who studied there a decade ago and companies headquartered there, while missing profiles that say Greater Amsterdam, Noord-Holland, or are written in Dutch. Use the platform’s location filter with a sensible radius instead, and keep the string about skills and titles.

Then iterate. Too few results: drop the seniority group or add title synonyms. Too much noise: extend the NOT group or tighten a phrase. A Boolean string is a draft you revise against the first two pages of results, not an incantation you write once.

Which LinkedIn quirks should you know?

LinkedIn is where most recruiter strings run, and where most of them quietly break. The platform’s role in your stack is a bigger question (we cover it in do I need an ATS if I use LinkedIn), but for the search box itself:

• Operators must be uppercase. A lowercase or is treated as the word or, and your carefully built groups dissolve into keyword soup.
• No wildcards. develop* does nothing. Enumerate developer OR development yourself.
• Punctuation is mostly ignored. C#, C++, .NET and React.js all degrade, which is exactly why symbol-heavy skills belong in OR groups of spellings rather than one exact form.
• Quotes must be straight quotes. Strings drafted in Word arrive with curly quotes and fail without an error message.
• Free search reads the whole profile. Headline, about section, recommendations, all of it. That is why the NOT recruiter group earns its place. Field-level targeting such as current title requires LinkedIn Recruiter.
• Keep free-tier strings short. Very long queries behave unreliably outside Recruiter. If a string needs ten OR groups, split it into two searches.

The same grammar travels: GitHub, job board CV databases and Google x-ray searches (site:linkedin.com/in plus your terms) all speak rough dialects of it, which matters once you start sourcing beyond LinkedIn.

When does semantic matching beat Boolean?

Boolean retrieves exactly what you enumerated and nothing else. It cannot know that someone listing Next.js and TypeScript almost certainly works in React, that front-end ontwikkelaar on a Dutch CV is your target title in another language, or that a software engineer with five years of component work is a stronger fit than a keyword-perfect profile. Every miss is invisible: you never see the people your string excluded.

Semantic matching compares the meaning of a profile against the meaning of a job, so synonyms, adjacent titles and phrasing stop being your problem; how candidate matching works walks through the mechanics. The practical split looks like this: Boolean for external databases where keyword access is all you get, and for hard, auditable requirements such as a certification or a named technology. Semantic ranking for any pool the system can read in full, starting with your own ATS, where past applicants you already paid to attract usually sit unsearched. An ATS with built-in sourcing closes that loop. The two are complements: Boolean fills the pool, matching ranks it.

Where does Recruitifly fit?

Boolean is how you pull candidates in from outside; once they are in your system, Recruitifly’s assistant Fly handles the ranking side. Ask it in plain language for senior React profiles with Azure exposure and it searches your talent pool, scores candidates against the job, and builds a shortlist you can compare side by side, with every change staged as a proposal you confirm before it happens. We are in private beta; if you spend your evenings hand-tuning strings against a database you already own, talk to us and bring your hardest search.