---
title: "Plain-language filters vs boolean search: a calmer way to shortlist"
description: "Boolean strings are powerful and brittle. Plain-language filters are readable, reviewable, and forgiving. Here is when each wins, and why readable logic matters for fair hiring."
url: https://zjcv.com/journal/plain-language-filters-vs-boolean-search/
canonical: https://zjcv.com/journal/plain-language-filters-vs-boolean-search/
author: "Zen Job CV Team"
published: 2026-06-04
updated: 2026-06-04
category: "Playbooks"
tags: ["plain-language filters", "boolean search", "cv screening", "shortlisting"]
lang: en
---

# Plain-language filters vs boolean search: a calmer way to shortlist

> **TL;DR** Boolean search (AND/OR/NOT keyword strings) is precise but brittle: it is hard to read, easy to get wrong, and it silently drops anyone who phrased their CV differently. Plain-language filters express the same intent in readable rules you can soften and reorder, and they keep near-misses visible. For fair, high-volume screening, plain-language filters with soft matching win, which is how Zen Job CV works.

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 `AND` and 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 `NOT` that 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](https://www.nber.org/papers/w9873) 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:

1. **Anyone can review them.** A hiring manager can read the filters and immediately agree or push back. No syntax to decode.
2. **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](/journal/how-to-screen-hundreds-of-cvs/): never silently drop a near-miss.
3. **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](https://gdpr-info.eu/) 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](/journal/bias-aware-blind-cv-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](/journal/track-applicants-without-ats/) and, if they arrive by email, [how to parse resumes from your inbox](/journal/parse-resumes-from-email/). If you are choosing a tool, [how to choose CV screening software](/journal/best-cv-screening-software-for-hr-teams/) walks the categories, and [boolean search](/journal/boolean-search-for-recruiters/) 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.

---

Source: https://zjcv.com/journal/plain-language-filters-vs-boolean-search/
Author: Zen Job CV Team