QA interview questions that test bug reports and the nerve to hold a release
QA is a communication job wearing a technical costume. Finding a defect is often the easy part. The value is in a report someone can act on without a conversation, and in being willing to say a release isn't ready when everyone in the room wants it to be. Both are visible in an interview, and neither is visible in a testing certification.
What the job actually involves
A QA engineer designs and runs tests, explores software for the failures nobody specified, writes up defects, and gives an assessment of release readiness. In many teams they also own automated suites and the flakiness that comes with them.
The position is structurally awkward and that's the job. QA is the person telling people their work isn't finished, usually under deadline pressure, usually as the last step before something ships. Doing that in a way that gets acted on rather than resented is the actual skill.
The questions, and what a good answer sounds like
Ask these as written. Each one is paired with what a strong answer sounds like, so two people rating the same candidate reach the same conclusion for the same reason.
1. Walk me through a bug report you would write for something you can't reproduce reliably.
A good answer: States the frequency honestly, gives everything they do know — environment, steps attempted, what varied — and doesn't either bury it or overstate it. Intermittent defects are where reporting discipline shows.
2. It is release day and you think it shouldn't ship.
A good answer: States the risk in terms of user impact instead of defect count, gives the decision to whoever owns it, and doesn't fold under pressure. Strong answers accept that the call may go against them and say so plainly.
3. A developer says your bug isn't a bug.
A good answer: Goes back to expected behaviour and where it is defined, instead of escalating on authority. If the spec is ambiguous, says so. That's a real finding not a lost argument.
4. You have two days to test something that needs two weeks.
A good answer: Risk-based prioritisation with the untested areas stated explicitly. The critical half is telling people what wasn't tested. Silent partial coverage is how QA becomes theatre.
5. How do you decide what to automate?
A good answer: Stability, repetition and cost of failure, not everything. Strong answers mention the maintenance burden and flaky tests, which is the honest cost nobody puts in the business case.
6. A defect you raised was closed as won't fix and it later hit users.
A good answer: Documented it at the time, and doesn't spend the answer on vindication. What you want is someone who makes the risk visible and then accepts the decision.
7. How do you test something with no specification?
A good answer: Explores, builds a model of intended behaviour from the product and from users, and asks. Comfort with ambiguity is most of exploratory testing.
8. What is a bug you're proud of finding?
A good answer: Ideally something subtle found by thinking about the system rather than clicking through it. This is where genuine testing instinct shows and it is hard to fabricate.
A scorecard you can rate against
Rate every candidate 1 to 4 on each row, and write the rating down before you watch the next one. Ratings drift badly when they're relative to whoever you just saw.
| Criterion | What a 4 looks like |
|---|---|
| Report quality | Writes an actionable report for an intermittent defect. A 2 either buries or overstates it. |
| Holding a release | States risk in user impact and doesn't fold. A 2 defers to the room. |
| Disagreeing with developers | Returns to defined expected behaviour. A 2 escalates on authority or drops it. |
| Stating what wasn't tested | Names the untested areas explicitly. A 2 reports only what passed. |
| Automation judgement | Weighs maintenance cost and flakiness. A 2 would automate everything. |
How to run the screen
- QA is a better fit for a recorded round than most technical roles, because reporting and persuasion are the core skills and both are visible in speech.
- Pair it with a written bug report from a short scenario. The written artefact is the actual deliverable and speech doesn't test writing.
- Ask three or four questions, capped at two minutes. Concise risk communication is the job.
- Weight the release-day question heavily. A QA engineer who can't hold a position under deadline pressure provides confidence over assurance.
- Keep a practical exploratory exercise for the shortlist. Testing instinct shows in doing not describing.
Running this on a large applicant pool is where it gets expensive. VoxScreen sends these questions as a single link, transcribes and scores every answer against criteria you set, and hands back a ranked list. Free for 50 candidates a month, no card.
Common hiring mistakes for this role
- Interviewing on tools and certifications. Both are trainable and neither predicts whether a report is actionable.
- Hiring an agreeable QA. The whole value of the function is a person who will say no when it counts, which is uncomfortable at interview and correct in production.
- Not testing writing. Bug reports are written, read asynchronously by people under time pressure, and a spoken answer tests a different skill.
- Treating test case counts as output. Coverage of risk matters. Counts measure activity.
- Using a recorded round for exploratory ability. It shows how someone thinks about testing, not how they test — the practical exercise does that.
Common questions
What should I ask a QA engineer in an interview?
Ask how they would report a defect they can't reproduce reliably, what they do on release day when they think it shouldn't ship, what happens when a developer says their bug isn't a bug, and how they handle two days to test two weeks of work. Those cover reporting, nerve, disagreement and honest coverage.
Is a recorded interview suitable for QA hiring?
Better than for most technical roles. The core skills — communicating risk, writing an actionable defect, holding a position under deadline pressure — are largely communication skills, and they show in speech. Pair it with a written bug report, because the written artefact is the actual deliverable, and keep a practical exploratory exercise for the shortlist.
How do I tell a good bug report from a bad one?
A good one can be acted on without a conversation: environment, exact steps, expected versus actual, frequency stated honestly, and severity argued in terms of user impact over asserted. The intermittent-defect question surfaces this quickly, because that's where reporting discipline either exists or doesn't.
Should QA report to engineering?
That's an org design question not a hiring one, but it bears on the interview: if QA reports into the team whose work it assesses, the willingness to hold a release matters even more, because the structural pressure to fold is higher. Weight that question accordingly.