A candidate search returns poor matches most often because a real requirement was entered as a wish, or because too many requirements were made hard. A must-have is a criterion without which you would not contact a person at all; a nice-to-have is a strong but negotiable signal. Keep three to five musts, mark everything else as a wish, and check each must against three questions: could a strong hire lack it, can you see it in a public profile, and is it lawful and job-related to filter on it?
Why does my candidate search return poor matches?
Read the result list as a symptom, not as a verdict on the tool. The pattern of the bad results usually points to one of four causes:
| What you see | Likely cause | What to change |
|---|---|---|
| Good profiles overall, but the one thing you need (a certificate, a language, a domain) is missing in most | A real requirement was entered as a wish, so the search ranks by overall similarity | Move it to the must column |
| Hundreds of loosely related profiles | No musts at all, or a brief that is only a job title | Add three to five musts and describe the work, not only the title |
| Three profiles, or none | Too many musts, or a must that a profile cannot show | Cut to the criteria that truly rule people out; check that each one is visible in a profile |
| Right titles, wrong seniority or wrong field | The job title is used as a stand-in for the capability | Describe the capability and the context in which it was used |
The first row is the one we meet most often. In our conversations with recruiters and agencies, the most common user mistake in a search is entering requirements as nice-to-have when the hire would fail without them; the result gets worse, and with the same requirement marked as a must it gets clearly better. The cause is the search, not the data.
What is the difference between a must-have and a nice-to-have?
A robust search separates four things: Must (without it no contact makes sense), Nice-to-have (a strong signal that may be traded off), Exclusion (a reason to stop reviewing someone) and Evidence (what in a profile shows that the criterion is met). The separation matters more than the choice of tool, because every method, Boolean or natural language, needs it. In a Boolean string a must becomes an AND group and a wish an optional OR; in a requirement search you mark it. How the two methods differ is covered in Boolean vs. requirement search and Boolean vs. natural language.
Which three questions decide whether something is a must?
- Could a strong hire lack it? If yes, it is a wish. A degree is the classic case: many strong people in scarce markets built their skills on the job. Write the capability as the must and the degree as a wish.
- Can you see it in a public profile? A must that profiles rarely state (a tool used on one project, a notice period) cannot be filtered on. Treat it as a question for the first message.
- Is it lawful and job-related to filter on it? In Germany the General Equal Treatment Act (AGG), section 7 prohibits disadvantaging people because of the grounds listed in section 1 (race or ethnic origin, gender, religion or belief, disability, age, sexual identity). Section 6 counts applicants as employees, and section 8 allows a difference in treatment only where the ground is an essential and decisive occupational requirement. Apply the same standard at the search stage: a filter on age or gender is not a must.
A worked example with assumed numbers
The numbers below are an illustration of the mechanism, not a measurement. Assume a role as an embedded software engineer in DACH with functional-safety experience. A first search finds a pool of 400 profiles that fit "C++ and embedded". Assume 15 % of them show functional-safety experience, which is 60 people.
| Entry | What the search does | Expected share with functional safety in the top 15 |
|---|---|---|
| Functional safety as a wish | Ranks all 400 by overall similarity; the 60 are spread through the list | About 15 %, so roughly 2 of 15 |
| Functional safety as a must | Keeps only the 60 and ranks within them | 15 of 15 (all from the 60) |
Now the opposite error. Suppose you add three more musts and each one removes half of what is left: automotive experience, fluent German and eight or more years of experience.
| Musts | Assumed pass rate | Profiles left |
|---|---|---|
| C++ and embedded (the pool) | - | 400 |
| plus functional safety | 15 % | 60 |
| plus automotive experience | 50 % | 30 |
| plus fluent German | 50 % | 15 |
| plus eight or more years | 50 % | about 7 |
Each additional hard criterion halves the list in this example, and the last one leaves too few people to contact. In a thin market that is the moment to demote one must to a wish or to widen the field, as described in sourcing bottleneck roles.
How do I set the criteria in practice?
- Write down the role as the work that has to be done, then list candidate criteria.
- Run the three questions on each criterion. Keep three to five musts.
- For every must, write down the evidence you expect to see in a profile.
- Run the search with your real vacancy rather than a sample role. In our conversations, the live test with the customer's own role is where the impression turns most quickly.
- Read the first ten results and note why each is wrong. A pattern means a criterion is on the wrong side of the line; adjust one criterion at a time.
In Atlas, you describe the requirements and mark the ones that are musts; the AI checks every profile individually against them and shows a reason for each requirement, so a mistake in the list is visible in the result instead of hidden in a ranking.
Does the AI Act affect how I set criteria?
Systems that filter or evaluate candidates fall under the high-risk category of Annex III of the EU AI Act; the obligations for high-risk systems apply from 2 December 2027 under Regulation (EU) 2026/1744. For your own search, that is a reason to document the musts and the evidence you used, so that the shortlist can be explained. For contacting people you found, the usual rules apply: legitimate interest under Art. 6(1)(f) and information under Art. 14 of the GDPR, covered in active sourcing and GDPR.
Frequently asked questions
How many must-have criteria should a search have?
Three to five. Fewer returns a loose list, more shrinks a thin market to nothing, as the example above shows. Only criteria whose absence really rules out a contact belong in the must column.
Should the degree be a must-have?
Usually not. Make the capability the must and the degree a wish, unless the degree is legally required for the activity, for example a licensed profession.
Should location be a must-have?
Only if the role cannot be done remotely or relocation is excluded. Otherwise treat location as a wish and ask about relocation in the first message.
Why does my search return only a few profiles?
Count the musts first. If you have more than five, or a must that profiles rarely state, loosen those. If the market is small, widen the field; see sourcing bottleneck roles.
Does this apply to Boolean search too?
Yes. In Boolean a must is an AND group and a wish an optional term. The mistake is the same: a requirement left out of the AND group disappears from the result. The comparison is in Boolean vs. requirement search.
Can ChatGPT set the criteria for me?
It can draft a list and challenge your wording, but it cannot know which criterion is a real must for your vacancy. Decide the musts yourself with the three questions, then let the tool help with the wording.
To try this on your own vacancy, start with the free account at Sprad Active Sourcing. A comparison of the tools themselves is in the 9 best active sourcing tools, and the wider topic is collected in the active sourcing hub.
Jürgen Ulbrich
Jürgen Ulbrich has more than a decade of experience in developing and leading high-performing teams and companies. As an expert in employee referral programs as well as feedback and performance processes, Jürgen has helped over 100 organizations optimize their talent acquisition and development strategies.
