QA & SDET Interview Questions for 2026

J. Kessler 18 min read

The QA and SDET interview questions that filter candidates in 2026: framework design, AI-augmented testing, and the answers that actually pass.

The single question that will filter you fastest in a 2026 QA or SDET interview is not about the test pyramid. It is: how do you keep up with the pace of development?

If your answer describes the old model, you have already lost the round. The old model: developers build a feature, throw it to QA, testers validate manually, automation gets added later. Or manual and automated teams work in parallel and never quite converge. That model does not survive an engineering org shipping AI-generated code every hour. Interviewers in 2026 are hiring for the opposite instinct: a QA engineer who designs the tooling so developers can test themselves, owns the overall coverage and pass-rate story, uses agents to augment exploratory testing, and treats “run the suite” as a solved problem so their attention can go to the parts of quality that are not.

This piece is the QA interview questions and SDET interview questions that actually show up in 2026 loops, grouped by what interviewers now filter for. A fundamentals round still opens the loop because the vocabulary matters, but the meat is framework design, automation strategy under AI-generated code, and the new AI-in-testing round that Google, Microsoft, and Amazon added to their loops in the past year.

What interviewers actually filter for in 2026

Three shifts changed the interview loop:

  1. The senior QA / SDET role is now framework and tooling ownership, not test authorship. Junior candidates get asked to write tests. Mid and senior candidates get asked to describe the framework’s components and how they stitch together. Staff candidates get asked how they would design test infrastructure that supports parallel end-to-end execution across a hundred developers.
  2. AI-in-testing is a mandatory round. As of early 2026, the largest QA employers dedicate a full stage to it. If you have not thought about how you would use, evaluate, and constrain agents in your test workflow, you cannot pass.
  3. QA owns the test system, not the daily testing activity. The signal interviewers look for is a candidate who talks in coverage numbers and pass-rate trends, not in “I ran 40 test cases yesterday.”

The rest of this piece walks through the six rounds you should expect, the questions that get asked in each, and what a passing answer looks like.

Round 1: Testing fundamentals (warm-up, not the filter)

These questions still open most loops. They confirm you know the vocabulary. Answer them tightly. Over-explaining a fundamentals question signals you have not seen the harder ones.

Q: Verification vs. validation. Verification checks the product against its spec (“did we build the thing right?”). Validation checks the product against user need (“did we build the right thing?”). A signed-off requirements doc is verification’s source of truth; a user interview or production telemetry is validation’s.

Q: Explain the test pyramid. Many unit tests at the base, fewer integration tests in the middle, a small layer of end-to-end tests at the top. The rationale is cost and speed: unit tests catch most bugs cheaper. The interviewer is checking whether you know the classical model. Round 3 will ask whether you still believe in it.

Q: Smoke vs. sanity vs. regression. Smoke tests are a shallow check that the build boots and the critical paths respond. Sanity tests are narrow checks that a specific fix or feature works. Regression tests are the broad safety net that verifies old behavior still holds after a change.

Q: Positive vs. negative testing. Positive tests confirm the system does what it should with valid input. Negative tests confirm it fails safely and predictably with invalid or malicious input. A candidate who only writes positive tests is not testing.

Q: Black-box, white-box, gray-box. Black-box: no knowledge of internals, test through the public interface. White-box: full knowledge, tests target specific branches and internal states. Gray-box: enough knowledge to design better tests without coupling to internals. Most modern SDET work is gray-box; you know the code well enough to write efficient tests but you deliberately test through the interface.

Q: Equivalence partitioning and boundary value analysis. Equivalence partitioning: group inputs into classes where any member should behave the same, test one from each class. Boundary value analysis: the bugs live at the edges of those classes, so also test one below, at, and above each boundary. Together they are how you cut a combinatorial input space to a testable set.

Q: Test case vs. test scenario. A test scenario is the goal (“verify checkout works with expired card”). A test case is the concrete steps and expected result. Interviewers ask this to check whether you can write test artifacts a stranger can execute.

If the loop asks four or five of these and moves on, you passed the warm-up. If they linger here for the full round, either the role is junior or you are not selling the higher-level signals hard enough in your answers.

Round 2: Framework design (the mid/senior filter)

This is where mid and senior candidates get separated. The interviewer wants to know whether you can build and defend a test framework, not just write tests inside someone else’s.

Q: Walk me through the components of a test framework you have built or maintained. The passing answer names five to eight components and describes their contract with each other. A representative shape: the test runner (Playwright, pytest), the fixture layer (per-test setup/teardown, database seeding), the page-object or interaction layer, the assertion layer (custom matchers), the test data layer (factories, generators, cleanup), the reporting layer, the CI integration layer, and the configuration layer (env-specific config). Bonus points for talking about how each layer is independently swappable.

Q: Page Object Model vs. Screenplay pattern. POM organizes selectors and interactions per page as a class. Screenplay organizes tests around actor personas performing tasks against the system, decoupling the “who” from the “what.” Screenplay reads better for complex behavior-driven flows; POM is faster to bootstrap for straightforward UI coverage. A senior answer names the tradeoff and picks based on the app’s flow complexity, not on Twitter’s opinion this month.

Q: How do you manage test data across environments? The passing answer covers three concerns: isolation (each test sets up and tears down its own data so tests do not leak into each other), freshness (seed data does not go stale as the schema evolves), and parallelization safety (two concurrent tests must not fight over the same user record). Candidates who mention factories, per-test unique identifiers, or database transactions rolled back after each test are showing they have hit these problems in production.

Q: How would you design a test suite to run in parallel? This is the current staff-level filter. Concrete things to talk about: test isolation (no shared mutable state), test-scoped unique data (email-based user creation with a UUID suffix, not a hard-coded fixture), assertion resilience to concurrent actors, retry logic that distinguishes flakiness from real failure, and scale-out infrastructure (a browser cloud, sharded execution, per-worker environment). If you cannot articulate the race conditions that appear when a sequential suite is parallelized, you have not run one. The qarepo-playwright-starter implements all of these; the tests/fixtures/ directory is a concrete answer to this question.

Q: When is retry logic a fix and when is it a band-aid? Retries are correct when the underlying operation is legitimately non-deterministic (network flake, eventual consistency, third-party API rate limiting). Retries are a band-aid when the test is racing against its own setup, or when a flaky selector is masking a real UI regression. A senior candidate distinguishes and instruments both: retry with metrics, so you can see when retry rates climb.

Q: How do you triage flaky tests in a suite of 5000? Instrument first. You cannot fix what you cannot see. Track per-test pass rate over a rolling window. Anything under 98% goes into a quarantine list. Fix the top-flake-rate tests weekly, either by fixing the flake source or by deleting the test if it does not earn its cost. Never accept “just re-run it” as team culture. That path ends with a suite nobody trusts. The concrete instrument-first pattern lives in the flake reporter shipped with the qarepo Playwright starter — per-test outcome JSON per run, aggregated across a 90-day GitHub Actions artifact window.

Round 3: Automation strategy in the AI era

The classical test pyramid is on shakier ground than it was five years ago. Interviewers now want to know what you think about it, not whether you can draw it.

Q: The traditional pyramid says lots of unit tests, fewer end-to-end. Is that still right when agents are writing the code? The honest answer: it is more contested than it was. When human developers wrote both the code and its unit tests, the pyramid was efficient. Unit tests were cheap, integration tests medium, end-to-end tests expensive. When agents write the code and the unit tests, the unit tests are cheap in a different sense: they can be trivially gamed. An agent that writes a function and its unit test in the same pass has strong incentive to make the test pass. What is harder to game is the true end-to-end experience: real HTTP, real database, real browser. Several senior testers now argue the pyramid should invert or at least flatten in AI-heavy codebases.

Q: When would you NOT automate a test? When the check is one-off, when the UI is scheduled for a rewrite inside the automation’s payback window, when the setup cost of the fixture is greater than the multi-year savings of the automated run, or when the test would be automating an interaction that has no user (dead code paths). “Always automate everything” is the wrong instinct. You are competing with your own maintenance backlog.

Q: What is your quality strategy when AI is writing 80% of the production code? Passing answer: shift emphasis from “review every line” to “define and enforce quality gates the code has to pass regardless of who wrote it.” Coverage floors that trip CI. Contract tests between services. End-to-end suites that exercise real user paths. Performance budgets. Security scanning. Automated eval loops that treat agent output the way we treat human PRs — evidence required. See Testing in the Age of AI and Using AI Agents for Testing for the depth version of this argument.

Q: How do you decide the right ratio of unit / integration / end-to-end tests? The old pyramid is one heuristic; another is: pick the level where the bug you are most afraid of is caught. If your fear is a business-logic regression, unit-level suffices. If your fear is two services drifting apart, contract tests. If your fear is the entire user path silently breaking after an agent-produced refactor, end-to-end. The interviewer is checking whether you reason from risk or from a diagram.

Round 4: The AI-in-testing round

This is the round that did not exist in interview loops two years ago. As of 2026 it is a full stage at Google, Microsoft, Amazon, and most companies interviewing for QA leadership. Prepare for it, or fail it.

Q: How would you use AI agents to augment exploratory testing? Concrete answer: spin up agent personas that mimic distinct customer behavior patterns: the impatient mobile user, the enterprise admin batch-configuring accounts, the malicious script-kiddie probing forms. Give each persona a goal and a budget of actions. Log everything they do and what happens. Grade the run on whether the system produced correct output and whether the user experience was defensible under that persona’s pressure. This is what real teams are shipping in 2026, not a hypothetical.

Q: When would you trust an AI-generated test case? When the contract the test claims to verify is specified independently of the test (so the test cannot silently drift to match the code), when a human has reviewed the assertion, and when the test has caught at least one regression in production that was not caught by the human-written suite. Trust is earned by evidence, not conferred by the model that produced the artifact.

Q: How would you detect that an agent hallucinated in a generated test? Signals to look for: assertions that check trivially-true properties (expect(result).toBeDefined()), test setup that mocks the very behavior the test is supposed to verify, test names that describe a behavior the assertions do not actually check, and the absence of any negative case. Any of these means the test looks like coverage but is not.

Q: What is the wrong answer here? The rejection answer is “we let the agent write the tests and we run them.” Interviewers are checking whether you understand that agent-produced tests without an independent contract are theater. If you cannot articulate what the tests are supposed to prove before the agent writes them, you are not testing.

Q: Design a scaled-out AI-powered test system for a mid-size SaaS product. Staff-level question. A passing sketch: a durable spec store where product requirements live as executable contracts; a fleet of persona agents replaying real-world traffic patterns against staging; a traditional deterministic Playwright suite covering critical happy paths; a coverage and pass-rate dashboard as the source of truth for release readiness; automated regression triage that clusters new failures and hands the human the smallest set of investigations. The interviewer wants you to reason about the components, not to have built the whole thing.

Q: How do you evaluate whether an AI-based testing tool is worth adopting? Passing framework: define the specific failure mode you want it to catch, wire it up on a staging slice, and measure both true-positive rate (real bugs found) and false-positive rate (developer time wasted). If the tool cannot beat your existing suite on some dimension you care about within four weeks, cut it.

Round 5: API testing and SQL for testers

Still a filter for most SDET roles because the underlying skill is verification through the layer where product bugs actually live.

Q: How do you test a REST API without a UI? Direct HTTP client (curl, Postman, Playwright’s request fixture, requests in Python). Verify status code, headers, and body schema on every response. Test happy path, boundary conditions, auth failures, rate limiting, and malformed input. Verify idempotency for PUT and DELETE. Verify that GET is safe (does not mutate state).

Q: What is contract testing and when do you reach for it? Contract testing verifies that two services agree on the shape of the messages they exchange, without deploying both to a shared environment. Pact and Spring Cloud Contract are the reference tools. You reach for it when integration tests are catching bugs that could have been caught earlier and cheaper by comparing recorded interactions against a schema.

Q: SQL a QA engineer should know: what queries and what for? SELECT with WHERE / JOIN / GROUP BY for verifying state after a test action. INSERT for seeding controlled test data. DELETE and TRUNCATE for teardown (with care about foreign keys). EXPLAIN for spotting when a slow-running test is actually a missing index in the app. Window functions for verifying ranking or ordering business logic without duplicating it in the test.

Q: How do you test a GraphQL API? Same principles as REST but the query language changes shape. Verify each field’s type and nullability, verify that querying nested fields returns the expected shape without extra round-trips, and test that queries do not return more data than the requesting user is authorized to see (authorization is a common GraphQL bug source).

For a full comparison of frameworks that support these API and browser test patterns, see Playwright vs. Cypress vs. Selenium.

Round 6: Behavioral and scenario

Every loop has one. The interviewer is checking whether you can work with engineers without being either a doormat or an obstacle.

Q: Tell me about a time you disagreed with a developer about whether a bug was a bug. The passing answer is specific, names the disagreement plainly, and describes how you resolved it, usually by writing down the expected behavior, agreeing on it with the PM, and letting the resolution follow from the spec. Answers that describe the developer as wrong and the tester as right, without acknowledging the ambiguity of the original spec, signal a candidate who cannot collaborate under pressure.

Q: Describe a bug that shipped despite your testing. What did you change? Interviewers are looking for the failure mode you learned to defend against, not the specific bug. Passing answers describe a class of gap (an environment-specific race condition, a data shape the test corpus did not cover, a browser version the CI grid did not include) and a change to the process that closed it (adding a chaos test tier, expanding fixture diversity, adding a mobile Safari lane).

Q: How would you convince engineering leadership to invest in test infrastructure? Talk in engineering-velocity numbers: cycle time from PR open to prod, developer hours lost to flake, incident-count trend. Product leadership does not respond to “we need more test coverage.” They respond to “our flaky suite is costing us 12 developer-hours a week and I can cut it to two.” See How to Write a Bug Report for the same principle applied to individual defect reports.

Q: How would you onboard a new engineer to a large existing test suite? Day one: point them at the failing tests in the last week and pair on triage. This teaches them the current pain points and the codebase’s actual weak spots faster than any tour. Day two: have them write and merge one small test end-to-end so they learn the CI and review flow. Day three onward: assign them ownership of one narrow area.

What to focus on next

If you are preparing for a 2026 QA or SDET loop, the highest-value prep is probably not memorizing more definitions. It is these five:

  • Be able to walk through a test framework you have built or maintained, component by component. If you have not built one, build a small one this month against a public API and use it in the interview.
  • Have an opinion on the pyramid in the AI era. The interviewer will ask what you think and press on the answer.
  • Prepare the AI-in-testing round explicitly. Agent personas, evaluating agent-produced tests, quality strategy under AI-generated code. This round did not exist two years ago and most candidates still under-prepare for it.
  • Practice reasoning about parallelization. Race conditions, shared state, data isolation, retry patterns. This is the current staff-level filter.
  • Do at least one round of SQL and API testing practice. Both still get asked.

For structured practice on the framework and API sides specifically, the Udemy QA courses are the fastest way to close the “I know the vocabulary but have not built one” gap that trips most mid-level candidates.