Natural Language Candidate Search: Five Real Queries, and Why Vague Ones Fail

Natural language candidate search means describing the person you want in a sentence and getting a ranked result, with no operators and no filter builder. It works. It also fails in one specific and predictable way, and the failure is entirely the fault of the person typing.

Below are five real queries our customers run, the results two of them returned, and the query that disappoints people most often, shown alongside the version that works.

Five natural language candidate search queries recruiters run

These are typed as sentences. No operators, no nesting, no field selection.

Look at the fourth and fifth. Each contains five separate conditions, two of which are not keywords at all. "Top law firms in Mumbai" requires knowing which firms those are. "Good experience of litigation" is a judgement about depth, not a term that appears in a document.

Writing that as a Boolean string means enumerating the firms by hand, guessing at the phrasing lawyers use to describe litigation work, and accepting that anyone who phrased it differently is invisible to you. The fifth query has the same problem with "voice AI", which is a field rather than a keyword, and which people on the ground describe as speech, ASR, TTS, or by naming the specific models they worked on.

What each query is actually asking for

The candidate search query that disappoints people

Here is the one that comes up constantly.

Three conditions, all reasonable, and the results are underwhelming. Not because the search failed, but because the query described a category rather than a person. There are a great many backend engineers in Bangalore with four years of experience, and nothing in that sentence says which of them you want.

Now the same intent, specified properly:

Same role. Completely different result set, because now the system has something to rank against. The second query has seven conditions and three of them are the ones you would actually reject someone for.

This is the single most useful thing to teach a new sourcer, and it takes one session rather than a quarter. It is also the reason the scorecard matters: a recruiter who has already defined the criteria has, in effect, already written the query.

Four elements every candidate search query needs

Every query that works contains these. Every query that disappoints is missing at least two.

The fourth row is the one people leave out, and it is usually the one that decides the shortlist. A backend engineer from a fintech and one from a services company are different hires for most roles, and the query has to say so.

Level is worth a note too. A range beats a number. "Four years" excludes the person with three years and eleven months who is exactly right, and includes nobody you were not already going to see.

Where natural language search does not help

Stating this plainly is what makes the rest of the post credible.

• Exact-match requirements. A specific certification number or a named employer is a filter, not a description. Use the filter.
• Hard numeric cutoffs. "Exactly 5 to 7 years" is a range filter. "Experienced" is a description. Do not use the second when you mean the first.
• Negation. "Not from a services background" is interpreted inconsistently. State the positive instead.
• Very long queries. Past a certain length, extra clauses dilute rather than sharpen. Two precise sentences beat one paragraph.

Searching your own database, not the open web

Worth being explicit, because it sets expectations correctly.

This search runs across your own records. Candidates you have sourced, screened, submitted, placed or rejected over the years. It does not search the open web and it is not a substitute for a sourcing licence when you genuinely need someone your firm has never encountered.

That constraint is a feature more often than it is a limitation. Searching your own database costs nothing per search, the people in it have usually dealt with you before, and every search makes the pool more current. External sourcing carries a per-seat licence cost and starts cold every time.

The right sequence is to exhaust the first before paying for the second. In one firm's data, that shift took job portal spend from roughly $100 per role to $60, which we cover in the talent pool audit.

What changes for the sourcer

The scarce skill moves.

A sourcer who could write a five-level nested Boolean string had something genuinely rare. A sourcer who can describe exactly what a good profile looks like, including the things that never appear on a CV, now has the rare skill. The second is more useful, transfers across tools, and can be taught to a new joiner in a session rather than a quarter.

The practical training is one sentence: name the capability, the level, the constraint and the context, every time. Everything else is refinement.

Semantic search versus Boolean, side by side

Worth understanding the difference in mechanism, because it explains both the strengths and the failure cases above.

Boolean search matches strings. You give it terms and logic, it returns documents containing those terms in that arrangement. It is exact, it is predictable, and it is blind to anything phrased differently from how you phrased it.

Semantic search matches meaning. It represents both the query and each profile as positions in a space where related concepts sit near each other, then ranks by proximity. "Voice AI" lands near "speech recognition" and "ASR" without anyone maintaining a synonym list, which is why the fifth query above works at all.

The practical answer for most desks is both, used for different jobs. Describe the person in a sentence, then apply hard filters for the things that are genuinely binary: notice period, location, work authorisation, rate band.

Common natural language search mistakes

Five patterns that account for most of the disappointment we see.

Writing the job title instead of the person

"Senior software engineer" is what the requisition says. It is not what you are looking for, and it is the single most common weak query.

Stacking too many clauses

Past roughly twenty-five words, additional conditions dilute the ranking rather than sharpening it. If the requirement genuinely has ten conditions, split it into two searches and compare the overlap.

Using a number where a range belongs

"Six years" excludes the person with five years and ten months. Ranges are almost always what you actually mean.

Describing the company instead of the candidate

"Someone for a Series B fintech" tells the search nothing about the person. Convert it: what does someone who succeeds at a Series B fintech look like on paper?

Forgetting availability entirely

A perfect profile on a six-month notice is not a candidate for a role closing in four weeks. Availability belongs in the query, not in the disappointment afterwards.

Frequently asked questions

How to test this on your own data

Take your last ten filled roles. For each, write one sentence describing the person you actually placed, using all four elements. Run it.

Then check whether the person you placed appears near the top. It is the only benchmark worth anything, because you already know the right answer, and it takes an afternoon rather than a pilot.