The People-Search Query Reference: Patterns, Matches, and Misses

The job is narrow and specific: write a people-search query that returns the right candidates the first time, on whatever source is in front of you. This is a lookup reference for in-house recruiters, sourcers, and founders doing their own hiring, organized by the candidate attribute you are matching rather than by operator. For each attribute it states what the pattern proves, exactly where it fails quietly, and how the same intent is written across GitHub user search, LinkedIn X-ray, and open-web search. Jump to the row you need and leave.

Every generic cheat sheet teaches you AND, OR, NOT and hands you a few copy-paste strings. None of them tell you who a pattern silently misses. That silent miss is where good candidates disappear and where a thin result gets mistaken for a thin market. This reference is built around that gap.

What operators each source actually supports

Each source has a fixed operator set, and mixing them up is the first way a query fails. LinkedIn, Google X-ray, and GitHub user search do not share syntax, so a string that works on one breaks silently on another.

LinkedIn supports exactly five native operators: AND, OR, NOT, quotation marks for exact phrases, and parentheses for grouping. They must be typed in ALL CAPS - a lowercase "and" or "not" is treated as an ordinary search word and breaks the query without warning. LinkedIn does not support the asterisk wildcard, curly, square, or angle brackets, and the plus and minus signs are not officially supported either.

Google X-ray uses a different set. site: restricts to a single website such as site:linkedin.com/in, quotation marks match an exact phrase, intitle: finds a keyword in the page title, OR broadens and must be uppercase, and the minus sign excludes a keyword.

GitHub user search uses qualifiers, not boolean words. It accepts, in any combination: type (user or org), in:login, in:name, in:email, fullname:, repos:, location:, language:, created:, and followers:. Note two hard limits most cheat sheets omit: a GitHub query cannot exceed 256 characters or use more than five AND/OR/NOT operators.

The attribute-by-attribute query reference

This is the core of the document: for each candidate attribute, the pattern, what it proves, and how it lies. Read the row for the attribute you are matching, then translate across sources in the later section.

Title. The pattern is an OR-group of synonyms: ("Software Engineer" OR "Backend Developer" OR "Platform Engineer"). It proves the person self-describes with one of those labels. It lies when you use job-description language instead of candidate language - a search for "Software Engineer" misses someone titled "Backend Developer" unless you add the synonym. The fix is to list every title the target would self-apply before you write the string.

Skill. On LinkedIn and open web, skills are matched as quoted keywords. On GitHub, the language: qualifier matches the languages of repositories a user owns, not stated skills. This proves the person has shipped code in that language. It lies hardest on frameworks: language:react returns nothing meaningful because React is not a language and resolves to JavaScript or TypeScript. Query the language and filter by framework topic instead.

Seniority. There is no clean operator for seniority. Sourcers reach for created:<2022-01-01 on GitHub, which returns accounts opened before a date. It proves account age and nothing else - account age says little about seniority, and it surfaces dormant accounts that stopped committing years ago. On LinkedIn, seniority is approximated with title keywords like "Senior" or "Staff" inside the OR-group.

Location. On GitHub, location: reads a free-text field exactly as the user typed it, so location:"Berlin" does not match "Deutschland", "Remote", or an empty field. On open web you quote the place name. It proves the string appears in the profile's location field; it proves nothing about where the person actually is. This is the attribute where confident sourcers lose the most candidates.

Employer and activity. LinkedIn matches current and past employers as keywords. GitHub has no activity filter in user search - a profile with a city and the right language can belong to someone who stopped committing three years ago, and GitHub sorts them alongside people shipping every week.

Education. No documented GitHub or LinkedIn operator failure case is publicly established for education matching. Treat it as a keyword match on open web and LinkedIn, and do not assume the field is populated or standardized.

How the same intent is written across three sources

The same hiring intent translates into three different strings. Below is one intent - backend or software engineers in a city, writing a given language, with recruiter and jobs noise excluded - expressed three ways.

LinkedIn / X-ray base:
("Software Engineer" OR "Backend Developer" OR "Platform Engineer") AND "Python" AND "San Francisco" NOT recruiter NOT intern

Open-web (Google) X-ray:
site:linkedin.com/in/ ("Software Engineer" OR "Backend Developer") "San Francisco" "Python" -job -jobs -recruiter

GitHub user search:
language:python location:"San Francisco" followers:>10 type:user

The three are not interchangeable one-for-one. The GitHub version proves shipped code but misses anyone whose location field reads "SF" or is blank. The open-web version reaches public profiles that may not surface inside LinkedIn, but it hits Google's served-result ceiling fast. The LinkedIn version has the richest title data but costs you against the monthly search limit. Running all three is how you catch the profiles each one drops.

Writing the query the first time, in order

This is the procedure to run once per role. It moves from candidate-language synonyms through source selection, exclusions, and cap management, to a spot-check for silent misses.

Two experienced practitioners order step one differently. One treats title-listing as a fixed first step; the other starts broad and adds NOT and parentheses iteratively after reading results. Both are defensible. What is not defensible is skipping the spot-check, because the failure modes below are invisible until you look.

The query above is the point of this whole reference. Writing it by hand means running location:"Berlin", then location:"Deutschland", then a blank-field pass, then merging and de-duplicating - and still missing the people who wrote "Remote". Asking in plain English and letting Refolk reconcile the location-field variants removes the step where most of a market disappears.

The result caps that truncate your pool without telling you

Every source caps the number of results it returns, and the dangerous ones give no error when you hit the ceiling. If your true population is larger than the cap, you are working a truncated pool and do not know it.

The GitHub cap is the trap. The API returns up to 1,000 results and fires no exception or error at the limit. Set that against Refolk's index of 2,869 US software and backend engineers who write Go: roughly two-thirds of them are unreachable in a single unsegmented query, and nothing tells you so.

Google compounds the problem on the open-web fallback. It serves only about 300 to 400 actual results per query no matter what headline total it claims, and in mid-2025 it stopped supporting the &num=100 parameter, so every page now returns 10 results. An X-ray that once needed one page to approach the ceiling now needs far more pagination. Treat the headline "166,000 results" as fiction and paginate to the real end.

LinkedIn free adds a second ceiling beyond the per-search cap: a Commercial Use Limit of roughly 300 people searches per month, resetting at midnight Pacific on the first of each month. Sales Navigator lifts the per-search cap to 2,500 but you still segment large populations.

How these queries go wrong: the silent misses

This is the most valuable section because every failure here is invisible until you check for it. Each one produces a plausible result that is quietly wrong. Below is the table of failure modes, what the false positive looks like, and how to check.

The location gap deserves extra weight because it fails exactly where sourcers feel most confident. In Refolk's index, Germany shows 328 software and backend Go engineers against 2,869 in the US - an 8.7x gap. Some of that is a real market difference, but part is a field-format artifact: many German developers write "Deutschland" or leave the location blank, and location:"Berlin" cannot bridge that. A thin result reads as a thin market when it is a thin query.

There is a second lesson buried in that German sample: Google alone accounted for 32% of the Go profiles versus 12% in the US sample. A naive Go-in-Germany search leans heavily toward one employer's current and former staff, narrowing the diversity of your pipeline before you have read a single profile.

A thin result reads as a thin market when it is really a thin query.

Skill-tag inflation is the subtlest miss. Self-reported skill tags over-count, and they can invert reality.

Refolk's index returns more US Vue.js profiles than React - the reverse of known framework adoption. That is not a market fact; it is evidence that a self-reported skill field is a weaker population signal than an owned-repo language or a title. Before you size a market off a skill tag, triangulate it against something the person had to do rather than claim.

Verify before you call the search done

Before you treat a result set as your population, run this checklist. It takes a few minutes and catches the misses that otherwise surface three weeks into the search when the pipeline runs dry.

Keeping this reference current

The operators and failure modes in this document are stable, but two things change under you: the result caps and the field conventions. Caps move when a source changes its policy - Google's removal of the &num=100 parameter is the live example, and it shifted the open-web fallback from one page to many. Re-check the served-result ceiling on your primary source whenever a search that used to fill a pipeline suddenly runs thin for no obvious reason.

Field conventions drift too. The free-text location problem is permanent in shape but changes in detail as populations shift which labels they use. The practical habit is to keep a short list of the location variants that matter for your markets - the local-language name, the country name, "Remote", and blank - and run all of them every time rather than trusting a single string.

The deeper discipline is the one the failure-modes table teaches: treat every count as a claim to be checked, not a fact. A query that returns a number is not the same as a query that returned the right people. The reference above tells you, attribute by attribute, where the two diverge. Run the spot-check, translate across sources, and segment under the cap, and the query that returns the right candidates the first time stops being luck.