Why keyword job alerts fail

Everyone who has job-hunted seriously has run the same experiment. You set up an alert. It sends thirty things a day, twenty-eight of which are wrong. You tighten the filters. It goes quiet, and three weeks later you find out through a friend that the role you wanted was open the whole time and never matched your terms.

Both outcomes are the same bug. A keyword alert is a string-matching query dressed up as a recommendation, and string matching has exactly two ways to be wrong.

Failure one: the words match, the job doesn't

"Senior" appears in a job description that also mentions reporting to a senior engineer. "Java" appears in a JavaScript posting. A Bangalore filter catches a Bangalore-based staffing consultancy advertising a role in Ohio. A "product manager" alert returns "product marketing manager", which is a different job that happens to share two thirds of its title.

None of that is a malfunction. The filter was asked whether some tokens are present, and it answered correctly. The question was wrong.

The costly version isn't the obviously-wrong result you skip in half a second. It's the plausible one. The posting that reads as a fit until paragraph six, where it turns out to want ten years, or on-site presence in a city you can't move to, or a stack you deliberately left behind. You spent four minutes finding that out, and you'll spend it again tomorrow on the same job reposted by a different consultancy.

Failure two: the job matches, the words don't

The other direction is quieter and worse, because you never learn it happened.

Titles are not standardised and never will be. The same work is advertised as Backend Engineer, Software Engineer II, Platform Engineer, Member of Technical Staff, SDE-2, and occasionally something a founder invented on a Tuesday. Filter for the three you thought of and you've excluded the others by construction.

Then there's the index problem, which sits underneath all of this: an alert can only fire on postings inside the platform it runs on. If a company opens a role on their own applicant tracking system, tells their network, and never buys a listing anywhere, no alert on any board can mention it. It isn't ranked low. It is absent. That gap is bigger than most people expect.

Why tightening filters can't fix it

The two failures pull in opposite directions. Broaden your terms and failure one gets worse. Narrow them and failure two gets worse. There is no setting that fixes both, because both come from the same root cause: the filter is matching tokens when the thing you care about is meaning. Adding more tokens changes where you sit on the trade-off; it doesn't remove the trade-off.

Which is why the honest answer to "how do I get better job alerts?" was, for years, "you don't. You read more listings yourself".

What actually breaks the trade-off

Something has to read the description. Not the title, not the tags: the text, where the real requirements and the quiet dealbreakers live. That's now cheap enough to do at scale, which is the only reason this problem is newly solvable rather than newly noticed.

Three things have to be true for it to work:

Hard rules stay hard. Geography, experience bounds, blocklists. These should be enforced as plain logic before any model is involved. They're not judgment calls, and a language model asked to weigh them will sometimes decide your "must be remote" is a preference. Ours are applied first, in code.

Judgment gets a threshold. Reading everything is only useful if most of it is then thrown away. An alert that reads well and still forwards forty results has moved the sorting problem back onto you and called it AI. We send only 7-and-above out of ten, with a daily ceiling, and the scale has to be anchored or everything drifts to a 6.

The reasoning is visible. A score you can't interrogate is a number you have to trust, and it will be wrong sometimes, job ads lie by omission, and a model reading one inherits that. Every alert we send carries why it scored what it scored, plus red flags, so overruling it takes five seconds.

The part that isn't about matching at all

One thing no scoring engine fixes: if the source list is one aggregator, better matching just means a cleaner view of the same partial index. Coverage and matching are separate problems, and most tools that solve the second quietly ignore the first.

That's why we spend most of our engineering on sources: 1000+ company ATS feeds polled directly, plus startup and remote boards, Indian aggregators, and targeted search for roles that live on a form and are indexed nowhere. The full list is public, including where it's thin.