How to Build a Recruiting Scorecard From Any Job Description
A generic scorecard template doesn't evaluate anyone against what the job actually needs. Here's how to build one properly, from the JD itself.
The Candit Team, 2026-08-18
Most interview scorecards start life as a generic template — five or six broad categories like "communication," "technical skills," "culture fit" — copied from the last role and reused for the next one with barely any changes. That's how you end up rating a Customer Success Manager and a Senior Backend Engineer against nearly the same criteria, which isn't really evaluating either of them against what the job actually needs.
A better scorecard starts from the job description itself. Here's how to build one properly, and what to do with it once you have it.
Why a generic template doesn't work
A job description is, underneath the boilerplate, a specific list of things a person needs to be able to do. A generic scorecard throws most of that away in favor of categories broad enough to apply to any role — which means it applies well to none of them. Two real problems follow from this:
- Interviewers end up guessing what "strong" means for a category vague enough to mean almost anything, so the same answer gets rated differently depending on who's asking.
- Nothing on the scorecard maps back to a specific line in the JD, so there's no way to check later whether the evaluation actually covered what the client or hiring manager cared about.
Step one: pull real competencies out of the JD, not a template
Read the job description the way a good interviewer would, looking for the specific, checkable things it's actually asking for — not the generic language padding it out. A JD for a backend engineering role might genuinely be asking for distributed systems design, API versioning judgment, and incident response experience. A JD for a customer success role is asking for something else entirely. The scorecard should look different for each, because the jobs are different.
A reasonable competency list has somewhere between four and seven items — enough to cover what actually matters, not so many that every interview turns into a checklist exercise nobody has time to fill in properly.
Step two: separate hard requirements from everything else
Almost every JD has a handful of non-negotiables buried in it — work authorization, a required certification, a specific number of years in a regulated function. These should never be folded into the same weighted score as everything else. A candidate who's excellent on every competency but fails a hard requirement shouldn't be able to average their way to a passing score; the requirement needs its own separate check, flagged on its own, regardless of how strong the rest of the interview was.
Step three: rate with evidence, not a gut number
A bare number — "3 out of 5 on communication" — is nearly useless three weeks later when you're trying to remember why. Every rating should carry the specific thing the candidate said that justifies it: a quote, a close paraphrase, the actual moment in the conversation. This does two things — it makes the rating defensible to a hiring manager who wasn't on the call, and it keeps the interviewer honest in the moment, because a rating with no evidence behind it is a much easier one to inflate without noticing.
Example: same shape, different content
| Role | Sample competency | What "met" looks like |
|---|---|---|
| Senior Backend Engineer | Distributed systems design | Discusses failure modes, consistency tradeoffs, and concrete design decisions from real systems they've built |
| Customer Success Manager | Escalation handling | Describes a specific difficult account, what they did, and the outcome — not a general philosophy |
| VP of Operations | Cross-functional influence | Gives a real example of aligning teams without direct authority over them |
Same structure — competency, evidence-backed rating — completely different content, because the roles are different. That's the whole point.
Doing this for every role without it becoming a full-time job
Building this by hand for every open role is the part that usually causes people to give up and go back to the generic template. The fix is doing it once, properly, at the start: pull the competencies and must-haves from the JD, agree them with the hiring manager, then score every candidate against the same list during the interview rather than reconstructing it from notes afterward.
That's the first thing we do when we take on a role for a client. At the Define step we turn the job description into what great looks like, the must-haves and an interview plan, and every candidate we vet is scored against it, with the evidence behind each rating in their interview pack.
We vet every candidate down to the interview before you meet them. Book a call.