A good QA engineer finds the bugs that matter before customers do, and helps the team ship faster instead of slower. These QA engineer interview questions test that: how candidates design tests, decide what to automate, handle flaky suites, and argue for quality when a release date is close. They work for manual testers, automation engineers and SDET roles, with notes where the expected depth changes. Hiring managers can choose 6 to 10. Candidates can read the "what good looks like" notes to see how answers are judged.
What a strong QA engineer interview checks
- Test design: boundary values, equivalence classes and negative cases chosen on purpose.
- Risk thinking: testing what could hurt users and the business most, first.
- Automation judgment: what to automate, at which layer, and how to keep it reliable.
- Bug communication: reports that developers can act on without a follow-up chat.
- Breadth: APIs, performance, accessibility, security basics and AI features.
- Influence: raising quality across the team instead of acting as the last gate.
QA engineer interview questions: testing fundamentals
1. Explain the test pyramid. When might the shape be different?
What good looks like: many fast unit tests at the bottom, fewer integration tests, and a small number of end-to-end tests at the top, because higher tests are slower and more brittle. Strong candidates note that some teams put more weight on integration tests, especially for frontends and services with thin logic, and that the goal is fast, trustworthy feedback, not a perfect shape.
2. A field accepts ages 18 to 65. Which values would you test, and why?
What good looks like: boundary values 17, 18, 65 and 66, a value in the middle as a valid class, plus invalid inputs: empty, negative, decimals, letters, very long strings and leading spaces. They explain equivalence partitioning (one test per class of input) and why bugs cluster at boundaries.
3. What's the difference between severity and priority? Give an example where they differ.
What good looks like: severity is the technical impact, priority is how soon it should be fixed. A misspelled company name on the homepage is low severity but high priority. A crash in a rarely used admin export is high severity but may wait a sprint if few people use it.
4. What makes a bug report good?
What good looks like: a clear title, exact steps to reproduce, expected versus actual result, environment and build, how often it happens, and evidence such as a screenshot, video or logs. The best reports narrow the problem to the smallest reproduction.
Red flag: "It doesn't work" with no steps.
5. How do you run an exploratory testing session?
What good looks like: a charter that names the area and the risk to explore, a time box (often 60 to 90 minutes), notes as they go, and a short debrief with bugs, questions and ideas for new automated tests. Exploratory testing complements scripted tests rather than replacing them.
Test design scenarios
6. How would you test a login page?
What good looks like: they ask about users and requirements first, then cover valid and invalid credentials, account lockout and rate limiting, error messages that don't reveal which field was wrong, password manager support, multi-factor flows, session expiry, keyboard and screen reader access, and behavior on slow networks.
7. How would you test discount codes at checkout?
What good looks like: valid, expired and not-yet-active codes, case sensitivity, stacking rules, minimum order values, rounding and currencies, and refunds of discounted orders. Strong candidates think of concurrency: two people redeeming a single-use code at the same moment. They also check expiry at time zone edges.
8. Release is in two days and 40 test scenarios haven't run. What do you do?
What good looks like: rank scenarios by risk (how likely a failure is and how bad it would be), run the highest first, and share a clear picture with the product owner: what's tested, what isn't, and the risk of shipping. The decision to ship is shared and documented.
Red flag: quietly marking untested items as passed.
9. What do you check when testing a REST API?
What good looks like: status codes, response schemas, authentication and authorization (can user A read user B's data?), input validation, pagination, idempotency of retries, error formats and rate limits. Contract tests catch breaking changes between services before integration.
10. How do you test a feature built on an LLM, where output changes every run?
What good looks like: test properties instead of exact strings (format, length, required facts, no banned content), build a set of real example inputs with scoring rules, run each case several times and track the pass rate against a threshold, and add cases for prompt injection and leaks of personal data. These tests run whenever the prompt or model changes.
Automation
11. A UI test fails about one run in ten. What do you do?
What good looks like: find the cause instead of adding retries. Common causes are hard-coded sleeps, tests sharing data or depending on order, animations, and unstable third-party services. Quarantine it with a ticket so it doesn't block others, then fix it. In Playwright, built-in auto-waiting and web-first assertions remove many timing problems.
Red flag: automatic retries everywhere, so flakiness is hidden for good.
12. How do you choose locators for UI tests?
What good looks like: prefer what users see, such as role and accessible name (Playwright's getByRole, for example), or dedicated test IDs. Avoid long CSS or XPath paths tied to layout, which break with every redesign.
13. Which tests would you automate first on a product with none?
What good looks like: the critical user paths that run often and change rarely, such as sign-up, login and checkout, plus API tests for core business rules. They'd skip automating one-off checks and screens still being redesigned.
14. How do you manage test data?
What good looks like: each test creates the data it needs through APIs or factories, and cleans up or runs in an isolated environment. Avoid shared test accounts that tests fight over. A database in a container per test run keeps integration tests repeatable.
15. Your end-to-end suite takes 90 minutes. How do you speed it up?
What good looks like: run tests in parallel and shard across machines, move checks that don't need a browser down to API or unit level, remove duplicate coverage, and split the suite so a fast smoke set blocks merges while the full set runs later.
Quality across the team
16. How do you measure whether quality is improving?
What good looks like: bugs that escape to production and their severity, change failure rate, time to detect and fix issues, and the flaky test rate. They avoid counting test cases or bugs filed as goals, since those are easy to inflate.
17. What do you do before any code is written?
What good looks like: review requirements and ask how each one would be tested, help write acceptance criteria, flag missing edge cases, and agree on test approach with developers early. Catching a misunderstanding here is the cheapest fix there is.
18. How do you approach accessibility testing?
What good looks like: automated scanners such as axe catch part of the problems, so they also test with the keyboard only, with a screen reader, at high zoom, and for color contrast. They know WCAG 2.2 level AA is the common target.
Behavioral (STAR)
19. Tell me about a serious bug that reached production on your watch.
What good looks like: what the bug was and its impact, why testing missed it, what they did right away, and the change they made (a new test, a review step, a monitoring alert). They take responsibility without blaming developers.
20. Describe a time you pushed back on a release.
What good looks like: concrete evidence of risk, a proposal (fix first, ship behind a flag, or ship with a known issue documented), and respect for the final decision. The best stories show they kept the relationship with the team strong.
A simple scoring rubric
Running this interview with AI
A first QA screen mostly asks candidates to think out loud about how they'd test something, which an AI interviewer can do in a live, two-way conversation. With NTRVSTA you can customize the questions per role, so scenarios like the discount-code checkout become part of every interview. The interviewer adapts to each answer, digging further when a candidate stops at the happy path, and asks behavioral questions using STAR. Automation roles can also be screened on programming languages from the exam library, such as Java, Python or JavaScript.
Reviewers get a score breakdown and video snippets of key moments, then bring the best candidates in for a hands-on task. Read how AI interviews are scored before relying on any score, and compare options in the best AI interview software. Related question sets: software engineer, JavaScript, Java and DevOps.
Questions
Should I interview manual and automation QA candidates differently?
Use the same test design and risk questions for both, since that thinking is the core of the job. Then add the automation section and a short coding task only for automation roles. Many strong manual testers are excellent at finding bugs, which is a skill worth scoring on its own.
Is a take-home automation task a good idea?
A small one can be. Give a simple public demo app or a tiny service, ask for three or four meaningful tests in the candidate's preferred framework, and cap it at two hours. Review how they chose what to test and how they named and structured the tests, not just whether they pass.
How can I test a candidate's testing mindset in 30 minutes?
Hand them an everyday object or a simple screen, such as a login form, and ask how they would test it for ten minutes. Strong testers ask about users and risk first, then cover negative cases, security, accessibility and performance without being prompted.
Curious what a QA screen looks like when an adaptive AI interviewer runs it? Book a 20-minute demo with us, or try a sample interview to test it like a QA engineer would.
