QA Engineer interview scorecard template
A structured scorecard for interviewing a QA 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 QA Engineer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Test design and coverage reasoning Whether they can decide what is worth testing, since exhaustive testing is impossible and coverage choices are the core judgment of the role. | 20% | Writes cases that mirror the acceptance criteria line by line, with no boundary, negative or state-transition cases beyond what the ticket stated. | Explains how they chose cases for a specific feature: the boundaries they picked, the combinations they deliberately skipped, and the risk that justified skipping them. |
| Defect investigation and reporting Whether a developer can act on their report without a second conversation, which determines how much QA time converts into fixed defects. | 18% | Files reports saying what looked wrong, without steps, environment or data, and reopens tickets that were closed as not reproducible. | Narrows a defect to minimal reproduction steps, states what differs between passing and failing runs, and attaches the log or request that pins the failure. |
| Test automation engineering Whether the automated suite stays trustworthy over time, because a flaky suite that everyone ignores costs more than having no suite at all. | 18% | Automates whatever is easiest to script, and treats intermittent failures as expected noise to be re-run rather than as a defect to diagnose. | Describes a flaky test they fixed at the cause — a timing assumption, shared state between runs — and how suite reliability changed afterward. |
| Release risk judgment Whether they can say what is safe to ship and what is not, since a QA hire is often the last informed voice before a release goes out. | 16% | Reports pass and fail counts and escalates every open defect equally, without distinguishing a cosmetic issue from a data-loss path. | Recalls a release they recommended shipping with a known defect, the exposure they estimated, and the mitigation agreed with product before launch. |
| Environments, test data and tooling Whether they can reach a realistic test setup on their own, which is where most of the wasted time in QA work tends to accumulate. | 14% | Is blocked whenever a test environment is unavailable, and cannot describe how test data was created or refreshed in their last role. | Describes a test data or environment problem they solved — seeded fixtures, a stubbed dependency — and what it unblocked for the rest of the team. |
| Working with developers and product Whether quality issues actually get resolved rather than escalated, since QA carries influence but rarely authority over what ships. | 14% | Frames past friction as developers ignoring their reports, with no account of what they changed in how the concern was raised. | Describes getting a quality concern acted on: who they raised it with, what evidence made the case, and the trade-off they accepted in return. |
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.
- Take a feature you tested recently. How did you decide which cases to write, and which risks did you consciously accept leaving untested?
- Describe a defect that reached production despite your testing. How did it get through, and what did you change afterward?
- Tell us about the flakiest test you have dealt with. What was the actual cause, and how did you confirm it was the cause?
- Describe a release you were uncomfortable with. What was the risk, who did you raise it with, and what was decided in the end?
- Walk us through the last bug report you filed. What was in it, and how many rounds did it take before the developer could reproduce it?
Red flags
- Defines the job as executing test cases written by someone else, with no input into coverage.
- Cannot name a defect that escaped to production, or what was learned from it.
- Re-runs failing automated tests until they pass and calls the build green.
- Describes quality as a gate they enforce rather than a risk they help the team weigh.
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 QA Engineer →
Frequently asked questions
What is the difference between a QA engineer and an SDET when hiring?
The titles overlap differently at every company. Decide what fraction of the role is exploratory testing and risk judgment versus building and maintaining automation infrastructure, then weight the interview to match. Hiring an automation-heavy profile into a mostly exploratory role is a common and expensive mismatch.
How do I test QA skills in an interview without a take-home?
Give them a small live feature or a written spec and ask what they would test first, what they would leave out, and why. Then read a real bug report they wrote and judge it on reproducibility alone. Both fit inside thirty minutes.
What should a QA engineer scorecard weight most?
Coverage reasoning and defect report quality usually carry the most weight, because they determine whether the rest of the work has value at all. Set the weights before interviewing and record the evidence behind each score. Verdict applies the same approach to CV screening, tying every score to a cited line from the document.
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.