QA Engineer Interview Questions: What to Ask and What a Good Answer Contains
Good QA engineers think about how a system fails before it does, and know that the goal is a product that works, not a test suite that is large. These questions look for that mindset, plus enough technical depth to automate what should be automated.
- Ask about work the candidate owned, not opinions: every question below asks for a system, a deal, a campaign or a decision that actually happened, with what they did and what came of it.
- Score each answer against the note beside it. The notes describe observable things a strong qa engineer answer contains, so two interviewers write down the same evidence and reach the same score.
- Use the scorecard: bug-finding method; automation judgement; flaky-test discipline, and two more. Five criteria, scored 1 to 4, with a sentence of evidence each.
- Ask five questions well rather than eight in a rush. The first one, about something the candidate owned end to end, sets the tone: specifics, not generalities.
- Watch for the red flags listed below, which are patterns rather than single answers: measures their work in number of test cases, for one.
The questions
1. Tell me about the most important bug you found before release. How did you find it, and why had nobody else?
What a strong answer contains: A specific bug with real consequences, a method that found it (an edge case, a state combination, a load pattern), and an understanding of why the developers' own testing missed it.
2. How do you decide what to automate and what to test by hand?
What a strong answer contains: Automates the stable, repeated, high-value paths; explores by hand where the product is new or the risk is in judgement (usability, visual). Has deleted flaky tests and can say why.
3. A test fails intermittently. What do you do?
What a strong answer contains: Quarantines it, investigates the cause (timing, shared state, environment, a real race), fixes the cause or deletes the test; does not add a retry and move on. Flaky tests are the interview's honesty check.
4. Walk me through how you would test a feature that lets a customer partially refund an order.
What a strong answer contains: Boundaries (zero, full, over, twice), currency and rounding, concurrent refunds, permissions, the audit trail, and what the customer sees. Asks what the rules are before listing tests.
5. How do you work with developers who see QA as a gate?
What a strong answer contains: Gets involved at the design stage, pairs on tests, reports bugs with reproduction steps and without judgement, and has turned a sceptical developer around. Look for partnership.
6. What does your test pyramid look like on your current project, and is it right?
What a strong answer contains: Knows the proportions, has an opinion about where they are wrong, and can name the trade-off (end-to-end coverage against speed and flakiness).
7. How do you test something you cannot fully control, like a third-party payment provider?
What a strong answer contains: Sandbox environments, contract tests, recorded responses for the fast path, a small number of real calls, and monitoring in production as the last line.
8. Tell me about a release you should have blocked and did not.
What a strong answer contains: Owns it, names the pressure, and has a rule now. Anyone who has never faced this has not been in the room when releases are decided.
Scorecard
Score each 1 to 4 with one line of evidence. A total is less useful than a pattern.
- Bug-finding method: knows why the bug existed and why others missed it
- Automation judgement: automates the right things and deletes the wrong ones
- Flaky-test discipline: finds causes, never adds retries
- Test design: boundaries, concurrency, permissions, from the rules outward
- Partnership with developers: early involvement, blameless reports
Red flags
- Measures their work in number of test cases
- Fixes flaky tests with retries
- Test design starts from the UI instead of the rules
- Has never blocked or regretted a release
How to run the interview
The refund question is worth twenty minutes. Give the rules a sentence at a time as the candidate asks for them, and watch whether they ask. Strong testers build the test list from the invariants; weak ones build it from the screens.
The flaky-test question is short and decisive. Retrying a flaky test is the QA equivalent of catching an exception and doing nothing, and the candidates who would do it will do it to your suite.
Ask about the blocked release last. It is a question about courage and about whose job quality is, and a candidate who has an honest story is one who will speak up at your company when it matters.
Frequently asked questions
Do we need a QA engineer who can code?
For automation, yes: enough to write and maintain tests in your stack and to read the code under test. For exploratory testing the mindset matters more. Decide which you are hiring for.
Should developers write their own tests instead?
They should write most of them. A QA engineer's value is the tests developers do not think of, the exploratory work, the test strategy, and the release judgement. Hire for that, not for writing the unit tests.
How do we assess someone from manual-only testing?
The refund and flaky-test questions do not require automation experience to answer well. If the role needs automation, set a small exercise in your language and see how they approach it, not whether they finish.
Related guides
Screening qa engineer CVs this week?
Paste the job description into WadeCV, check the rubric it drafts, and upload the CVs. Each one is read against the rubric and scored with an explanation. Ten screenings are free; there is no subscription.
Screen your first CVs free