A search for a hard role usually gets tuned by its result count, whether it runs as a Boolean string or as a request to an AI candidate sourcing tool. One run brings back a few thousand people, so terms go in until the number looks readable. The next brings back a dozen, and the requirement that seemed least important comes out. Either way the count has set the bar, and the hiring manager meets a shortlist built to a standard no one agreed to.

I’d settle what qualified means before the first run, in the words qualified people use about their own work, and test the search first, reading its opening results as a check on the search before reading them as candidates. When the count comes back wrong, change the words and leave the requirements alone. Kept that strict, the method holds when several recruiters search one role family at once, which is where a bar usually starts to drift.

Borrow the search terms from people who already qualify.

Hiring managers name a role’s needs in their own vocabulary, and the people who fit it describe themselves in another. This step builds the search from the second.

Pick a handful of people you already know are qualified, such as people on your own team who do this job well and finalists from the role’s last search. The hiring manager can usually add a name or two from places they have worked. Open their profiles and copy the words they use for each thing the role needs. For an engineering manager on a payments team, one profile might say “engineering lead” where another says “head of platform,” and the payments experience might read “ledger” on one and “payouts” on the next.

Only some requirements survive that exercise, because a search can match a requirement only when people write it down. Job titles and system names turn into words. Whether someone grew a team by hiring, or held up under an outage that cost money, turns into nothing a search box can use, so I keep those as reading lines: the things a person checks once the results are in. Everything that does turn into words becomes a search line, written as a group of the borrowed words joined by “or,” with the groups joined by “and.” A plain-language request to a sourcing tool gets the same groups in sentence form, every alternative included, so the request names which other titles count.

Leave company names out at first. A list of companies shrinks the count fast, and it does that by dropping everyone who did the same work somewhere you didn’t name.

Test the search on people you know are qualified.

Before you read a single new name, check that the search finds the people whose words you borrowed. When one of them is missing, you learn fast that a group of words is too narrow.

Run the search without excluding your own company, so your current team can show up, and look for every known person in the results. Where someone is missing, put their profile beside the search and find the group none of their words matched. That group needs the word they used. Keep adding words until the search finds all of them.

If a search can’t find the people already doing this job well, it won’t find the next one either.

Past finalists are usually the easiest known people to collect. Bringing them back as candidates for the new opening is its own job, and candidate rediscovery covers how to do it.

Read the first results for what the search let in.

Now run the search and read its opening results as a report on the search itself. I’d read about 25 profiles against the reading lines and note, for every one that fails, which word brought it in.

When most of the failures share a word, that word means something else somewhere: “London” pulls in London, Ontario, and “payments” pulls in people who sold payment products. Trace failures to a word, then add one from the same group that only the people you want would use, or exclude the meaning you don’t want. If a failure matches every search line and misses only a reading line, leave the search as it is. Turning that profile down is the reader’s job, and it is the reason the reading lines stayed out of the search.

Then look for who is absent. If none of those results shares the background of one of your known people, such as an engineer who moved into management at a bank, the search still lacks the words that background uses, and your set of known people needs someone from it too.

Widen or narrow AI candidate sourcing without moving the bar.

Once the search finds your known people and most of its opening results meet the reading lines, the count is the last thing to fix. Fix it with words, and leave the requirements alone.

A low count after the search has found every known person usually means a small market for the role, and I’d tell the hiring manager that before touching the requirements. If they decide to accept a new background, such as engineers who led a team without the title, put the change in writing as a new search line, so everyone can see the bar moved and who moved it.

Sometimes the people you want are not where the search looks. Choosing recruitment channels for a role is a decision of its own, made before more words go into the search.

Share tested searches across a role family.

One recruiter tuning one search can hold the bar by care alone. Several recruiters searching a role family at once, or one high-volume role with several people reading results, need the method written down where all of them work from it.

• Keep one set of word groups per family. Agree the search lines once, with their word groups, and let every recruiter add a word only to the shared groups. Two recruiters who each write their own search for backend engineering end up with two bars.
• Keep a standing set of known people for the family as well, and run every new or edited search against it before anyone reads a result. A recruiter who joins the family later then starts from a search that has already passed.
• Log failures in one shared place. When several people read results, each writes down the word behind every failure in that log. A word that misleads one reader then gets fixed in the shared groups for everyone, instead of in one person’s copy.
• Roles that share most search lines can run as one search, with one extra group per role for the line that differs. Read each role’s results against its own reading lines, because a profile that fails one role’s line can still suit another.

The log is the part teams skip, and I’d start with it. Without it, every reader fixes the same misleading word on their own, and each fix moves a little further from the agreed groups.

When a family moves into a new city or industry, a talent map of the market shows where people with the background work now, and any companies or titles it adds go into the shared groups only once the search still finds every known person.

Where Metaview fits in finding qualified candidates.

The known-people test works on a sourcing agent the same way it works on a string, and it shows fastest whether a request says what you meant. Write one request in plain language for a role you have filled before, then look for that role’s last finalists among the candidates it returns.

AI Sourcing takes that request as one prompt written in natural language. The agent searches the open web and, if your applicant tracking system (ATS) is connected to Metaview, the candidates brought over from it, and it also reads through interviews your team captured with Metaview. If a finalist your ATS holds doesn’t come back, the request lacks a word they use, the same gap a string would have.

Every candidate it returns arrives with the agent’s reasoning for including them, and nothing more is done to that name: no message goes out, and no one is marked as meeting the bar, until a recruiter acts.

For a family moving into new ground, Deep Research, the market-mapping mode of AI Sourcing, answers questions about the market, such as which of the fastest-growing employers in a city are hiring for the role, with charts and tables as well as profiles. Those employers are new words like any others, so the known-people test applies to them too.

Recorded interviews are another source of search terms. Where the people in a call have agreed to be recorded, which your team arranges, Metaview’s Notetaker can join as a visible participant, then record and transcribe the call, and the Notetaker turns that conversation into structured notes.

With names and organizations transcribed correctly, a transcript can serve as a source of search terms. Metaview captures every spoken word. For a search, that means a strong past candidate’s own description of their work, with the system names and team titles they used, can go straight into the word groups for the next role like theirs.

Check the shared search when a new opening arrives.

Every finalist your team meets for a role family joins the standing set of known people, so the set grows with each opening and the test gets harder to pass by accident.

When a new opening arrives, test the shared search against the set before anyone edits it. People it misses show which group of words has aged, usually because a title changed or a tool was renamed. When it still finds everyone but more of its opening results fail the reading lines than last time, some word has picked up a new meaning in the market. Check the failure log for it. And if the hiring manager asks for a new requirement, the search starts again from the borrowed words, because a new line means a new search.

A team that runs searches this way can keep many open across a role family, with several people reading results, and still mean the same thing by qualified in every one of them.