Back to Journal

From Resume Matching to Trustworthy Signals

How I designed a resume screener that scores with explainability first, not black-box ranking. A practical walkthrough of the key design decisions that make the difference between a useful screening tool and a black-box that creates more work.

The problem with black-box resume ranking

Most resume screening tools are black boxes: you dump resumes in, get a ranked list out, and have no idea why one resume scored higher than another. That opacity creates more problems than it solves — for the hiring team, the candidates, and anyone who has to defend a hiring decision two months later.

I built a resume screener that works differently. It scores resumes against job descriptions, but every score comes with an explanation. Keyword matches. Skill gaps. Experience depth signals. The person reviewing the output can see exactly what drove each score and can override any part of it.

Start with what you're optimising for

Before writing a line of code, I asked: what does "good" actually mean here?

A screening tool is a filter between raw applicant volume and focused human review. Its job isn't to pick the best candidate — it's to reduce the work the hiring team has to do without filtering out anyone who deserves a closer look.

That framing changes everything. The goal isn't to maximise precision. It's to maximise the ratio of signal to noise while keeping false negatives low.

The scoring model

I used a simple weighted signal approach:

  • Keyword presence (40%): Does the resume mention the core skills from the job description? Exact matches count more than fuzzy ones, but fuzzy matches are still counted.
  • Skill gap analysis (30%): For each required skill, is it present? Is it a primary skill or a passing mention? This is where experience depth shows up.
  • Context signals (30%): Years of experience, role level, domain relevance. These are harder to fake and harder to accidentally inflate.

Each signal maps to a clear output. The UI shows which keywords matched, which skills are present or absent, and how the experience level score was derived.

Why explainability is the actual feature

When a recruiter gets a low score and asks "why," the tool should answer in seconds, not require a developer to pull logs and trace through the model.

When a hiring manager wants to know if someone who "passed" the screener but got a surprisingly low score is actually worth a second look, they can open the breakdown and decide on the actual content.

When someone challenges a screening decision, the explanation is already there — no post-hoc rationalisation.

What I'd do differently

The biggest lesson: the job description parser is the most important component and I underestimated it. Most job descriptions are written casually and contain noise (lists of every possible skill, aspirational requirements that don't match the day-to-day). Parsing that signal from noise before scoring starts is where most of the accuracy gains live.

Next iteration: a job description quality scorer alongside the resume scorer — so the hiring team can improve the input before they get frustrated by the output.