Boolean operators for Recruiting

A Boolean operator is a word or symbol that tells a search engine how to combine your keywords using formal logic. There are eight worth knowing: AND requires every term, OR requires at least one, NOT excludes, quotation marks lock an exact phrase, parentheses control evaluation order, wildcards capture word families, field operators restrict a term to a specific field, and proximity operators require terms to appear near each other. Most guides cover five, and recruiters spend 90% of their time using just one.

With the rise of AI agents, Boolean building will get less and less common, but I believe wit will always have a place in every recruiter’s toolbox. It just depends on what you want to do. For example, lets say you are looking for every Software Developer that is in your database and lives in Maryland. You want an exact list, not AI’s opinion of what might be on that list. Boolean still has a place.

Below: every operator with working examples, a platform-by-platform support table, ten copy-paste strings by role, and a troubleshooting table for when a string that worked yesterday stops working today.

Jump to:
What is a Boolean operator? · The eight operators · Platform support · Records vs documents · Beyond the resume · How to build a string · 10 copy-paste strings · Troubleshooting · FAQ

What is a Boolean operator?

Boolean logic comes from George Boole, a self-taught English mathematician who spent the 1840s and 50s trying to prove that human reasoning could be written as algebra. That “this AND that,” “this OR that,” and “NOT this” weren’t just rhetoric but operations, with rules, that you could solve like equations.

He was right, and here’s the part that matters for your day:

A Boolean string isn’t a description of what you want. It’s a specification. It defines a testable condition, and every record either satisfies it or it doesn’t. True or false. In or out. No maybe.

That property is the source of everything good about Boolean and everything painful about it. It’s also what separates it from AI semantic search, which returns nearer and farther instead of in and out. For now, hold onto this: you’re writing a specification, not a wish.

The eight operators, in the order you’ll actually need them

One rule first, and it’s a platform question rather than a law of Boolean. Many search engines want AND, OR, and NOT in uppercase. Google and LinkedIn both do. Lowercase “and” gets treated as an ordinary keyword or thrown away as a stop word, which is a common reason a beginner’s string does nothing like what they expected.

Plenty of systems don’t care. Some parse operators case-insensitively and also take symbol shorthand, where + means AND, | means OR, and - means NOT. Crelate is one of those, and its basic Boolean reference documents both forms. Check your platform before you assume. The failure is silent either way.

1. AND narrows

Requires every term. Each AND you add shrinks the result set.

"registered nurse" AND ICU AND telemetry

Only records with all three come back. Where symbol shorthand works, + does the same job. Google and LinkedIn treat a space as an implied AND, so nurse ICU behaves the same way there. Don’t assume that everywhere: plenty of ATS default to OR, which is a very different search. Write AND out anyway. Explicit strings are debuggable.

2. OR broadens

Requires at least one term. Each OR grows the set. This is where the real craft lives, because nobody describes the same job the same way twice.

("registered nurse" OR RN OR "R.N." OR "staff nurse" OR "nurse, ICU")

OR does two jobs: capturing every synonym and title variant for one concept, and building a list of acceptable values (target companies, certifications, schools, tech stacks). The pipe character | is the common shorthand.

3. NOT excludes

Removes records containing the term. Some platforms use AND NOT, some use a leading minus sign, some take both.

"controls engineer" NOT (intern OR "co-op" OR student)

Where the minus sign is the exclusion operator, whitespace changes the meaning, and this one catches everybody. dog -cat excludes cat. dog - cat reads as two separate terms and behaves like an OR. The minus has to be attached to the word it’s removing.

NOT is the sharpest tool in the box and the easiest one to cut yourself with. More on that below.

4. Quotation marks bind phrases

Forces an exact phrase in exact order.

"director of clinical operations"

Drop the quotes and most engines treat that as four ANDed words, then hand you a clinical nurse who directs nothing.

Use straight quotes, not curly ones. Smart quotes pasted out of Word or Google Docs silently break searches on most platforms, LinkedIn included. This is the number one reason a string that worked yesterday stops working today.

5. Parentheses control precedence

Parentheses group terms and force evaluation order, exactly like arithmetic. This matters more than people realize, because AND usually binds tighter than OR. So these aren’t the same query:

nurse AND ICU OR ER
nurse AND (ICU OR ER)

The first can resolve as (nurse AND ICU) OR ER, handing you every ER record in your database whether they’re a nurse or not. The second returns nurses in either unit. One misplaced parenthesis is the difference between a shortlist and a data dump.

Rule of thumb: wrap every OR group in parentheses, every time. Two keystrokes, one whole category of bug gone.

6. Wildcards and truncation

A wildcard stands in for one or more characters, so one term captures a family of words. In most systems it’s prefix matching: the asterisk goes at the end and matches everything starting with what came before it.

manag*      -> manager, managing, management, managed
engineer*   -> engineer, engineers, engineering

Two things to know before you build a string around this.

Character truncation like manag* is a behavior of Lucene-based systems, which power most modern ATS and resume databases. It doesn’t work that way on Google, where * is a word-level placeholder for a missing word, not a partial word. And it doesn’t work at all in LinkedIn Recruiter, which has no wildcard support.

If you work in a Lucene backed system (Elasticsearch is built on Lucene), one more wrinkle: wildcard terms usually bypass the analyzer, so they skip stemming and lowercasing. That means manag* and manage can return genuinely different sets, and a leading wildcard like *manager is often disallowed outright because it’s expensive to run.

7. Field and scope operators

These restrict a term to a specific field instead of the whole record. This is where Boolean stops being keyword matching and becomes real querying.

title:("vice president" OR VP) AND company:(Medtronic OR Stryker)

And the search engine flavor, for X-ray sourcing on the open web:

site:linkedin.com/in "supply chain" AND ("Boise" OR "Meridian") -jobs
site:github.com "rust" AND "embedded"
filetype:pdf "resume" AND "CDL-A" AND Idaho

site: constrains a domain, filetype: constrains a document type, intitle: and inurl: constrain where the match happens. X-ray search, using Google to search a site better than the site searches itself, is still one of the highest-leverage skills in sourcing. It’s pure Boolean.

One caveat inside an ATS. Typing field operators by hand means knowing the internal field name, the value format, and the exact syntax your platform wants, none of which the search box will ever show you. Custom fields are worse, since the name in the UI and the name in the query often aren’t the same string. That’s why most platforms put fields behind a filter builder instead: pick the field, an operator, a value, and the system assembles the predicate. Same logic, no memory test. Crelate does this in Advanced Search.

8. Proximity operators: NEAR, ~, W/n, AROUND (the least portable one)

Last because it’s the operator you’re least likely to be able to use. Proximity requires two terms to appear within a set distance of each other, which is a much better proxy for “related” than co-occurrence anywhere in a document.

project NEAR/5 manager
"six sigma" ~10 "black belt"

Syntax varies wildly (NEAR/n, ~n, W/n, ADJ), LinkedIn doesn’t support it, and most ATS don’t either. Google has an undocumented AROUND(n) that works but isn’t guaranteed to keep working:

"vice president" AROUND(4) operations

Where it exists, proximity earns its keep against long resumes, since a six-page document contains everything and plain AND stops meaning much. Where it doesn’t, scoping is the substitute: restrict to a field or document type so co-occurrence means something. That’s usually available when proximity isn’t, and it’s the more portable habit.

Platform reality check: operators don’t travel

Here’s what most Boolean guides skip, and it causes more real frustration than anything in the syntax. The same string doesn’t behave the same way in two different systems. Operator support is a per-platform question, every time.

	AND / OR / NOT	Quotes	Parentheses	Wildcard	Proximity	Field scoping
Google (X-ray)	Yes (- for NOT)	Yes	Yes	Word-level * only	Undocumented AROUND(n)	Yes
LinkedIn Recruiter	Yes, uppercase only	Straight quotes only	Yes	No	No	Partial, by filter
Job boards	Usually	Usually	Varies	Varies	Rarely	Rarely
A modern ATS/CRM	Yes, case rules vary	Yes	Yes	Usually, as prefix match	Rarely	Usually via filter builder
Crelate	Yes, case insensitive	Yes	Yes	Yes	No	Yes, via search builder UX

LinkedIn deserves its own list, since that’s where most sourcing time goes:

• No wildcards. Spell out every variant with OR.
• Operators must be uppercase. Curly quotes fail silently.
• Stop words get thrown away. Common words (and, or, the, of, at, by, to, for, with, in, from, not, but, after) are stripped from keyword fields. Searching “after sales” can return records containing only “sales.”
• Not every filter takes Boolean. It works in keyword, title, and company fields. Others need the exclude control in the UI.
• There’s a complexity ceiling. Stack enough facets and the query misbehaves rather than erroring.

That last point generalizes into a principle worth noting: prefer a precise inclusion list over a sprawling exclusion list. Long NOT chains are where good strings go to die. Every exclusion is a bet that the term never appears innocently. NOT manager throws away the senior engineer who wrote “reported to the engineering manager.” NOT junior loses the principal architect who once worked at Junior Achievement. Exclusion is high variance. Use it surgically.

What you’re actually searching: records, documents, and why it matters

Here’s a question most guides never raise, and it changes what your operators mean.

Search a job board and one result is one document. Search your own database and one result is a person, and a person isn’t one document. They’re a contact record, plus however many resumes they’ve sent you over the years, plus interview notes, emails and call logs, tags, custom fields, and every job they’ve been considered for.

So when you write Kubernetes AND "willing to relocate", you’ve asked an ambiguous question. Do you want both phrases in the same resume? Or do you want the person, where Kubernetes came off their 2023 resume and “willing to relocate” came out of an interview note somebody typed last spring?

Both are reasonable. They’re different searches. Most systems quietly pick one for you.

This is why scope control matters more than operator trivia. Being able to say “resumes only” or “search my notes too” is often the difference between a usable result set and noise. Crelate defaults to documents and lets you expand or restrict to activities and notes, and it shows which document each keyword was found in, which is the fastest way to catch a match that came from the wrong place. That’s covered in Using Search.

Two other scope traps, both common across platforms:

• Lookup and full-text are different searches. Typing a name into a quick-find box to jump to a record isn’t the same as running that name as a keyword query. Do the second and you get every resume containing the word.
• You don’t always need Boolean. If your requirement is entirely structured (a location, a tag, a date range, a certification field), a filter-only search with an empty keyword box beats any string. Reaching for Boolean when a filter would do is the most common self-inflicted wound in sourcing.

Why this is hard to build: denormalization, in plain terms

Worth understanding even if you never touch a database, because it explains behavior you’ll run into.

Databases store people the tidy way: contact details in one table, resumes in another, notes in a third, job history in a fourth. That’s normalization, and it’s correct for storing and editing data. Nothing is duplicated, so nothing can disagree with itself. It goes further than you’d think, too. A candidate’s email addresses, phone numbers, and physical addresses each live in their own table, so a person can have many of each. This normalization is, well, normal.

This optimal database design is suboptimal for searching. A query like “Kubernetes on a resume, relocation in a note, considered for a sales job in 2024” has to stitch four large tables together on the fly, for every person, every time. On a database with millions of records that’s slow enough to be unusable.

So search engines do the opposite. They build a second, flattened copy of each person that pre-assembles everything into one searchable bundle. Think of a file spread across four filing cabinets, photocopied into a single folder per person and kept updated. That’s denormalization, and it’s what makes fast cross-record search possible at all.

Two consequences you’ll notice:

1. The index is a copy, so it can lag. Edit a record and search results may take a moment to agree with you. Not a bug, just the copy catching up.
2. Matching happens at the person level. Because everything got flattened into one bundle, two terms can match from two different documents and the person still comes back. Usually what you wanted. Occasionally not, which is exactly when you narrow the scope.

Searching what isn’t on the resume

Boolean’s real ceiling isn’t syntax. It’s that a keyword search only finds what somebody wrote down. If the resume doesn’t say “willing to relocate,” no string finds it.

The usual answer is AI, and semantic search does help. But there’s a cheaper one that gets overlooked: capture the fact as structured data when you learn it and it’s searchable with total precision forever. Screening answers like relocation and notice period. Recency fields like last activity and last reach out. Who’s missing a phone number. Who’s been considered for a similar job before and how far they got. Radius from a location, which beats guessing at suburb names with OR. In Crelate, any question in an Activity Form becomes a filter in Advanced Search.

“Boolean only finds what’s on the resume” is only true if the resume is the only thing you ever recorded.

And if you build a search you’ll need again, save it. A saved, shareable search is the difference between a skill living in one person’s head and a process your team can run.

How to actually build a string

Don’t write a Boolean string. Write three lists, then assemble them.

1. Constraints. The non-negotiables. True or false, where a wrong answer costs you a submittal or a compliance problem. Licenses, certifications, clearances, geography, work authorization.
2. Concepts. The fuzzy stuff. What the person actually does. Enumerate every synonym and title variant you can think of, joined by OR.
3. Exclusions. Narrow, deliberate cuts. Keep this list short and be ready to defend every entry.

Then layer them, testing at each step so you know which clause broke what.

Layer 1, the concept
("registered nurse" OR RN OR "staff nurse")

Layer 2, the specialization
AND (ICU OR "intensive care" OR "critical care" OR CCU OR SICU OR MICU)

Layer 3, the hard constraints
AND ("compact license" OR NLC OR "multistate license")
AND (BLS AND ACLS)

Layer 4, one careful exclusion
NOT ("nurse practitioner" OR "nurse educator")

Check your count after every layer. If it falls off a cliff, you just learned something, either about your string or about your data.

And here’s the meta-skill every good sourcer already knows: the hard part was never the syntax. It’s knowing what to ask the hiring manager. Once you understand what makes someone qualified, the string writes itself. Boolean records a well-specified requirement. It can’t rescue a badly specified one.

Ten copy-paste strings by role

Adapt the geography and target companies. The note under each tells you what it’s guarding against, which is the part you need before you reuse it.

1. Backend software engineer, Go

(Go OR Golang) AND (microservices OR gRPC OR Kubernetes)
AND ("software engineer" OR "backend engineer" OR "platform engineer" OR SRE)
NOT (recruiter OR "talent acquisition")

Guards against: recruiters whose profiles are stuffed with every tech keyword they’ve ever hired for. The most common false positive in tech sourcing.

2. Enterprise SaaS account executive

("account executive" OR "enterprise AE" OR "strategic account" OR "major accounts")
AND (SaaS OR "software sales" OR ARR OR "net new")
AND (quota OR "President's Club" OR "Presidents Club" OR "quota attainment")

Guards against: inside sales and SDR profiles. Quota and Club language is the cheapest proxy for a closing role there is.

3. Controller or accounting manager

(Controller OR "accounting manager" OR "assistant controller")
AND (CPA OR "Certified Public Accountant")
AND ("month-end close" OR "monthly close" OR GAAP OR "financial reporting")
NOT (audit OR "public accounting" OR intern)

Guards against: career audit professionals when the client wants industry close experience. Drop the NOT if they’d take a Big Four candidate making the move.

4. CDL-A driver

("CDL-A" OR "CDL A" OR "Class A CDL")
AND (OTR OR regional OR "dry van" OR reefer OR flatbed)
AND ("clean MVR" OR "clean driving record" OR hazmat OR tanker)

Guards against: CDL-B holders. Spell out every punctuation variant, because the hyphen matters and nobody writes it the same way.

5. Industrial maintenance technician

("maintenance technician" OR "maintenance mechanic" OR "multi-craft" OR millwright)
AND (PLC OR hydraulics OR pneumatics OR "preventive maintenance" OR troubleshoot*)
AND (Allen-Bradley OR "Allen Bradley" OR Siemens OR Fanuc)

Guards against: facilities and building maintenance. Naming the controls brands separates plant floor from janitorial.

6. VP-level executive search

title:("vice president" OR VP OR "SVP" OR "senior vice president" OR "head of")
AND (operations OR "supply chain" OR manufacturing)
AND ("P&L" OR "P and L" OR EBITDA OR "full P&L responsibility")
AND company:(Medtronic OR Stryker OR "Boston Scientific" OR Baxter)

Guards against: title inflation. P&L is the constraint that matters, and candidates phrase it a dozen ways.

7. Cleared candidate, government services

("TS/SCI" OR "Top Secret" OR "TS SCI" OR "active clearance" OR "SCI with poly")
AND (polygraph OR CI OR "full scope" OR FSP)
AND ("systems engineer" OR "cyber" OR "SIGINT" OR "all source")

Guards against: expired and interim clearances. Always verify status directly. Never treat a keyword match as verification.

8. Radiologic technologist

("radiologic technologist" OR "rad tech" OR "x-ray tech" OR "radiology technologist")
AND (ARRT OR "R.T.(R)" OR "registered technologist")
AND (CT OR MRI OR mammography OR fluoroscopy)
AND ("state license" OR licensed)

Guards against: unlicensed and student profiles in a role where the license is the job.

9. Google X-ray into LinkedIn

site:linkedin.com/in ("plant manager" OR "operations manager")
AND ("Salt Lake" OR "Ogden" OR "Provo" OR Utah)
AND (lean OR "continuous improvement" OR "Six Sigma")
-jobs -jobs.linkedin.com -"we are hiring"

Guards against: job postings and company pages. Those three exclusions do most of the work in any X-ray string.

10. GitHub X-ray for embedded developers

site:github.com ("embedded" OR "firmware" OR RTOS OR bare-metal)
AND (C OR C++ OR Rust)
AND (Idaho OR Boise OR "Salt Lake City" OR remote)

Guards against: nothing, really. This one’s about reach. GitHub bios are sparse, so keep constraints short and expect to click through.

(Cheat sheet CTA slot: one-page PDF of all eight operators plus these ten strings. Ungated.)

Troubleshooting: why your string isn’t working

Symptom	Most likely cause	Fix
Zero results	Too many ANDed constraints, or a cert written differently than you guessed	Remove clauses bottom-up until results appear. The last one you removed is the problem.
Thousands of irrelevant results	Missing parentheses around an OR group	Wrap every OR group in parentheses
Worked yesterday, broken today	Curly quotes, usually from pasting out of Word, Docs, Slack, or email	Retype every quote by hand. Never compose strings in a word processor.
Operators treated as keywords	Lowercase and, or, not on a platform that requires caps	Uppercase all three
Exact phrase returning nonsense	The platform stripped a stop word out of your phrase	Reorder around a distinctive word, or use proximity
Obvious people missing	A title or acronym variant you didn’t enumerate	Check abbreviations, punctuation variants, internal titles, British vs American spellings
Good candidates vanished after a NOT	The excluded term appears innocently in their history	Scope it to a field (NOT title:manager) or drop it
Wildcard doing nothing	LinkedIn has none, and Google’s * is word-level	Spell out variants with OR
Searched a name, got hundreds of resumes	You ran full-text instead of a record lookup	Use quick-find, don’t submit the name as a query
Exclusion ignored entirely	On minus-sign platforms, a space breaks it	Attach it directly: -cat, never - cat
Two terms matched from unrelated documents	Person-level matching across a flattened index	Narrow the scope, or add a phrase constraint
A record you just edited isn’t matching	Index hasn’t caught up with the write	Wait a moment and re-run before blaming the string
Result count changes between identical runs	The index is updating underneath you	Note the date on any search you’ll need to defend later

Where Boolean stops being enough

Everything above is a specification language. It’s precise, reproducible, and it will silently miss anybody you didn’t think to ask for.

The short version of the tradeoff: Boolean answers who qualifies, based on exact criteria you determine. AI answers who might fit, based on what can be inferred. Boolean fails by missing people quietly. AI can fail by including people confidently. One is hard to write and easy to defend. The other is easy to write and hard to defend.

The right architecture uses both, in order: filter deterministically on hard constraints first, then retrieve lexically and semantically across what’s left. Determinism isn’t the fallback there. It’s step one.

I speak more about AI Search in Boolean is dead?

Frequently asked questions

What are the five Boolean operators? The classic five are AND, OR, NOT, quotation marks, and parentheses. They cover most of what you do. But three more do real work: proximity, wildcards, and field operators. Learn only five and you’ll keep hitting problems the other three solve in one line.

Do Boolean operators have to be uppercase? Depends on the platform, which is why it trips people up. Google and LinkedIn require uppercase and treat lowercase “and” as an ordinary keyword. Many ATS don’t care, and some also accept + for AND, | for OR, and - for NOT. Crelate is case insensitive and supports both forms. Uppercasing is the safe habit because it never hurts, but don’t assume lowercase is broken everywhere.

Does LinkedIn Recruiter support wildcards? No. Spell out every variant with OR. LinkedIn also strips stop words from keyword fields and requires straight quotation marks.

Does Google support NEAR? Not by that name. Google has an undocumented AROUND(n) that works as a proximity search, written as "vice president" AROUND(4) operations. Because it’s undocumented, don’t build a critical workflow on it.

In what order do AND and OR evaluate? On most engines AND binds tighter than OR, so nurse AND ICU OR ER can resolve as (nurse AND ICU) OR ER. Wrap every OR group in parentheses and you never have to think about it.

Why do two search terms match a candidate when the terms are in different documents? Your ATS is matching at the person level, not the document level. Search engines flatten everything about a contact, resumes, notes, custom fields, activity history, into one searchable bundle so queries run fast across millions of records. Useful most of the time. When you need both terms in the same document, narrow the scope.

Can Boolean find things that aren’t on the resume? Only if somebody recorded them somewhere the search can reach. That’s why capturing screening answers, dates, and pipeline history as structured data matters: once a fact lives in a field, it’s searchable with total precision. “Boolean only finds what’s on the resume” is a statement about your data capture, not about Boolean.

Do I have to type field operators by hand? Usually not, and usually you shouldn’t. Typed field syntax means knowing internal field names and value formats the search box never shows you. Most platforms expose fields through a filter builder instead, which produces the same deterministic logic without the guesswork.

What’s the difference between Boolean and semantic search? Boolean returns a set: each record either satisfies your condition or it doesn’t. Semantic search returns a ranked list by meaning similarity, so it finds synonyms you never enumerated but can’t tell you whether anyone actually qualifies. Boolean is precise and reproducible. Semantic is fast and forgiving.

Is Boolean search dead? The search box as the front door to your database is finished, and good riddance. The logic isn’t. As recruiting moves to agents that source and screen with less human review per action, deterministic conditions are what you write guardrails and audit trails in. AI has gotten very good at writing Boolean, which is a different thing from replacing it.

Should I still learn Boolean if my ATS has AI search? Yes, mostly for reading rather than writing. If your platform builds a query from a plain-language prompt, being able to read that query is how you catch it doing the wrong thing. If your platform won’t show you the query it ran, that’s worth asking about.