The People-Search Query Cookbook: Patterns That Return Real Candidates

This is a lookup document for turning a fuzzy idea of who you want to hire into a search that returns those people on the first try, whatever tool is in front of you. It is for in-house recruiters, sourcers, talent leaders, and founders doing their own sourcing. Instead of a flat list of operators bolted to one platform, it is organized by the intent behind a search, so you jump to the pattern that matches what you actually want and leave knowing how that pattern would have missed people.

Most Boolean cheat sheets teach syntax: AND, OR, NOT, quotes, parentheses. That is the easy half. The hard half is knowing which pattern to reach for, how it translates across LinkedIn keyword fields, GitHub qualifiers, and Google X-ray, and precisely how each one lies to you. That is what this cookbook is for. Read a row, adapt it, and correct for its known failure before it wastes a page of results.

What a query pattern is, and why intent beats operators

A query pattern is a reusable shape of search tied to a hiring intent, not to a platform. You pick the pattern from what you are looking for, then translate its operators to the tool you are in.

There are six patterns worth naming, and almost every real search is one of them or a stack of two. Naming the pattern first is the whole discipline: it tells you which operators matter and, more usefully, which failure mode is about to bite you.

The reason to lead with intent rather than syntax is that the same operator behaves differently depending on what you are trying to prove. An OR block used for synonym expansion buys you reach; the same OR block used for pedigree, listing three companies, is doing something else entirely and fails in a different way. If you start from a syntax table you cannot see that. If you start from intent, the failure mode comes attached to the pattern.

The core translation table: one intent, three platforms

The same intent needs different syntax on LinkedIn, GitHub, and Google X-ray, and switching platforms is mostly mechanical once you know the swaps. Moving from LinkedIn Boolean to Google X-ray is largely swapping NOT for the minus sign and adding site: at the start.

Keep this table open. It is the spine of the cookbook: pick your intent in the left column, read across to the platform you are on.

Three things about this table decide whether your search works.

First, GitHub does not do synonym OR or exclusion inside user qualifiers. It filters by hard fields: location, language, followers, repos, created, in, and type. That makes GitHub precise but literal. There is no "or adjacent title" on GitHub; there is only what people declared in structured fields.

Second, on LinkedIn the + and - operators are not officially supported. They may appear to work, but the documented operators are AND, OR, NOT, quoted exact phrases, and parentheses. Use AND and NOT. LinkedIn's documented precedence runs quotes first (matched as exact phrases before any Boolean logic), then parentheses, then NOT, then AND, then OR last. If your grouping surprises you, this order is usually why.

Third, on Google the operators glue to their term: there must be no space between intitle: or inurl: and the following word. inurl: restricts results to documents with the word in the URL; intitle: restricts to the word in the page title. And several once-common operators are gone: Google retired link:, cache:, +, ~, and info:. Cheat sheets that still teach them are stale.

Pattern by pattern: what each returns and how it lies

Each pattern proves something specific and misleads in a specific way. Read the "how it lies" line before you run it; that is the line that saves the page.

Title-and-skill

This is the default: an exact title phrase AND a skill. On LinkedIn, "software engineer" AND Rust. On GitHub, you cannot phrase a title, so you approximate with language:rust and let the code stand in for the claim. On X-ray, "software engineer" Rust site:github.com.

What it proves: the person currently frames themselves with that title and that skill. What it lies about: people who use the skill daily but never named it, and people whose title differs by one word. In Refolk's index, Rust plus the literal title Software Engineer returns 603 people in the US. That count is an artefact of exact-title matching as much as it is a measure of the market.

Synonym expansion

Broaden the title and skill into an OR block of real-world variants, grouped in parentheses: ("developer" OR "programmer" OR "engineer") AND Python. Semantic search does this for you by applying related job titles and skills to each term, bridging how candidates describe themselves and how recruiters search. A worked expansion: "Java Developer" fans out to Java Architect, J2EE, Java Programmer, Java Engineer, J2EE Developer, and Java Software Engineer.

What it proves: broader true coverage of the same role. What it lies about: precision. Every synonym you add buys reach and costs precision, and an over-broad OR block pulls in adjacent roles, treating Customer Success as Sales or Go as Rust. The fix is to sample ten results after each new variant and check for role drift.

Pedigree

An OR block of company or project names: ("Oxide Computer Company" OR Meta) AND Rust. Top US employers for Rust engineers in Refolk's index include Google, Oxide Computer Company, and Meta, which makes those names useful anchors for a pedigree search. On GitHub the equivalent is targeting contributors to a known repository or organisation rather than a keyword.

What it proves: the person cleared a known bar. What it lies about: it silently excludes strong people who never worked at your named companies, and it rewards brand over craft. Use it to seed, not to gate.

Relocation

Constrain or open by geography. On GitHub, location:berlin; on X-ray, a quoted "Berlin" alongside your site: path. The interesting move is opening a search across two hubs when the local pool is thin: location:berlin OR location:munich. Munich and Berlin lead among German Rust locations in Refolk's index.

What it proves: where someone says they are. What it lies about: everything, because GitHub location is self-reported free text. location:berlin misses "Berlin, DE" and every empty field. Run location variants and cross-check with language: so you are not trusting one messy field.

Seniority inference

Target a level without stapling a literal seniority word to an exact title. Infer from years, scope, repos: count, or followers: rather than from the word "Senior." On GitHub, repos:10..30 or followers:>1000 are proxies for someone with a track record; repos:>9000 matches users with over 9,000 repositories.

What it proves: depth, indirectly. What it lies about: the literal word. This pattern exists precisely because the naive version fails, which is the next section.

Exclusion

Strip job ads, sample resumes, and recruiters with a NOT block: -jobs -hiring -recruiter, plus -intern -junior -assistant -freelance when you want senior people. A documented resume-hunting string reads (intitle:resume OR intitle:cv) ... -job -jobs -sample -examples, where the minus sign excludes sample resumes and job ads. Keep reusable exclusion blocks on hand.

What it proves: a cleaner first page. What it lies about: it takes real people with it. -recruiter drops an engineer who mentions "recruiting tools." Compare result counts with and without each NOT term before you trust it.

Every synonym you add buys reach and costs precision; every exclusion you add buys quiet and costs people.

The [OURS] numbers behind these patterns

The counts in Refolk's index show why the patterns matter more in some markets than others, and why over-constraining is so easy to do by accident.

Start with the same title-and-skill search run in two countries.

The US pool is 6.8 times the German pool for Rust software engineers. That ratio is the whole argument for synonym expansion in thin markets. At 89 people, each variant you forget to add is a large share of everyone you could find. At 603, a missed synonym stings less. Spend your OR-block effort where the population is small.

Now hold the market fixed and change the skill.

Golang returns about 1.94 times the US count of Rust. An unadjusted "just find me Rust people" brief looks scarcer than the organisation's actual willingness to hire adjacent Go talent. If the requisition is really "systems-minded backend engineer," the Go pool nearly doubles your reach. Whether to widen is a hiring-manager call, but you should surface the number, not hide it behind a literal skill filter.

The build procedure: intent to first-page-clean

Run these seven steps in order. The one judgement call is where exclusions go: some sources fold them into the first draft, but the iterative-refinement view, which I follow, is that you add exclusions only after you see which noise actually appears on page one.

Writing the query is the part every cheat sheet covers. Reading the first page and knowing which of the six failure modes just fired is the part they skip, and it is where the time goes.

The advantage of describing intent in plain English, as with Refolk, is that you skip the translation step entirely: you state who you want and get named people across the public GitHub graph, public LinkedIn records, and the open web, without hand-writing the OR blocks and site: paths for each platform. When the pool is 89 people, the cost of a forgotten synonym is a candidate you never see, so removing the translation step is not cosmetic.

How these patterns go wrong

Every pattern has a failure mode, and most of them look like success until you inspect page one. These are the ones that waste the most time, with the tell and the check for each.

Two of these deserve extra weight.

The over-constrained failure is the one that fools experienced sourcers, because zero results reads like a verdict on the market. It is usually a verdict on your query. In Refolk's index, Senior plus Rust plus the exact string "Software Engineer" returns 0, even though Rust plus that title returns 603 in the US. The seniority word and the exact-title string intersect too narrowly. Infer seniority from scope, years, or GitHub repos: and followers: counts instead of demanding the literal word.

The stale X-ray failure is structural and permanent. In January 2024 LinkedIn removed headline, About, work experience, education, and location data from Google's public index, as documented by sourcing trainer Jan Tegze. That broke the most popular site:linkedin.com/in use case: the result snippet no longer confirms title or skill, and the HTML title can show old positions. The search still finds profile pages, but you must open every one. This is why sourcing weight moved toward site:github.com and site:stackoverflow.com X-ray, where public profiles are still indexed, and toward GitHub qualifiers that filter server-side regardless of what any snippet shows.

One more syntax trap worth flagging: allintitle: and allinurl: do not stack well. allinurl: requires every following token and combines badly with other filters. Use repeated single-token inurl: calls alongside your other operators instead.

An operator translation cheat you can paste

Keep the swaps in one place so translating a working LinkedIn string to X-ray takes seconds, not a rewrite. This template turns the mechanical differences into a checklist.

LinkedIn:  ("software engineer" OR "backend engineer") AND Rust NOT recruiter
X-ray:     site:github.com ("software engineer" OR "backend engineer") Rust -recruiter -jobs -hiring

Swaps to make every time:
- NOT  becomes  -term   (minus sign, no space before the term)
- Add  site:github.com  or  site:stackoverflow.com  at the start
- Keep quotes for exact phrases; keep parentheses for OR groups
- Drop LinkedIn field filters; replace with quoted location terms

GitHub user-search version (structured, no synonym OR):
language:rust location:berlin followers:>1000 repos:10..30

Two reminders that live in the template above. Dates on GitHub must follow ISO 8601, YYYY-MM-DD, so created:>2020-01-01 is valid and created:>2020 is not. And stars: and pushed: are repository qualifiers, not user qualifiers; they will not filter a people search no matter how reasonable they look.

Before you call the search done

Run this checklist against any people-search before you hand the results to a hiring manager or start outreach. It catches the failures that pass silently.

Keeping the cookbook current

Query patterns are stable; the platforms under them are not, so re-check the mechanisms rather than memorising today's syntax. The load-bearing change to watch for is index and field availability: the January 2024 LinkedIn removal is the example, and the way to detect the next one is to run a known site: X-ray against a profile you can see and confirm the snippet still carries title and location. When it stops, that use case is broken, and you move weight to GitHub and Stack Overflow.

Free X-ray generators track these swaps for you and are worth a bookmark as a translation crutch; one long-running generator was still adding new networks as recently as early 2026. Use them to draft, then apply this cookbook's failure-mode checks by hand, because a generator cannot tell you that your seniority filter just zeroed out a real market or that a NOT term took ten real engineers with it. The syntax is cheap. Knowing how each pattern lies is the part worth keeping open.