# The People-Search Query Cookbook: Patterns That Find Real Candidates

*You will be able to write a search that returns the right people the first time, whatever tool is in front of you.*

- Canonical URL: https://www.refolk.ai/guides/people-search-query-cookbook-2
- Pillar: Recruiting and sourcing
- Format: Reference
- Published: 2026-08-30
- Last reviewed: 2026-08-30
- Reading time: 15 min
- Keywords: people search query, boolean search recruiters, natural language search candidates, sourcing search strings

## Key takeaways

- A single role carries 4 to 8 legitimate titles depending on company size, industry, and region, so the OR-cluster for titles is where most searches quietly lose their pool.
- LinkedIn Recruiter does not rank results by how well they match your Boolean string, so the best-fit profile can sit on page 30 while precision buys you nothing without a re-rank.
- Only 18% of GitHub activity is public and location: only matches a filled-in profile field, so a thin GitHub result set usually reflects missing metadata rather than missing talent.
- Refolk's index holds 1,264 sourcer profiles in the US against 69 in the UK, roughly 18.3x more, which is a structural reason UK teams lean on RPO firms like Pontoon and Adecco.
- Boolean matches strings while natural-language search infers intent: a Boolean query for 'people management' returns nothing for a CV that says 'managed 12 direct reports'.
- Free LinkedIn accounts face a ~300 monthly commercial-search cap and 1,000 results per search, which turns query segmentation into a quota-preservation tactic, not just a precision one.

Writing a people-search query is the daily mechanical act of sourcing, and it is where most pipelines silently lose the candidates they were meant to find. This is a lookup document for in-house recruiters, sourcers, talent leaders, and founders doing their own hiring: the operators each platform actually supports, the four-part structure that scales, the ways queries fail without an error, and the patterns that return the right people the first time. Jump to the row you need and leave.

The mechanical part of writing strings is now cheap. The durable skill is the same one that always separated good Boolean users from bad ones: turning a hiring manager's vague wish into concrete, checkable attributes. That translation is still the job, and it is now the whole job.

## What Boolean operators every platform actually supports

Five operators are the whole vocabulary: AND, OR, NOT, quotation marks for an exact phrase, and parentheses for grouping. Everything else is platform-specific, and most broken searches trace back to assuming an operator works when it does not.

LinkedIn Recruiter and Recruiter Lite support all five in the keyword field. Per LinkedIn's official help documentation, wildcards (the asterisk) and the plus and minus operators are not supported, and there is no NEAR or proximity operator. Use AND in place of plus and NOT in place of minus. This is not only a compatibility fix: it makes a query easier to read.

Two LinkedIn rules cause more zero-result searches than any syntax error. First, operators must be uppercase. LinkedIn only reads AND, OR, and NOT as Boolean operators when typed in uppercase; in the Keywords filter, lowercase and, or, not are ignored as stop words. Second, Boolean works in the Job titles, Companies, and Keywords filters, but the Project filter does not support Boolean search at all.

> **Rule:** Uppercase operators, straight quotes, always
>
> LinkedIn reads AND, OR, and NOT as operators only when uppercase; lowercase versions are dropped as stop words. Always use straight quotes ("), never curly quotes copied from a document, or the phrase match silently fails.

### The operator differences that bite when you port a string

A string that works on LinkedIn Recruiter will silently fail on Google X-ray if you forget to swap NOT for the minus sign. X-ray uses the site: operator to restrict results to one domain, for example site:linkedin.com "recruiting marketing", and it accepts the minus sign for exclusion where LinkedIn wants the word NOT. GitHub uses field operators entirely of its own, covered below. Treat every platform as a separate dialect and re-validate operators each time you move a query.

There is one documented conflict worth knowing. LinkedIn documents a limit on the number of Boolean operators rather than characters: Sales Navigator allows roughly 15 operators per query, while Recruiter and Recruiter Lite have no operator limit. A separate source reports Recruiter strings up to roughly 2,000 characters. The sources disagree, so if you are writing long strings on Sales Navigator, count your operators and keep the total near 15 to be safe.

## The four-part query structure

Every reliable string follows the same order: title variations, then skills, then context, then exclusions. Build each concept as an OR-cluster in parentheses, then join the clusters with AND.

The reason the order matters is diagnostic. When a search returns too few results, you widen the title cluster first, because that is almost always where the pool was lost. When it returns too many, you tighten the skills or add an exclusion. Keeping the parts in a fixed order lets you reason about which knob to turn without rereading the whole string.

#### The four-part query structure

1. **Title variations** - Every legitimate title for the role, joined by OR
2. **Skills** - The must-have capabilities, each an OR-cluster
3. **Context** - Company stage, industry, or scale signals
4. **Exclusions** - NOT terms that remove predictable false positives

*Read outermost first: each layer narrows the pool from the one above it.*

**The four-part LinkedIn Boolean skeleton**

```
("title variation A" OR "title variation B" OR "title variation C")
AND ("skill one" OR "equivalent phrasing")
AND ("context signal" OR "context signal")
NOT ("term that produces false positives")
```

*Replace the bracketed clusters with your own OR-terms; keep operators uppercase and quotes straight.*

### Why the title cluster does most of the work

A single role can have 4 to 8 legitimate titles depending on company size, industry, and region. A "sourcer" is also a "Technical Sourcer", a "Talent Sourcer", sometimes a "Recruiting Researcher", and at a small company a "Recruiter" who happens to source. Miss one of those and you do not reorder your results, you delete a slice of the pool. This is Boolean's core weakness: exact-match precision is also a blind spot, and a single missed synonym silently shrinks the pool rather than just changing the ranking.

Enumerating those synonyms is exactly the brief-translation skill that matters most. List every title your target candidate might use before you write a single operator.

## Boolean versus natural language: when each one wins

Boolean matches strings; natural-language search infers intent. Boolean wins when you know exactly which words appear on the right profile and on any platform without an AI layer. Natural language wins when the requirement is not a keyword.

The clearest illustration: a Boolean search for "people management" will miss candidates whose CVs say "led a cross-functional team of 8" or "managed 12 direct reports". Because the exact phrase does not appear, Boolean returns nothing. No error, no warning, just an empty or thin result set that looks like a shortage of talent.

There is a trap on the other side. Plenty of tools advertise natural-language search while running keyword matching underneath, and an over-eager system that expands too widely floods you with wrong-seniority profiles. The tell shows up immediately when your brief contains a non-keyword requirement. Test any "natural language" tool on a brief where you already know the right answer, and watch whether it finds the equivalently-phrased profile or only the literal one.

> Boolean precision is also its blind spot: one missed synonym deletes a slice of the pool, not just its order.

This is the friction that a genuine natural-language layer removes. Instead of enumerating eight title synonyms and every equivalent phrasing for a skill, you describe the person and let the tool infer the variants. [Refolk](/) is built for exactly this: you ask in plain English and it searches across GitHub, LinkedIn, and the open web, so the brief-translation you did in step one becomes the query itself rather than a manual synonym-expansion exercise.

I ran this search: `Technical sourcers who have worked at a high-growth US startup like Rippling or Verkada in the last three years` - [see the full result list](https://www.refolk.ai/s/61qzm7938w).

*Returns sourcer profiles matched on employer, seniority, and recency without you writing a single OR-cluster or NOT term.*

## The platform field operators worth memorising

Each platform exposes structured fields that outperform anything you could cram into a keyword string. Move location, followers, language, and repository counts into these operators rather than the Boolean body.

| Operator | Platform | What it matches | The catch |
|---|---|---|---|
| location:austin | GitHub | Users who typed a location | Only works if the user filled the field |
| language:python | GitHub | Primary repo language, chainable | Misses polyglots who tag differently |
| followers:50..500 | GitHub | Follower count range | A proxy for visibility, not skill |
| repos:>20 | GitHub | Public repo count | Counts forks and toy repos too |
| site:linkedin.com | Google X-ray | Results only on that domain | Uses the minus sign, not NOT |

The GitHub numbers set expectations. There were 180 million developers on GitHub as of the 2025 Octoverse report, but only 18% of all GitHub activity is public, and there is no built-in messaging. So a small GitHub result set is usually a coverage artifact, not a talent shortage. When location: returns almost nobody, it is telling you how many people filled in a profile field, not how many qualified developers exist. Cross-search README files, commit history, and adjacent signals before you conclude the pool is thin.

> **Watch out:** A thin GitHub result is usually missing metadata
>
> With only 18% of activity public and location: dependent on a filled field, a small result set reflects absent profile data, not absent talent. Do not read "few results" as "few qualified developers."

## The platform limits that force query design

LinkedIn's free tier caps searches, so segmenting one broad search into filtered chunks is a quota-preservation tactic, not just a precision one. Sales Navigator and Google X-ray each change the math.

| Platform / tier | Monthly search cap | Results per search |
|---|---|---|
| LinkedIn free | ~300 | 1,000 |
| Sales Navigator | no monthly cap | 2,500 |
| Google X-ray (site:linkedin.com) | no LinkedIn internal cap | Google-paginated |

Free LinkedIn accounts face a roughly 300 monthly commercial-search limit and 1,000 results per individual search. The commercial-use limit resets at midnight PST on the first of each calendar month, so a run of exploratory searches late in the month can leave you locked out. Sales Navigator removes the monthly cap and raises the per-search result ceiling to 2,500 profiles. Google X-ray searches run through Google, not LinkedIn's internal search, so they do not count against the internal limit at all, which is why X-ray is the standard escape valve for a constrained free account.

**1,000 - Results per search on a free LinkedIn account**

Combined with the ~300 monthly cap, this is why a broad search should be split into filtered segments rather than run once and paged through.

One ranking gap changes how you read any result set. LinkedIn Recruiter does not rank results by how well they match your Boolean string, so the most relevant profile might be on page 30. Precision without re-ranking wastes the precision: an ultra-specific string still buries the best fit deep in the pages. Export and re-sort by fit rather than assuming page one is the strongest match.

## The step-by-step: writing a query that lands the first time

The procedure is seven steps, and the first two carry most of the value. The mechanical operator work has been automated for years; the translation from brief to checkable attributes is where good searches are won.

#### From brief to saved query

1. **Translate the brief into checkable attributes** - Sit with the hiring manager and turn the vague wish into a written must-have versus nice-to-have list, each line something you can verify on a profile. Budget 15 to 30 minutes.
2. **Enumerate title and skill synonyms** - List every title and skill term the target might use, since one role carries 4 to 8 legitimate titles. Put each concept in its own OR-cluster. Budget about 10 minutes.
3. **Assemble the string in four parts** - Build one nested string in the order title, skills, context, exclusions, with parentheses around each OR-cluster. Done is a single parenthesised string you can read top to bottom.
4. **Pick the platform and adapt the syntax** - Rewrite operators to the platform's rules: uppercase AND OR NOT and straight quotes on LinkedIn, minus and site: on X-ray, field operators on GitHub. Done is a string valid for exactly one platform.
5. **Move location and fields out of the string** - Pull city names, seniority, and structured attributes into built-in filters, which handle them better than a keyword. Done is a leaner string plus filter selections.
6. **Run, test, and check for silent failure** - Confirm the result set is non-zero and on-target, then re-run after any platform change since search behaviour shifts without notice. Eyeball the results, do not just read the count.
7. **Iterate with NOT terms, then save the string** - Loosen or tighten exclusions based on the first few pages, then store the winning query in a doc or Notion. Done is a saved, labelled string you can reuse next quarter.

Experienced sourcers disagree on where to start. Some begin broad and narrow, reviewing the first few pages and adding skills or NOT terms only when irrelevant profiles appear. Others build the full four-part string first. Both work; the broad-first approach is safer on unfamiliar roles because it shows you the real distribution of titles before you commit to exclusions.

#### The refine loop after the first run

1. **Run broad** - Title cluster plus one skill, no exclusions
2. **Read first pages** - Note wrong-title and wrong-seniority noise
3. **Widen or tighten** - Add titles if thin, add NOT terms if noisy
4. **Move fields out** - Location and seniority into filters
5. **Save** - Store the working string with a label

*Every zero or noisy result routes back to a specific part of the string.*

## How people-search queries fail without an error

Most query failures are silent: the search runs, returns something, and looks fine while quietly missing the right people. These are the eight failure modes to check for, each with the signal that it is happening and the test that catches it.

| Failure mode | What it looks like | How to check |
|---|---|---|
| Lowercase operators | Operators read as literal keywords; thin or zero results | Uppercase every AND/OR/NOT; test for zero |
| Curly vs straight quotes | Query looks correct but phrase match fails | Retype quotes in the field, not pasted |
| Over-specific string | Qualified people excluded on terminology | Run an OR-only version and compare counts |
| Porting across platforms | LinkedIn string fails on X-ray | Re-validate operators per platform |
| No relevance ranking | Best profile buried on a late page | Export and re-sort results by fit |
| GitHub location gaps | Small set read as few devs | Cross-search README, commits, adjacent signals |

Two of these deserve extra weight. The over-specific string is the most common self-inflicted wound: overly specific Boolean strings exclude qualified candidates who may not have used the exact terminology. The fix is a discipline, not a one-off. Keep a broadened, OR-only version of every important query and compare the counts; a large gap means your precise string is throwing away people, not just noise.

NOT terms over-exclude in a way that is easy to miss. Excluding "junior" can drop a senior engineer who wrote "mentored junior developers" in their profile. The exclusion inference must be confirmed by hand, so manually verify a sample of who your NOT terms removed before you trust them.

The porting failure is the one that survives a working query. A string you validated on Recruiter last week will fail on X-ray this week if you forget to swap NOT for the minus sign, and it fails silently because Google will happily run the malformed query and return whatever it finds. Re-validate operators every time you change platform, even when the underlying logic is identical.

> **Tip:** Keep a broad twin of every important query
>
> For any high-stakes role, store the precise string next to an OR-only version. Comparing their result counts tells you instantly whether your precision is finding signal or deleting qualified people.

## What the sourcer market looks like, and why it matters for query volume

The talent that writes these queries is heavily concentrated in one market. In Refolk's index of professional profiles, the US sourcer pool is roughly 18.3 times the UK pool, which shapes who is available to run in-house sourcing and who leans on agencies instead.

| Market | Matching sourcer profiles | Share of the two-market total |
|---|---|---|
| United States | 1,264 | 94.8% |
| United Kingdom | 69 | 5.2% |

In Refolk's index, the two markets also cluster around different employer types. US sourcers concentrate at high-growth tech companies including Rippling, Anthropic, MongoDB, Verkada, and Zoox, with the sample dispersed enough that no single employer dominates. UK sourcers concentrate at staffing and RPO firms such as Pontoon Solutions and Adecco, alongside tech employers like Google and Bloomberg.

**18.3x - US sourcer pool versus UK, in Refolk's index**

1,264 US profiles against 69 UK profiles is a structural reason UK teams rely on RPO firms like Pontoon and Adecco rather than in-house sourcing.

The practical read: if you are hiring or benchmarking sourcers in the UK, the in-house pool is genuinely small, and the query patterns above will surface the same faces quickly. Widen the title cluster aggressively and consider that many strong UK sourcers sit inside RPO firms rather than in-house teams, so your context cluster should not exclude agency backgrounds by default.

## Keeping your query library current

Search platforms change behaviour without announcing it, so the maintenance job is continuous testing, not a one-time setup. LinkedIn occasionally updates how searches work, which is why you always test your queries rather than trusting a string that worked last quarter.

Save your best strings in a doc or Notion so high-performing queries survive past the search that produced them, and label each with the role, platform, and the date you last confirmed it ran. When you reuse one, re-run it against a known-good profile before you trust the full result set. The mechanical operators rarely change, but ranking, caps, and field behaviour do.

#### Before you trust a people-search query

- [ ] Every AND, OR, and NOT is uppercase and every quote is straight
- [ ] Each concept has an OR-cluster covering 4 to 8 title or skill synonyms
- [ ] Location and seniority are in structured filters, not the Boolean string
- [ ] Operators are validated for the specific platform, not ported blind
- [ ] A broad OR-only twin exists and its count is close to the precise string
- [ ] Results were eyeballed, and on unranked platforms re-sorted by fit
- [ ] The winning string is saved with role, platform, and last-tested date

The through-line across every platform and every failure mode is the same. The operator syntax is a solved problem you can look up in the tables above. The work that decides whether you find the right people is upstream of the string: converting a fuzzy brief into checkable attributes and enumerating the titles a real candidate would actually use. Get that right and almost any tool will find them; get it wrong and no operator will save you.

## Frequently asked questions

### Does LinkedIn support the plus and minus operators for Boolean search?

No. Per LinkedIn's official help documentation, LinkedIn does not support the plus or minus operators, and it does not support wildcards or proximity operators either. Use AND in place of plus and NOT in place of minus, which also makes the query easier to read. Boolean works in the Job titles, Companies, and Keywords filters, but the Project filter does not support Boolean at all.

### Why does my LinkedIn Boolean search return zero results when the query looks correct?

The two most common silent failures are lowercase operators and curly quotes. LinkedIn only reads AND, OR, and NOT as operators when typed in uppercase, and it treats lowercase and, or, not as stop words. Curly quotes pasted from a document break exact-phrase matching without any error message. Retype your operators in uppercase and your quotes straight, directly in the field.

### When should I use natural-language search instead of Boolean?

Use natural-language search when the requirement is not a specific string. A Boolean query for 'people management' returns nothing for a profile that says 'led a cross-functional team of 8', because the exact phrase never appears. Boolean still wins when you know the precise words on the right profile, and it is the only option on platforms without an AI layer. Beware tools that advertise natural language but run keyword matching underneath.

### Why do I get so few results on GitHub when searching by location?

GitHub's location: filter only matches users who filled in their location field, and only 18% of all GitHub activity is public. A small result set usually reflects missing metadata, not a shortage of qualified developers. Cross-search README files, commit history, and adjacent signals like language: and followers: ranges rather than treating the thin location result as the whole pool.

### Do Google X-ray searches count against my LinkedIn monthly search limit?

No. Google X-ray searches with site:linkedin.com run through Google, not LinkedIn's internal search, so they do not count against LinkedIn's commercial-use cap. Free LinkedIn accounts face roughly 300 monthly commercial searches and 1,000 results per search, and that limit resets at midnight PST on the first of each calendar month. X-ray is a way to stretch a constrained quota.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/people-search-query-cookbook-2*