If you are choosing between writing boolean search strings and writing plain-language filters to shortlist candidates, plain-language filters win for almost every high-volume hiring team. They are readable, reviewable, forgiving of how people phrase their CVs, and they keep near-misses visible instead of silently dropping them. That is the approach Zen Job CV takes: you describe your ideal candidate in plain words, mark each rule as must-have or nice-to-have, and every candidate is ranked with the reasons attached. Here is the honest comparison.
What is boolean search, and why is it brittle?
Boolean search builds a query from keywords joined by operators: AND, OR, NOT, quotes, and parentheses. A recruiter might write:
("product designer" OR "UX designer") AND Figma AND ("team lead" OR "led a team") NOT junior
It is genuinely precise, and for narrow sourcing it is powerful. But three things make it brittle at screening scale:
- It is hard to read. By the third
ANDand second nested parenthesis, almost nobody on the team can tell you exactly who the string includes and excludes. - It is unforgiving of phrasing. A candidate who wrote “managed a team of six” instead of “led a team” is silently excluded, not because they lack the experience, but because they used different words.
- It hides its own mistakes. A boolean string returns a set. It does not tell you why someone was excluded, so an accidental
NOTthat quietly removes strong candidates can sit undetected for a whole hiring round.
That last point matters beyond convenience. Screening logic you cannot read is screening logic you cannot audit, and unauditable logic is exactly where unintended exclusion hides. The correspondence research on callbacks is a reminder that hiring decisions carry biases we do not notice; a rule you cannot inspect gives those biases a place to live.
How are plain-language filters different?
Plain-language filters express the same intent as readable rules:
- 5+ years of experience
- Has led a team
- Speaks Dutch
- Portfolio included
Three properties make them calmer to work with:
- Anyone can review them. A hiring manager can read the filters and immediately agree or push back. No syntax to decode.
- They can be soft. Mark a filter as nice-to-have and a candidate who misses it is flagged for review, not dropped. This is the single biggest difference from a boolean string, which has no concept of “close.” It is the same principle behind the wider fair, high-volume screening workflow: never silently drop a near-miss.
- They stay explainable. Every candidate shows which filters they met and missed, so the ranking is reviewable and defensible, and logged decisions align with the transparency the GDPR expects around automated processing.
Do you lose precision?
No, and this is the common misconception. Good plain-language filters translate into precise screening logic underneath; you simply do not hand-write the brittle syntax. You get semantic matching (so “managed a team of six” satisfies “has led a team”), the ability to weight and soften rules, and a per-candidate explanation. Boolean gives you an exact set with no reasons; plain-language filters give you a ranked list with reasons and a visible near-miss pile.
Head to head on the things that decide a screening step:
| What you need | Boolean search | Plain-language filters |
|---|---|---|
| Readable by the whole team | Syntax to decode | Plain rules anyone checks |
| Tolerance of how a CV is phrased | Exact terms only | Semantic matching |
| Near-misses | Excluded silently | Flagged for review |
| A reason per candidate | None, just a result set | Met and missed criteria |
| Auditable logic | Hard to inspect | Readable is auditable |
Which should you use?
| Situation | Better tool | Why |
|---|---|---|
| Screening a high volume for one role | Plain-language filters | Readable, soft matching, explainable, keeps near-misses |
| Precise external sourcing on a job board | Boolean search | Exact keyword targeting where a set is what you want |
| A hiring manager needs to review the criteria | Plain-language filters | No syntax to decode; agree or push back in seconds |
| Auditing why someone was excluded | Plain-language filters | Per-candidate reasons vs an opaque result set |
| Fairness matters (it always does) | Plain-language filters | Readable logic is auditable logic; pairs with blind screening |
Boolean still has its place in sourcing. But for the screening step, turning many applicants into a fair, defensible shortlist, readable rules beat clever strings. Where those applications live is a related question: see how to keep track of applicants without an ATS and, if they arrive by email, how to parse resumes from your inbox. If you are choosing a tool, how to choose CV screening software walks the categories, and boolean search is the sourcing counterpart to plain-language screening.
Which one to use for your next role
- Boolean search is precise but brittle: hard to read, unforgiving of phrasing, and it hides its own exclusions.
- Plain-language filters express the same intent in rules anyone can review.
- Soft filters flag near-misses instead of dropping them; boolean has no “close.”
- Readable logic is auditable logic, which matters for fair hiring and GDPR transparency.
- Zen Job CV runs on plain-language filters with soft matching and per-candidate reasons.
Quick answers
What is boolean search in recruiting? Candidate queries built from keywords and operators (AND/OR/NOT), precise but brittle and hard to audit.
Why are plain-language filters better for screening? They are readable, can be softened so near-misses are flagged, and stay explainable per candidate.
How does Zen Job CV handle filters? You write them in plain language, mark each must-have or nice-to-have, and every candidate is ranked with reasons attached.