Quality assurance interviewing has changed more in the last two years than in the previous decade. The “manual QA who clicks around in staging” job description has shrunk hard, and roles now sit on a clearer spectrum: exploratory and risk-based manual testing on one end, automation engineering in the middle, and SDET work that overlaps with backend engineering on the other end. Interview loops reflect that. This guide covers the questions you will actually hear in 2026 across all three flavors of the role, what hiring managers want behind each question, and how to prep without burning a weekend on irrelevant LeetCode grinds.
The QA Engineer interview funnel
A modern QA loop usually has four to six stages and the structure tells you which slice of the role the team is hiring for. A typical funnel looks like this: recruiter screen (30 minutes, scope, comp, work authorization), hiring manager call (45-60 minutes, story-mode questions about past projects), a technical round, a take-home or pairing exercise, and a values or “bar-raiser” interview.
The technical round is where the role really splits. Manual QA loops focus on test design — given a feature spec, how would you decompose it into equivalence classes, boundary cases, and exploratory charters. Automation loops add a live framework exercise, usually “write a Playwright or Cypress test against this demo site” with twenty to forty minutes of pairing. SDET loops include a full coding interview (data structures, sometimes a system design lite) plus a framework-design round where the prompt is something like “design the end-to-end test harness for a checkout flow that spans three services.”
A practical signal: if the recruiter mentions “you’ll be working closely with the platform team” or “we’re hiring into engineering, not into a separate QA org,” expect SDET-level coding. If the JD mentions JIRA workflows, test plans, and “regression cycles,” it leans manual. If the JD names Playwright, Cypress, or Selenium plus CI/CD, it is squarely automation. Match your prep to the funnel, not to a generic “QA interview questions” list.
Test strategy and planning questions
Strategy questions are where strong candidates separate from script-readers. The test pyramid is the canonical opener. Originally from Mike Cohn and popularized by Martin Fowler’s “Practical Test Pyramid” essay, it argues that fast unit tests should make up the base of a suite, integration tests the middle, and slow UI-driven end-to-end tests the tip. A 2025 survey of engineering leaders found 76% identified test automation evolution as a critical factor in their roadmap, and pyramid alignment is usually the first decision called out. Interviewers want to hear that you would push back on a strategy with hundreds of E2E tests and no unit coverage, because the feedback loop becomes slow and flake-prone.
Expect follow-ups on risk-based testing: how do you decide what to test first when you cannot test everything before a release. A clean answer combines impact (revenue, data integrity, regulatory) with likelihood (recent code churn, complexity, history of defects). Map features into a quick four-quadrant grid and explicitly accept the risk on the low-impact-low-likelihood quadrant.
Equivalence partitioning and boundary value analysis show up in almost every loop. Be ready with a worked example: a coupon code field that accepts 6-12 alphanumeric characters has three equivalence classes (under 6, 6-12, over 12) and four boundary values (5, 6, 12, 13). Hiring managers want to see that you do not blindly write one test per requirement — you compress the input space using formal techniques.
Finally, exploratory vs scripted. The strong answer is “both, intentionally.” Scripted tests cover the spec; exploratory charters cover the unknowns. Reference session-based test management (SBTM) from James Bach if you want to signal depth without sounding rehearsed.
Automation and tooling questions
Automation rounds in 2026 are dominated by Playwright. Indeed shows roughly 10,200 postings mentioning Playwright versus 8,800 for Selenium, and the gap is closing fast. Most loops will ask you to compare the two: Playwright auto-waits on actionability, ships a built-in trace viewer, parallelizes via sharding natively, and runs across Chromium, WebKit, and Firefox from a single API. Selenium wins on raw browser coverage and a longer ecosystem, but loses on developer experience.
Common Playwright drill-downs: locators (prefer getByRole, fall back to getByTestId, avoid CSS selectors that mirror styling), fixtures (how to share authentication state across tests with storageState), POM vs functional helpers (POM still useful for high-churn UIs, but flat helper functions scale better in small suites), and API testing via the request fixture for hybrid UI+API flows.
Contract testing is the underrated topic that separates senior candidates. Tools like Pact let consumer and provider teams agree on an API contract and verify both sides independently, which sits between unit tests and full E2E in the pyramid. Mentioning Pact or consumer-driven contracts is a strong signal in any microservices org.
CI integration is the closing question. Be ready to explain Playwright sharding in GitHub Actions or GitLab CI — splitting a 600-test suite into eight parallel shards drops execution time from 40 minutes to under 6, and that single optimization commands a noticeable salary premium because it reduces CI bills.
Bug-reporting and reproduction questions
Many candidates underprepare this section because it feels obvious, then lose offers on it. The standard prompt is “walk me through a bug you found that nobody else could reproduce.” A weak answer says “I added more logs.” A strong answer narrates a minimal reproduction: isolate the variables (browser, network, user state, feature flag), bisect on the variable most likely to matter, capture a HAR file or trace, then strip the steps until the smallest possible recipe still triggers the failure.
Severity vs priority is the second classic. Severity is the technical impact on the system — data loss is critical, cosmetic misalignment is trivial. Priority is the urgency relative to the business — a typo on the pricing page is low severity but P0 priority because every visitor sees it. Conflating the two is the most common mistake.
Expect a live bug-report exercise: the interviewer demos a small site or shows a screen recording and asks you to write the ticket. Cover title (observed problem, not guessed cause), environment and build, steps to reproduce that a developer can follow without context, expected versus actual, severity and priority with reasoning, and attachments. Add a “hypothesis” line if you have one, but flag it as a hypothesis — never as a diagnosis.
A final test of senior judgment: how do you decide to file vs ignore. Production-impacting and reproducible always goes in the tracker. Cosmetic and intermittent gets logged but might not block release. Document the rationale either way — silent dropped findings erode trust.
What hiring managers look for
Behind every technical question, hiring managers are scoring three traits. First, quality mindset. Do you talk about preventing defects upstream, or only about catching them downstream. The “shift left” framing — pulling testing earlier into design and code review — has been the dominant industry trend since 2022, and candidates who only describe end-of-cycle work read as outdated.
Second, ownership. The strongest QA hires treat shipped bugs as their problem even when an engineer wrote the code. They run blameless retros, propose process changes, instrument production for better signal, and follow up on action items. Phrases that score well: “I owned the regression report for that release,” “I drove the postmortem,” “I shipped a dashboard that surfaced flake to the whole team.”
Third, collaboration with developers. The old adversarial QA-vs-dev dynamic is gone in healthy orgs. Hiring managers want to hear that you pair with developers on test design, leave kind PR reviews on test code, and understand the codebase well enough to suggest where a unit test would have caught the bug instead of an E2E. If you can read a stack trace and propose a fix location, say so.
Watch for the “tell me about a disagreement” question. The trap answer is “I escalated to my manager.” The strong answer shows you advocated for the user, presented data (defect rates, customer tickets, telemetry), and either changed minds or accepted the decision and moved on.
Questions to ask them
Your questions are graded. Recycled prompts like “what’s the culture like” waste the slot. Use the time to test for red flags and to demonstrate seniority.
Strong questions to ask a hiring manager:
- Who owns quality on this team? If the answer is “the QA org,” that team treats quality as a separate function and you will likely be the bottleneck. If the answer is “everyone, and we have a QA partner embedded with each squad,” that team has shifted left.
- What does the current test pyramid actually look like? Ask for rough ratios. “We have 12,000 unit tests, 800 integration tests, and 150 E2E” is a healthy answer. “We mostly run a Selenium suite” is a warning.
- How long is the CI pipeline today? Under 15 minutes is excellent. 30-60 minutes is normal. Over an hour means you will spend your first quarter on infra work.
- How is flake handled? A team with a quarantine process, weekly flake review, and a flake-rate SLO is mature. “We just rerun until it passes” is a smell.
- Where does bug triage happen? Cross-functional triage with PM, engineering, and QA is healthy. QA-only triage means findings get dismissed quietly.
- Is there an on-call rotation for the test infrastructure? If yes, ask how often it pages and what runbooks exist.
These questions also signal that you know what good looks like, which often matters more than the literal answer.
Common mistakes
Five patterns lose loops more than any others.
Memorizing definitions without examples. Reciting “equivalence partitioning is dividing input data into classes” without a worked example reads as surface-level. Always have a one-minute concrete story ready.
Treating automation as separate from testing. Candidates who say “I write the automation, manual QA writes the tests” miss the point. Automation is testing — selector strategy, data setup, and assertion design are all test design problems.
No public artifacts. A GitHub repo with one real Playwright or Cypress project, a README that explains framework choices, and a green CI badge does more than three pages of resume bullets. Build it before applying.
Ignoring SDET coding prep. If the JD says SDET, the coding bar matches the software engineer ladder. Knock out 50 LeetCode easies and 30 mediums, focus on arrays, strings, and hashmaps, and practice talking through your reasoning out loud.
Vague flake stories. “We had flaky tests and I fixed them” is not an answer. Name the root cause (race condition, shared state, network timeout, brittle selector), the diagnosis tool (trace viewer, video, network HAR), and the durable fix.
Avoid those five and prep the eight to twelve question categories above, and most QA loops in 2026 become winnable.
Sources:
- Why the Test Pyramid Still Matters in 2025 — Qalified
- The Practical Test Pyramid — Martin Fowler
- Playwright Job Market in 2026 — TestDino
- QA Automation Engineer in 2026: Essential Trends — Refonte Learning
Frequently asked questions
What are the most common QA engineer interview questions in 2026?
Expect a split between test strategy (test pyramid, risk-based testing, equivalence partitioning), automation craft (Playwright or Cypress locators, fixtures, Page Object Model), debugging flake, and a bug-reporting exercise. SDET loops add a coding round at roughly the same bar as a software engineer interview.
How is the QA engineer role different from SDET and automation engineer?
Manual QA focuses on exploratory testing, charter-based sessions, and reproduction quality. Automation engineers own framework code and CI pipelines but rarely write product code. SDETs sit closest to developers, contributing to production code, test infrastructure, and observability tooling — and are compensated within 5-10% of software engineers.
Do I still need to know Selenium if I learn Playwright?
For greenfield work, Playwright is the safer bet — auto-waiting, trace viewer, and parallel sharding cut flake meaningfully. But many enterprise codebases still ship Selenium suites, so understanding WebDriver protocol, explicit waits, and grid setup keeps you eligible for a wider job pool.
What is the test pyramid and why do interviewers care?
It is a heuristic from Mike Cohn that says fast unit tests should be the base, integration tests the middle, and slow end-to-end tests the tip. Interviewers use it to check whether you push back on E2E-heavy strategies that produce slow, flaky pipelines instead of fast feedback.
How do I answer 'severity vs priority' in a QA interview?
Severity describes technical impact on the system; priority describes urgency to fix relative to business goals. A typo on the login page is low severity but high priority because every user sees it. A rare data-loss edge case can be critical severity but lower priority if no customer is currently affected.
What should a good bug report contain?
Title with the observed problem, environment and build, steps to reproduce that anyone can follow, expected vs actual result, severity, attachments (logs, video, HAR, screenshots), and any minimal reproduction notes. Bonus points for adding a hypothesis about root cause and linking the failing test.
How do I talk about flaky tests in an interview?
Quote the 2025 Perforce Continuous Testing Report finding that over 30% of orgs struggle with test instability, then walk through a fix loop: quarantine first, classify root cause (timing, data, environment, selectors), add deterministic waits or test doubles, and only un-quarantine once a test passes 50 consecutive CI runs.
What coding questions appear in SDET loops?
Array and string manipulation, hashmap problems, basic graph traversal, plus design-a-test-framework or design-a-bug-triage-system. Recruiters compare against the standard software engineering ladder, so practice on LeetCode easy and medium tier.
How do I prepare if my background is mostly manual testing?
Build one public Playwright or Cypress project against a real site, push it to GitHub with a GitHub Actions workflow, write a README explaining the framework decisions, and rehearse explaining flake fixes and selector strategy. That single artifact closes most loops that screen for automation.
What questions should I ask a QA hiring manager?
Who owns quality on the team, what the current ratio of unit to E2E tests looks like, how long the pipeline runs, how flake is handled, where bug triage lives, and what the on-call rotation looks like. The answers reveal whether quality is shared or thrown over the wall.