How HireQwik Matches Resumes to a Job Description

A recruiter posts a JD for an Operations Manager role at 6 p.m. on a Tuesday. By the time she checks her laptop the next morning, 40 resumes have come in overnight through the connected sheet, and they’re already sitting in a ranked order on the Needs Review tab — not a pile she has to sort herself, a list. Somewhere between “resume arrives” and “resume has a rank,” HireQwik’s AI resume matching engine did something that looks simple from the outside and is actually a three-layer decision, each layer picking up where the one before it runs out of signal.

This post is about that matching mechanism specifically — not the scoring logic in isolation, which we’ve covered elsewhere, but how a resume and a job description actually become one ranked list a recruiter can act on.

Matching is a ranking problem wearing a scoring costume

It’s easy to think of AI resume matching as “the model reads a resume and gives it a grade.” That’s not quite what’s happening. The grade is a means to an end; the end is a rank. Forty resumes against one JD isn’t forty independent grading exercises — it’s one ranking exercise that happens to produce forty numbers along the way. The distinction matters because a matching system optimized purely for grading accuracy can still produce a useless rank if its scores don’t spread out enough to separate real differences between candidates, which is exactly the failure mode behind score compression.

The three layers, in the order they run

HireQwik checks for the best available signal first and only falls back when that signal is missing.

Layer one: the JD’s own structured rubric, if one exists. When a recruiter has set up a per-JD scoring rubric — knockout criteria, scoring dimensions, anchors for what a strong versus weak answer looks like on each — the resume gets scored against those specific dimensions first. This is the highest-signal path because the rubric already encodes what “good” means for this exact role, not a generic approximation of it.

Layer two: relevance-aware scoring, when no rubric exists. Most JDs don’t have a hand-built rubric attached, especially early in a campaign before anyone’s had time to configure one. For those, a relevance-aware scorer takes over, and its whole job is to stop treating tenure and credentials as proxies for fit — a resume gets credit for what it can show is relevant to this specific role, not for how many years or which degree sit at the top of the page. Nothing relevant on the page means nothing to score, and the profile is capped low regardless of length.

Layer three: a relevance-gated keyword and experience matcher, as the last resort. If neither of the first two layers has enough to work with, a narrower fallback checks for keyword and experience overlap, still gated by relevance rather than raw counting. This layer exists so a candidate never goes completely unscored — it’s deliberately the least sophisticated of the three, and it’s the one HireQwik’s product team spends the least time tuning, because the goal is always to get more roles onto layer one or two, not to make layer three better at being a fallback.

Why the hierarchy runs in that order, not the reverse

You could imagine an engine that always runs the most detailed method available and averages it with the others. HireQwik doesn’t, because averaging a high-signal method with a low-signal one degrades the high-signal method’s output rather than improving it — a precise rubric-based score diluted by a generic keyword score is a worse number than the rubric score alone. The hierarchy exists specifically to avoid that dilution: each layer only runs when the one above it has nothing to say, not as a second opinion on top of it.

What actually produces the rank

Once a resume clears whichever layer scored it, that score doesn’t sit in isolation — it’s placed against every other resume scored for the same JD, and that ordering is what shows up as the Score/Decision filter bands on the Needs Review tab: Strong Go at 90–100%, Go at 75–89%, Maybe at 60–74%, Reject at 0–59%. A recruiter filtering to Strong Go isn’t asking “who scored well” in the abstract. She’s asking “who’s at the top of this specific JD’s ranked list,” which is a subtly different question — a resume-match score only ever means something relative to the one JD it was computed against, never as a portable rating of the candidate. Move the exact same resume onto a different requisition with a different rubric behind it, and the rank it lands at can shift considerably, because the ordering was never a judgment on the person — it was always a judgment on the fit between that person and that one posting.

A worked example: three resumes, one JD

Take the Operations Manager JD from the opening. Say it has a structured rubric already configured — layer one runs for every resume against it. Candidate A has six years managing a warehouse floor and lists specific inventory systems the JD names directly; she scores 91% and lands Strong Go. Candidate B has four years in retail operations, adjacent but not identical, with partial overlap on the systems named; he scores 78% and lands Go. Candidate C has a general business degree and two internships in unrelated functions; nothing in her resume maps to the rubric’s dimensions, so she scores 34% and lands in Reject. None of these three scores were computed by comparing the candidates to each other directly — each one was scored independently against the same rubric, and the rank simply falls out of where those three independent scores land relative to the JD’s own thresholds. That’s a meaningful distinction: the system isn’t picking a “best of three,” it’s measuring distance from a fixed target three times.

Where a low match score doesn’t mean “off-topic”

Layer one and layer two both score relevance to the specific role, but relevance isn’t the only reason a resume can score low. A candidate with no work history to point to yet scores differently than one who has years of the wrong kind of experience, even if both land in a similar band — the first is a thin-signal case, the second is a genuine mismatch, and recruiters reading only the final percentage can lose that distinction unless they open the score breakdown behind it.

The honest limit of any matching system

No three-layer hierarchy eliminates every edge case. A structured screener-build document written for a broad, generalist role gives the matching engine more surface area to score against than one written for a narrow, unusually specific role — which is exactly why niche technical roles put more pressure on layer two and layer three than a generalist role does. And any layer can, on rare occasions, undersell a candidate whose background is genuinely relevant but described in a way none of the three layers were built to recognize. That’s a known limitation, not a hidden one, and it’s the reason a low match score triggers a recruiter’s judgment call rather than an automatic reject in every configuration.

This isn’t just an internal design choice we happen to prefer. A 2026 study measuring algorithmic friction in automated resume screening found that keyword-overlap systems disagree with human reviewers far more often than semantic, relevance-based systems do, largely because keyword matching can’t distinguish a candidate who described an equivalent skill in different words from one who genuinely doesn’t have it. Putting relevance-aware scoring ahead of keyword matching in the hierarchy, rather than averaging the two together, is a direct response to that exact gap.

What this means for how you read a match score

The practical takeaway for a recruiter isn’t “trust the top of the list blindly.” It’s narrower: know which layer scored a given resume before deciding how much weight to put on the number. A 91% from a fully configured per-JD rubric and a 91% from the keyword-fallback layer are not the same claim, even though they render as the same percentage on the Needs Review tab. If a role’s rubric isn’t configured yet, that’s worth fixing before a drive opens, not after — setting one up during initial campaign setup takes a fraction of the time it saves in re-reading fallback-layer scores with extra suspicion later.

See what the ranked list looks like on a real JD you’re hiring against at app.hireqwik.in/dashboard/hr.