Slide 1 of 3 · How matching works

There are five levels of matching. Most products stop at two.

Before writing any code, I read the research - everything from the simplest possible approach to what LinkedIn, Indeed and academic labs actually run in production. Here's the whole ladder, in plain English.

Level 1Word matching

Does the CV contain the same words as the job ad?

Breaks immediately. A graduate CV scores highly for a Staff Engineer role, simply because both of them say "React".

Level 2Meaning matching

The computer learns that "React" and "front-end" mean similar things.

Better, but still not enough. It can't hold several rules at once (remote and senior and above £150k), and it never stops to ask whether you'd actually get the job.

Level 3Score each thing

Skills, level, pay, location and direction are each scored separately, then combined.V1 is here

This is where you can finally see what's going on. You can see exactly why a job ranked where it did, change one weight, and test whether the results actually got better.

Level 4Both sides

It doesn't just ask "would you want this job?" - it also asks "would they want you back?"

This is the one candidates would thank you for. It tells you your real odds. No product on the market tells a candidate "you'd love this one, but you probably won't get it, and here's where your evidence is thin".

Level 5The whole market

Everyone's shortlist is decided together, so the same great job isn't sent to all 200 people.

LinkedIn runs this in production. If you send the same great job to everybody, most of them get rejected, and fewer people end up hired overall.

V1 builds level 3 properly, because it's the highest level you can prove works without real user outcomes. Levels 4 and 5 are the roadmap - and here's the interesting bit: level 5 is actually cheaper at a curated catalogue of 10,000 jobs than it is at LinkedIn's scale.

Slide 2 of 3 · What the research says

Five findings that changed what I built.

Drawn from published field experiments in real hiring, production engineering write-ups, and peer-reviewed retrieval research.

Stated preferences

2–3×

People don't actually want what they say they want - stated preferences overstate reality by two to three times.

Caution

Going wider

More interviews

Showing people jobs outside the criteria they asked for actually got them more interviews, not fewer.

Opportunity

Many rules at once

1 → 6

A single score can't hold many rules at once, so you ask each question separately and then add the answers up.

Built in V1

Bias in plain text

85% vs 11%

If you read a CV as raw text, you copy human bias straight into the system. Researchers changed only the name and the ranking changed.

Risk

Measuring success

Clicks mislead

If you optimise for clicks, matching actually gets worse - unhappy people click around more, not less.

Caution

The last one is the trap most teams fall into. Clicks are the easiest thing to measure, but optimising for them takes you in the wrong direction - what you really want to measure is interviews. Indeed published this about their own system: a model tuned for applications "might negatively correlate with relevance or hires."

Slide 3 of 3 · Judgement

The research also told me what not to build.

Every technique in the right-hand column is something I read up on, costed and decided against - and I've written down exactly why. To be honest, figuring out what not to build turned out to be more useful than figuring out what to build.

Chose

Small things I can prove work

  • Check every job exactly - no clever shortcut At 10,000 jobs this takes milliseconds and is perfectly accurate. The clever index would actually be less accurate here.
  • Six separate scores instead of one Each one can be explained, tested and tuned on its own.
  • Explanations that quote the evidence Every explanation has to quote the actual line in your CV and the actual line in the job ad. If it can't point at the evidence, it can't say it - which means it can't make things up.
  • A test set that proves it works A set of known-good answers, scored automatically on every change - so I can tell whether the matching got better or worse instead of guessing.
  • Say "nothing matches" when nothing matches If you pad the shortlist with near-misses, the whole shortlist stops being trustworthy. A short honest list is worth more.

Rejected

Impressive techniques that don't fit this problem

  • AI graph networks over candidates and jobs LinkedIn's own published result: about 1% improvement. And it needs data nobody outside LinkedIn has.
  • State-of-the-art retrieval machinery It's designed for tens of millions of documents. At 10,000, it adds complexity and buys you nothing.
  • Training a custom matching model There's nothing to train on yet, so the system collects the right data now and can learn later.
  • A separate specialist database One boring database does the job until millions of jobs. Two databases means two things to keep in sync.
  • Asking the AI to justify its own scores It will always produce a convincing reason, whether or not it's the real one.

There's a pattern I keep coming back to here: use AI where language is genuinely the problem, and ordinary code everywhere else. This is because a silent mistake in ordinary logic quietly compounds - and I want those parts to be boring and correct.