A friend of mine failed a QA automation interview at a mid-size fintech last spring. He knew Selenium cold. The problem was that the first question wasn’t about Selenium at all. It was about why he would not automate something. He had no answer ready.
That’s the shift happening in QA interviews right now. Interviewers at companies like Stripe, Atlassian, and smaller SaaS shops are less interested in whether you can write a Page Object Model from scratch, and more interested in whether you understand when automation is worth the maintenance cost. The technical questions still come, and they come hard, but the framing has changed.
Below are the 47 questions I’ve seen (and heard about from engineers in the testing community) showing up most often in 2026 QA automation rounds, grouped by topic. I haven’t included every variation, just the ones that trip people up.
The test pyramid question everybody fumbles
Almost every QA automation screen starts here: “Explain the test pyramid.” Most candidates recite the three layers (unit, integration, E2E) correctly. Then the follow-up hits: “Your E2E suite takes 45 minutes. What do you do?”
The right territory to explore is not “add parallelism” first. It’s: are those E2E tests actually testing things that should be unit or integration tests? A 45-minute suite usually means test logic crept upward into E2E when it didn’t need to.
Related questions you should expect:
- What’s the difference between verification and validation?
- How do you decide which tests to automate vs. leave manual?
- When would you recommend fewer automated tests?
That last one is worth sitting with. Most candidates are never asked to argue against automation. Having a real answer here (flaky-prone areas, rapidly changing UI, one-off edge cases) is a genuine differentiator.
Selenium vs. Playwright vs. Cypress: what interviewers actually want
The Stack Overflow Developer Survey 2024 shows Playwright adoption accelerating sharply among professional developers, which means interviewers at newer companies are increasingly asking Playwright-specific questions. Selenium still dominates older enterprise stacks, so if you’re targeting a company with a Java-heavy backend, prepare accordingly.
The comparison questions that actually show up:
- “You’re starting a new automation project from scratch. Walk me through your tool selection.”
- “Explain the architectural difference between Cypress and Playwright.”
- “You have a Selenium suite with 300 tests. The team wants to migrate to Playwright. What’s your migration strategy?”
For the Cypress vs. Playwright architectural question: Cypress runs inside the browser event loop, which gives it fast, reliable DOM access but limits multi-tab and cross-browser support. Playwright runs outside the browser via the CDP/WebSocket protocol, which gives it more flexibility but requires more explicit waits. Neither is universally better. Saying that (with a real reason for each) is what a strong answer looks like.
Flaky tests: 6 questions that reveal whether you’ve actually dealt with them
Interviewers love flaky test questions because the answers reveal experience quickly. Here are the six that surface most often:
- How do you identify a flaky test in a CI pipeline?
- Walk me through a flaky test you fixed. What was the root cause?
- How do you distinguish a flaky test from a real intermittent bug?
- Your team’s policy is to skip flaky tests and revisit them monthly. Do you agree with this? Why or why not?
- How do you prevent new flaky tests from being introduced?
- What’s your quarantine strategy for flaky tests that aren’t yet fixed?
Question 4 is the one I’d focus on. The answer isn’t obviously yes or no. It depends on test criticality, frequency of the flakiness, and team capacity. Interviewers are watching whether you think through trade-offs or just reflexively say “no, fix them immediately.”
API testing depth
Most QA roles in 2026 expect you to write API tests, not just UI tests. The questions here tend to escalate fast:
- What’s the difference between a REST and contract test?
- You’re testing a microservice that depends on three external services. How do you handle test isolation?
- How do you validate schema changes without breaking existing consumers?
- What’s consumer-driven contract testing, and when does it break down?
On consumer-driven contract testing: tools like Pact work well when teams agree on the workflow, but I’ve heard from engineers at companies with 50+ microservices that the overhead of maintaining pact contracts becomes a project in itself. Whether that tradeoff is worth it depends heavily on deployment frequency. Worth mentioning that nuance if asked.
Performance and load testing questions
These come up more in senior QA roles, but mid-level interviews at product companies increasingly include at least one:
- Explain the difference between load, stress, soak, and spike testing.
- You run a load test and p99 latency spikes after 200 concurrent users. Where do you look first?
- How do you correlate performance test results with production metrics?
The p99 latency question doesn’t have a single right answer. Database connection pool exhaustion, slow query plans, and external API timeouts are all common culprits. Walking through your diagnostic process out loud is the actual test here.
CI/CD integration and test strategy
The BLS Occupational Outlook for software QA engineers continues to show strong demand, particularly in organizations with mature DevOps practices. That context matters because companies with CI/CD pipelines ask test strategy questions that go beyond individual test writing:
- How do you decide which tests run on every commit vs. nightly?
- Your pipeline fails 30% of the time due to test instability. How do you make the case to leadership that this needs fixing?
- How do you measure test suite effectiveness beyond code coverage?
That last question is worth preparing a real answer for. Code coverage is a proxy metric, not a goal. Defect escape rate, mean time to detect, and test execution time per deployment are more useful measures, and naming them specifically will stand out.
Scenario questions they don’t warn you about
Most QA interview guides ignore the scenario round. These are the ones I’d prepare:
- “You join a team with zero automation. Where do you start?” (They want to hear risk assessment, not “I’d implement Selenium.”)
- “A developer says your automated test is wrong and the feature works fine. How do you handle it?”
- “You’re told to cut the test suite by 40% to speed up the pipeline. How do you choose what to cut?”
One thing worth trying before a QA interview: use an AI interview copilot during a practice run to hear how your answers land when spoken aloud. Craqly runs in the background during live or practice sessions and can flag when you’re going too shallow on a technical answer. It won’t fix gaps in your knowledge, but it’s useful for catching when you’ve given a one-sentence answer to a five-minute question.
The engineers who do well in QA automation interviews aren’t the ones who memorized every Selenium API. They’re the ones who can explain why they made a choice, and what they’d do differently with a year of hindsight. That’s what you’re actually being evaluated on.