One Sourcing Search: From First Query to Ranked Shortlist

This guide carries one real candidate search from the first query to a sent shortlist, showing the actual counts at each fork and the wrong turns taken and reversed. It is for in-house recruiters, sourcers, talent leaders, and founders running their own searches. By the end you can look at any count your search returns and say whether it is a query problem you should fix or a market fact you should accept.

Most sourcing advice is either a copy-paste boolean cheat sheet or an abstract three-step shortlist article. Neither shows you a single search with the intermediate numbers. This one does. The worked case is a Site Reliability Engineer role, and the counts come from Refolk's index of professional profiles. Follow along on your own req as you read.

What one sourcing search actually looks like

A sourcing search is not one query. It is a sequence of forks, and at each fork a count tells you to loosen, tighten, or stop. The skill is reading the count, not memorising operators.

Here is the whole arc for the SRE case, so you can see where you are headed before you start.

The reason this matters: a bare count lies to you. In Refolk's index, "Site Reliability Engineer" with Kubernetes in the United States returns 1,228 people. The same title and skill in Germany returns 203. If your rule were "a good set is under 200," you would flag the US pool as broken and start hacking at a query that was fine. Huge is a property of the market, not the query.

So the first discipline is to stop treating the count as a verdict on your string. It is a reading you interpret against what you know about the market. The rest of this guide is how to do that interpretation at each fork.

Read the count: what "too many" and "zero" actually mean

Practitioner convention holds a healthy people-search set at roughly 50 to 200 profiles on LinkedIn and 20 to 50 on Google X-ray. No regulator publishes these cutoffs; they are conventions, and they are bands to steer toward, not laws. A market can legitimately sit outside them.

To calibrate scale: type "software engineer" into LinkedIn with nothing else and you get about 3 million results. That number tells you nothing about talent. It tells you the title is common. The whole job of the search is to walk that 3 million down to a set you can actually read, without walking it down to zero by accident.

Three readings, three responses:

That bottom row is the dangerous one. A zero count carries no information until you have run a baseline, because a syntax error and an empty market produce the identical output. This is the core idea of the whole guide, so it gets its own rule.

The named risk here is silent failure. Your string returns zero on LinkedIn, you assume the candidate pool is empty, and you move on. The pool was fine. The string had a stray operator. This is the mistake that quietly costs recruiters the most time, because it produces no error message and no obvious signal that anything went wrong.

Build the string one operator at a time

Build the string incrementally: add one operator, check the count, then add the next layer. This is not a style preference. It is the only way to know which operator did the cutting when the count moves.

Here is the SRE search built up, with the count read after each layer. This is the spine of the walkthrough, and the numbers are from Refolk's index.

Start with the title, broad, in the target market. "Site Reliability Engineer" in the United States is a large pool. Now layer the first must-have skill, Kubernetes, with AND:

Layer 1  title only:            "Site Reliability Engineer", US        -> large pool
Layer 2  + Kubernetes (AND):    "Site Reliability Engineer" AND Kubernetes, US  -> 1,228
Layer 3a + Rust instead:        "Site Reliability Engineer" AND Rust, US        -> 6
Layer 3b + Senior filter:       "Site Reliability Engineer" AND Kubernetes, US, Senior  -> 0

Read what those numbers say. Layer 2 lands at 1,228, above the LinkedIn band but a perfectly normal count for a common skill in a large market. That is a set you can work with by splitting it, not a broken query.

Layer 3a swaps Kubernetes for Rust and the count collapses to 6. Layer 3b keeps Kubernetes but adds a Senior seniority filter, and the count collapses to 0. Both look like collapses. They are opposite problems, and the next two sections pull them apart, because confusing them is how you either abandon a real market or hack away at a real scarcity.

The over-filter fork: when your own query zeroed the pool

An over-filter fork is a zero that you created. The market has people; your string just excluded all of them with one operator too many. You diagnose it by removing the last operator and watching the count jump back.

Layer 3b is the textbook case. The unfiltered pool was 1,228 real people. Add a Senior seniority filter and it reads 0.

Zero percent retained from a single filter is the signature of an over-filter artifact. A market that genuinely had 1,228 people does not have zero senior ones; far more likely the seniority field is populated inconsistently, or the filter interacts with the title match in a way that excludes everyone. The number is a query artifact, not a scarcity fact.

The fix is not to broaden blindly. It is to identify the operator that did the cutting, which the incremental build already told you, and decide whether that filter is worth its cost. Here you would drop the seniority filter and instead read seniority from the profiles themselves in the fit scan: years, scope, and title progression tell you who is senior more reliably than a filter field that just zeroed your pool.

This is also why preemptive NOT clauses are a trap. A NOT you add before seeing a false positive can silently exclude titles that also contain your target term. Add NOT only after you have watched the false positive appear in results.

The scarcity fork: when the small number is the truth

A scarcity fork is a small count that is real. The market is genuinely tiny, and no amount of query loosening manufactures people who do not exist. You diagnose it by loosening operators and watching the count fail to move.

Layer 3a is this case. SRE plus Rust in the US returns 6 people in Refolk's index. Compare it to the Kubernetes cohort in the identical market:

The Rust cohort is roughly 205 times rarer than the Kubernetes cohort in the same country, same title. That 6 is not a broken string. It is a market fact. You can confirm it is real the same way you diagnose everything else: your title-only baseline for US SREs is large, so the syntax works; the collapse happened only when you specified a rare skill. Baseline healthy, specific query tiny, means real scarcity.

Some scarcity is real, and no operator you add will conjure people the market never grew.

When you hit a real scarcity fork, the response is a strategy decision, not a query decision. With 6 people you do not build a funnel; you build a named-target list and accept a longer, more personal outreach cycle. You might also loosen a deliberately chosen constraint: drop the exact title and search for the capability instead, because the platform engineers who own reliability but whose titles never say SRE are exactly the people a literal title match misses.

This is where a semantic tool earns its place. A literal boolean engine returns only exact term matches and will never surface the person who describes Rust systems work without using your skill keyword. Interpreting the intent behind a search, rather than matching its literal tokens, is the difference between finding 6 people and finding the 30 who actually do the work under different words. Tools like Refolk let you state the capability in plain English so the query is the intent, not a token string you hope the profile happens to echo.

The market-size fork: when huge is normal

A market-size fork is a large count you are tempted to treat as broken. It is not broken. Some markets are simply big, and a threshold applied blindly flags them as errors.

Layer 2 is this fork: 1,228 for SRE plus Kubernetes in the US. Set that beside Germany:

Same string, 6x difference. If you carried a rigid "under 200" rule across both markets, you would accept Germany and start mutilating a perfectly good US query. The right response to 1,228 is not to narrow until it drops below 200. It is to split the set into readable slices, by company size, by sub-skill, by region, and read each slice.

Splitting also defeats a false ceiling. LinkedIn free browsing caps at 1,000 results per session and Sales Navigator at 2,500, regardless of the true pool. Any market above the cap reads as exactly the cap. A 1,228-person pool would show as "1,000+" on a free account, hiding a quarter of itself. If you read that ceiling as the total market, you undercount.

The procedure: one search, start to finish

Run these eight steps in order on your own req. Each ends with a definition of done, so you know when to move to the next fork rather than drifting.

Two notes on order. Sources disagree on whether to start broad and narrow, or to pare to basics on a specific site and add operators back "one at a time in order of priority." Both work. What matters is that you change one thing per step, because a count only teaches you something when you know which operator moved it. And on a specific website, pare down to the basics first, then reintroduce operators by priority.

Scan for fit, not keywords, then stop

Scanning for fit means reading each profile for evidence of the work, not for the presence of your search terms. Keyword filtering rewards candidates who optimise their profiles for search rather than for genuine fit, so a pure term match systematically over-selects self-promoters.

Use four signals to separate a qualified profile from a merely decent one:

A candidate who looks like a poor match on keywords alone can surface as a top-3 fit once you account for trajectory, company-size experience, and skills adjacency. This is the payoff of not stopping at the term match. It is also why the platform engineer whose title never says SRE belongs on your list.

Watch for two lies here. Profile-optimised resumes list the right words and fail the four signals; verify the work, not the vocabulary. And a semantic engine that returns a big, confident set may have quietly reinterpreted your terms into a broader query. If a tool cannot explain why a profile matched, distrust the ranking. Over-recall dressed as coverage is still over-recall.

Then stop. The most common way a search fails is not a bad string; it is that sourcing drifts into endless screening and never ships a list. Fix a deliverable size before you scan. The golden rule is 3 to 5 candidates per role, broad shortlists run 10 to 20, and managerial roles often sit at six to 10. Pick one, time-box the scan, and cut to it.

Keep the search current: the failure modes

The most valuable habit is knowing how this goes wrong, because the failures are silent and produce confident-looking numbers. Here are the false positives to check for, drawn from the case above.

• Silent zero read as empty market. A string returns zero and you conclude no such candidates exist. Rerun a known-good baseline; if it also returns zero, the syntax is broken.
• Over-stacked operators rule out good people. A clean short list that is artificially narrow. Remove the last operator and watch the count jump, as the Senior filter took 1,228 to 0.
• Preemptive NOT clauses. A NOT excludes titles that also contain your target. Add NOT only after seeing the false positive.
• Cross-platform string reuse. A Google string returns zero on LinkedIn purely because of dialect, then reads as an empty market. Retune per platform, and baseline-test the retuned string.
• Semantic over-recall read as precision. A big, confident set that quietly reinterpreted your terms. Demand explainable ranking; if the tool cannot say why a profile matched, distrust it.
• Keyword match mistaken for fit. Profile-optimised resumes list the right buzzwords and fail the four signals. Verify trajectory, scope, and outcomes.
• Result cap mistaken for total market. A pool above 1,000 reads as exactly the cap on a free account. Split by filter to see beyond it.
• Endless screening drift. Sourcing that never ships a list. Enforce a deliverable size of 3 to 10 and a time box.

One more mechanism to plan around: strings decay. A string that worked in one month can return half the candidates a few months later, as profiles change and platforms adjust. Do not treat a good query as permanent. Re-run your baseline periodically, and if a once-reliable string suddenly returns a suspiciously low count, suspect decay before you suspect the market. The discipline is the same one this whole guide teaches: no count is a verdict until you have checked it against a control.

The next time a search hands you a zero or a huge number, do not reach for a new operator. Reach for a baseline. Ask whether the number is your string talking or the market talking. That single question, asked at every fork, is what turns a pile of operators into a search you can trust.