Software Engineer interview scorecard template
A structured scorecard for interviewing a Software Engineer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The Software Engineer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| System design and decomposition Whether the candidate can break an ambiguous requirement into services, modules and interfaces, and defend the boundaries they chose against realistic alternatives. | 20% | Jumps to a framework or database choice before the requirements are clear; describes the design as it ended up without naming a single rejected alternative. | States the constraints first, sketches two or three viable structures, and explains which one was shipped and what had to be true for that choice to hold. |
| Code review judgment How the candidate raises and receives review feedback, which determines how much defect risk the team catches before code reaches production. | 18% | Frames review as approving or blocking; recalls comments about formatting and naming but no case where a review caught a real defect before release. | Gives examples of review comments that changed a design, separates blocking concerns from preferences, and describes changing their own position when shown data. |
| Debugging and root-cause analysis Whether the candidate isolates causes with evidence — logs, traces, bisects — instead of guessing, which drives how long production problems stay open. | 18% | Describes the fix but not how the cause was confirmed; attributes past incidents to flaky systems or other teams without a reproduction step. | Names the signal that narrowed the search, the hypothesis it ruled out, and how they proved the fix addressed the cause rather than the symptom. |
| Testing strategy Whether the candidate chooses test types deliberately by risk and cost, which determines if the suite catches regressions or only slows delivery down. | 15% | Reports coverage percentage as the goal; cannot name a bug the tests caught, or writes tests only when a reviewer asks for them. | Explains which layers get unit, integration or end-to-end tests and why, and cites a regression the suite caught before it reached users. |
| Scope and trade-off judgment under a deadline Whether the candidate can cut scope without hiding the cost, which determines how much unplanned rework the team absorbs after a release. | 15% | Reports that everything shipped on time with no compromises, or names shortcuts taken without saying who was told or what was written down. | Describes a specific cut, the risk it accepted, who agreed to it, and whether the follow-up work was tracked and actually completed. |
| Technical communication Whether the candidate can make a technical decision legible to people who did not write the code, which governs how well decisions survive team turnover. | 14% | Explains work only in implementation terms; when asked to restate it for a non-engineer, repeats the same jargon at a slower pace. | Adjusts depth to the listener, states the decision before the detail, and points to a written document or ADR that someone else later relied on. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Walk me through a production incident you personally diagnosed. What was the first signal, what did you rule out, and how did you confirm the root cause?
- Describe a design you shipped in the last two years where you chose between two real options. What made you pick one, and what would have changed your mind?
- Tell me about code of yours that was rejected in review. What was the objection, and what did the final version look like compared to your first?
- Point to something you wrote that another engineer had to maintain. How did you find out whether they could work with it without asking you?
- What is the last thing you removed from a release to hit a date? Who decided it, what was the risk, and what happened to the deferred work?
Red flags
- Cannot name a single technical decision they now consider wrong, across an entire career.
- Every past project is described as a success and every failure is attributed to management or another team.
- Describes every accomplishment in the plural and cannot isolate which parts of the system they wrote themselves.
- Names technologies and versions fluently but goes vague the moment the question moves to what broke and why.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a Software Engineer →
Frequently asked questions
What should an interview scorecard for a software engineer include?
Weighted competencies that match what the role actually does, behavioral anchors describing what a low and a high answer sound like, and one probe per competency that asks for past work rather than hypotheticals. Weights should add to 100 so scores are comparable across interviewers. Without anchors, two interviewers will use the same number to mean different things.
How many interview rounds does a software engineer hire need?
Most teams get what they need from two to four rounds: a technical conversation about past work, a practical exercise close to the real codebase, and a session on design and collaboration. Adding rounds past that usually adds calendar time rather than information. Decide which competency each round is responsible for before scheduling it.
How do you compare two software engineers who scored the same?
Go back to the evidence behind each score instead of re-arguing the totals. Compare the specific examples each candidate gave on the highest-weighted competencies, and check whether a score rests on something they personally did or something their team did. Verdict scores candidates on that kind of cited evidence, so the tie-break stays anchored to what was actually said.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.