Templates

Technical interview scorecard template for software engineers

A scorecard every interviewer fills in the same way: anchored ratings for each competency, written evidence, a level call and a hire decision rule.

By the Ryz Labs team · Updated October 2026

A technical interview scorecard is a form each interviewer completes right after their interview: one rating per competency on an anchored scale, the evidence behind each rating, a level estimate and a hire or no-hire call. It works when the anchors describe observable behavior, every rating has written evidence, and interviewers submit before the debrief so they cannot anchor on each other. The template below is built for software engineers and adapts to backend, frontend, data and AI roles by swapping competencies.

Technical interview scorecard template

1. Scorecard header

Field	Value
Candidate	[Name]
Role and target level	[Senior backend engineer, L5]
Interview type	[Coding / System design / Domain deep dive / Collaboration]
Interviewer	[Name]
Date and length	[YYYY-MM-DD, 60 min]
Problem or topic used	[Exact prompt, so the debrief can compare like with like]

2. Competencies and anchored ratings (1-4)

Competency	1: Strong no	2: Lean no	3: Lean yes	4: Strong yes	Rating	Evidence (quote or describe what happened)
Problem solving	Could not break the problem down even with hints	Reached a solution with significant guidance	Structured the problem and reached a working approach with light hints	Explored trade-offs unprompted and chose the simplest approach that works	[1-4]	[Evidence]
Code quality	Code does not run or is hard to follow	Works but with unclear names and no edge cases	Clean, readable, handles main edge cases	Production-ready: tested, readable, edge cases and failure modes covered	[1-4]	[Evidence]
Debugging	Guessed at causes without a method	Found the bug slowly with hints	Used logs, tests or a debugger systematically	Isolated the root cause quickly and explained how to prevent it	[1-4]	[Evidence]
System design (mid-level and above)	No coherent design	Design works for the happy path only	Sound design with reasonable trade-offs explained	Designed for scale, failure and operability; named what they would measure	[1-4]	[Evidence]
Domain or stack depth	Surface knowledge only	Knows the tools, not the internals	Has used the stack in production and knows its pitfalls	Can explain internals and has fixed hard production issues in it	[1-4]	[Evidence]
Communication	Hard to follow; did not explain decisions	Explained when asked	Explained reasoning clearly while working	Adjusted to the audience and made the interviewer's job easy	[1-4]	[Evidence]
Collaboration and ownership	Blamed others or avoided responsibility in examples	Did assigned work only	Took ownership of outcomes in their examples	Raised the level of the team: reviews, mentoring, unblocking others	[1-4]	[Evidence]

3. Level call and decision

Field	Value
Level evidence	[Below target / At target / Above target, with one sentence why]
Overall recommendation	[Strong no / No / Yes / Strong yes]
Top strength	[One sentence]
Top concern	[One sentence]
Questions for the next interviewer	[What to probe]
Submitted before debrief	[Yes / No]

Use this template

How to use this interview scorecard

Pick the four to six competencies that matter for this role and delete the rest. A frontend role might swap system design for UI architecture and accessibility; an AI role adds evaluation design.
Rewrite the anchors in your own words for the target level before the first interview. A "4" for a mid-level engineer is not a "4" for a staff engineer.
Assign each competency to one interview in the loop so no two interviewers test the same thing and nothing is skipped.
During the interview, write down what the candidate said and did. Ratings come after, from the notes, not from memory.
Submit the scorecard before the debrief. Hiring tools can hide other scores until you submit; if yours cannot, ask interviewers not to discuss the candidate first.
In the debrief, discuss evidence, not adjectives. Use a written rule, such as no hire with any 1 on a core competency, and record why if you override it.

Example: a filled-in competency row

Competency	Rating	Evidence
Debugging	3: Lean yes	Given a failing pagination endpoint, added a test that reproduced the off-by-one error within ten minutes, then read the query and fixed the offset. Did not check for the same pattern in the two sibling endpoints until asked.

The evidence explains both the rating and why it is not a 4. Another interviewer can read it and reach the same score.

Common scorecard mistakes

Anchors that describe feelings. "Seemed smart" and "good culture fit" cannot be calibrated. Describe what the candidate did.
A 1-5 scale with a safe middle. A 3 out of 5 lets interviewers avoid a decision. A 1-4 scale forces a lean.
Ratings without evidence. If the evidence box is empty, the rating does not count in the debrief.
Testing the same thing twice. Two coding rounds on algorithms tell you little more than one. Map each competency to one interview.
Debrief before submission. The first opinion in the room becomes the decision. Collect written scores first.
One scorecard for every level. Calibrate anchors to the level you are hiring, or senior candidates will look average and junior candidates will look weak.

Scorecards for AI and data roles

For AI engineers, add competencies for retrieval design and evaluation: can the candidate build an eval set from real tasks and use it to choose between two prompts or models? For data engineers, add data modeling and pipeline reliability. Our AI engineer interview questions, data engineer interview questions and Python interview questions give you prompts that map to these rows.

Want candidates who already passed a scorecard like this?

Every Ryz engineer goes through structured technical interviews and recruiter review before you meet them, and only the top 1% of the tens of thousands of engineers we interview make it. You then interview the shortlist with your own scorecard. Ryz engineers work on your team, reporting to your leads, on US business hours. See our vetting process, or talk to us to scope your team.

FAQ

What is an interview scorecard?

An interview scorecard is a structured form an interviewer completes after an interview. It lists the competencies the interview tested, a rating for each on a defined scale, the evidence behind each rating and an overall recommendation. It makes interviews comparable across candidates and interviewers.

Should a technical interview scorecard use a 1-4 or 1-5 scale?

A 1-4 scale works better for hiring decisions because it has no neutral midpoint, so every rating leans yes or no. If your hiring tool requires 1-5, define 3 as "meets the bar with a specific concern" and require the concern in the evidence box.

Which competencies should a software engineer scorecard include?

Most loops cover problem solving, code quality, debugging, system design for mid-level and above, stack depth, communication and ownership. Choose four to six for a given role and assign each to exactly one interview in the loop.

When should interviewers fill in the scorecard?

Immediately after the interview and before any discussion of the candidate. Notes fade within hours, and scores written after hearing a colleague's opinion are less independent.

How do you calibrate interviewers on a scorecard?

Have new interviewers shadow two or three interviews and score them independently, then compare their scores with the lead interviewer's and discuss differences. Review score distributions per interviewer every quarter to spot anyone who rates far above or below the rest.

Questions we didn't answer? Email info@ryzlabs.com.