Structured Interview Rubric Template, with Examples
This structured interview rubric template shows how to write anchored levels for each skill, with two worked examples and a weighted scorecard to copy.
Interview panels often agree on what they are hiring for, then disagree about every candidate. One interviewer hears a confident answer, another hears a vague one, and the debrief becomes a contest of impressions. A rubric settles this before anyone is interviewed, by writing down what a weak, a solid and an excellent answer actually contain.
Here is how to build one, with two complete interview rubric examples, a blank template and the arithmetic for a weighted scorecard.
What a structured interview rubric is
A structured interview asks every candidate the same job-related questions and scores the answers against the same predefined standard. The rubric is that standard. For each skill, it sets the weight, the question that tests it, and what an answer at each level sounds like.
Structured interviews predict job performance about twice as well as unstructured ones (Sackett et al., 2022). But if each interviewer scores against a private idea of a good answer, you have a structured conversation with unstructured scoring. An interview scoring rubric closes that gap and leaves a record: when someone asks why a candidate scored a 2, the answer is on the page.
The anatomy of a rubric
Every skill in the rubric has four parts.
| Part | The question it answers | Example |
|---|---|---|
| Skill | What exactly are we measuring? | Diagnosing front-end performance problems |
| Weight | How much does it count toward the total? | 30% |
| Question | What will every candidate be asked? | "A page you own renders slowly after a data change..." |
| Anchored levels | What does an answer at each level contain? | Novice, Competent, Proficient, Expert |
The levels do the real work. A bare 1-to-5 scale leaves each interviewer to decide what a 3 means. A behaviorally anchored rating scale (BARS), a method Smith and Kendall introduced in 1963, attaches a description of observable behavior to each point, so a level means the same thing to every scorer. This guide uses four:
- Novice: knows the topic but has no workable approach.
- Competent: gives a correct, workable answer for the common case.
- Proficient: adds a method, the reasoning behind it, and a check that it worked.
- Expert: adds judgment, such as trade-offs, prevention, and knowing when the usual answer is wrong.
Setting the depth with Bloom's taxonomy
Not every role needs the same depth in a skill. The revised Bloom's taxonomy orders thinking from remember to understand, apply, analyze, evaluate and create. Pick the rung the role needs, write the Expert anchor there, and build the lower levels beneath it. Here is one skill, making slow database queries fast, written at two depths:
| Level | Junior analyst (depth: apply) | Senior data engineer (depth: evaluate) |
|---|---|---|
| Novice | Defines an index but can't say when one helps | Tunes queries by trial and error; can't say why a change worked |
| Competent | Explains why filtering on an unindexed column forces a full scan | Adds the right index and checks that the query plan uses it |
| Proficient | Adds a suitable index once shown the problem column | Finds the join or filter that dominates the plan's cost, and fixes that first |
| Expert | Finds the problem column in an unfamiliar query, indexes it, and confirms the speed-up | Weighs an index against a rewrite, cache or schema change, given write load and growth, and says what they'd measure |
The junior Expert anchor sits near the senior Competent one: depth moves the whole bar.
How to write anchors that work
A good anchor passes one test: two interviewers who hear the same answer would agree on whether it happened.
- Describe evidence, not adjectives: what the candidate said or did, not how it felt.
- Say what a weaker answer is missing, not just that it is worse.
- Make each level add something. If neighboring anchors differ only by an adjective, rewrite one.
- Describe the answer, not the person. Confidence, polish and credentials are not anchors.
| Weak anchor | Why it fails | Stronger anchor |
|---|---|---|
| Communicates well | An impression; scorers will disagree | Summarizes the trade-off in a sentence, then checks the listener followed |
| Strong technical knowledge | Says nothing about the answer | Names the likely causes and how to confirm each one |
| Lacks depth | Says "less," not what is absent | Proposes a fix but not how to tell whether it worked |
| Good culture fit | Undefined, so it invites similarity bias | Describes a specific disagreement, how it was resolved, and what changed after |
The method works for newer skills too, such as assessing AI fluency.
Two interview rubric examples
Both use real questions from Hyrr's demo interviews. The last column shows what each answer lacks compared with the level above.
Example 1: diagnosing front-end performance problems
"A page you own renders slowly after a data change. How do you find out why, and what are the usual causes you check first?"
It comes from our frontend engineer demo interview, where you can hear it asked. Weight: 30%. Depth: analyze, because a mid-level engineer should find the cause, not just list possibilities.
| Level | What you hear in the answer | What is missing |
|---|---|---|
| Novice | Jumps to a fix ("add memoization," "switch libraries") without measuring. Can't name a tool for finding the slow part. | Any method for locating the cause. |
| Competent | Reproduces the slowdown and measures it with the browser's performance panel or the framework's profiler. Names a common cause or two, such as needless re-renders. | A link from measurement to cause, and a re-check after the fix. |
| Proficient | Uses the profile to find what re-renders or blocks the main thread, and ties it to the data change. Checks the usual causes: new object or function props that defeat memoization, unstable list keys, state updates that re-render too much of the tree, expensive work during render, long unvirtualized lists, layout thrashing. Measures again after the fix. | Trade-offs, and a way to stop it recurring. |
| Expert | Everything in Proficient, plus weighs the fixes (memoization has its own cost; virtualizing a list affects in-page search and screen readers), separates data-processing time from render time, and proposes a guard: a performance budget, a regression test or real-user monitoring. | Nothing. This is the target. |
Example 2: guiding hiring managers toward objective assessment
"Imagine a hiring manager is consistently rejecting qualified candidates due to subjective reasons. How would you address this situation and guide them towards a more objective assessment?"
This one is from our senior recruiter demo interview. Weight: 25%. Depth: evaluate, because a senior recruiter should judge the situation and choose an approach, not recite a policy.
| Level | What you hear in the answer | What is missing |
|---|---|---|
| Novice | Escalates straight to HR, or accepts the manager's calls as final. Speaks in generalities ("I'd remind them to be fair"). | A conversation with the manager, and any evidence. |
| Competent | Raises it with the manager directly, asks for the specific reasons behind recent rejections, and suggests agreeing on the role's must-have criteria. | Evidence gathered beforehand, and a change to how future candidates are judged. |
| Proficient | Arrives with evidence: recent rejections, the reasons given, and how each candidate measured against the requirements. Names the pattern, such as "not polished" used against candidates who met every requirement. Proposes a scorecard agreed before the next interview, written feedback tied to it, and calibration on a few past candidates. | A way to tell whether it worked, and a plan if it doesn't. |
| Expert | Everything in Proficient, plus frames it around the manager's own goal, a successful hire, rather than blame. Recognizes when the stated reasons could track a protected characteristic and HR must be involved. Agrees on a measure to review, such as how many shortlisted candidates advance next month. | Nothing. This is the target. |
From rubric to interview scorecard
A scorecard puts every skill for the job on one page with its weight. Convert each level to points (Novice 1, Competent 2, Proficient 3, Expert 4), multiply by the weight, and add. A worked example for a mid-level frontend engineer:
| Skill | Weight | Level awarded | Points | Weighted points |
|---|---|---|---|---|
| Diagnosing front-end performance problems | 30% | Proficient | 3 | 0.90 |
| Writing correct, readable JavaScript | 30% | Competent | 2 | 0.60 |
| Building accessible interfaces | 20% | Expert | 4 | 0.80 |
| Explaining technical trade-offs to non-engineers | 20% | Proficient | 3 | 0.60 |
| Total | 100% | 2.90 of 4.00 |
The arithmetic: (0.30 × 3) + (0.30 × 2) + (0.20 × 4) + (0.20 × 3) = 0.90 + 0.60 + 0.80 + 0.60 = 2.90, which is 72.5% of the 4.00 maximum.
Set the pass bar before interviews start, with a floor for must-have skills: for example, "2.75 overall, and no must-have skill below Competent." The floor stops one strong skill from covering for a missing one.
The structured interview rubric template
Copy the first two tables into a doc or spreadsheet once per skill, and the scorecard once per candidate. Four to six skills is enough for most roles.
| Field | Your entry |
|---|---|
| Skill | |
| Weight (all skills sum to 100%) | |
| Depth (Bloom's level) | |
| Question | |
| Neutral follow-ups |
| Level | What you hear in the answer | What is missing |
|---|---|---|
| Novice (1) | ||
| Competent (2) | ||
| Proficient (3) | ||
| Expert (4) |
And a blank interview scorecard template:
| Skill | Weight | Level | Points | Weighted points | Evidence (quote or note) |
|---|---|---|---|---|---|
| Total | 100% |
How to score interview answers consistently
The rubric only works if everyone uses it the same way.
- Write it before the first applicant. Anchors written after meeting candidates tend to describe the ones you liked.
- Use the same guide for every candidate. Same questions, anchors and weights. Neutral follow-ups aimed at the same evidence are fine.
- Score against the anchors, not against the last candidate. Note the evidence beside each score: a quote, or a specific step the candidate described. A score without evidence is an opinion.
- Score independently, before any debrief. Discussing first tends to pull everyone toward the most senior or loudest voice.
- Calibrate on sample answers. Before the first real interview, have the panel score two or three sample answers. Where scores differ by more than one level, rewrite the anchor.
A shared, written standard is also one of the most practical steps toward fairer hiring; our guide to bias-free hiring covers the rest.
Common mistakes
- Too many skills. Ten skills at 10% each leaves too little interview time to score any of them well.
- Generic skills. "Communication" means different things in different jobs. Name the job's version.
- Rewarding length or fluency. A long, confident answer is not the same as a complete one.
- The halo effect. One strong answer lifts every other score. Score each skill on its own evidence.
- Moving the weights mid-process. If the job changed, write a new rubric rather than bending the old one toward a favorite.
- Treating the total as the decision. The score informs a human decision; it doesn't replace one.
How Hyrr does it
Hyrr runs the first interview round as a live AI interview. Every job has a scorecard of weighted skills, and each skill has a written BARS grading guide that defines what a Novice, Competent, Proficient and Expert answer looks like, at a depth the hiring team sets using Bloom's taxonomy. The guide is written before the first applicant, and the same guide is used for every candidate.
Resume screening runs on the same rubric and pass bar as the interview. Name, accent, age, appearance and location are excluded from scoring by design. Scores are recomputed in code, with a scoring trace and decision record: the rubric in force, the evidence quoted for each skill, and the arithmetic. Reports can be exported as PDF or Word. The scores inform the decision; your team makes it.
To hear a structured AI interview from the candidate's side, take a demo interview on the home page. Pricing is $6 per completed interview, with no seats, no platform fee and no annual minimum; the pricing page has the details.