The worst QA interview advice I’ve seen repeated is “just know Selenium and the test pyramid.” That was barely sufficient in 2019. In 2026, companies are screening for something more complicated: the ability to think about test strategy at an organizational level, not just write test scripts.
I’ve been collecting feedback from QA engineers who’ve gone through interviews at SaaS companies, healthtech firms, and mid-size fintechs over the past year. The pattern that stands out is that candidates who prepare for technical questions but skip the strategy layer consistently get cut after the technical screen, not during it.
Here’s how to not be that candidate.
What interviewers are actually evaluating
Most QA interview guides list what topics to study. Few explain the evaluation criteria underneath the questions. Based on feedback from hiring managers, there are really three things being assessed:
Technical depth: Can you write real automation code, diagnose flaky tests, and discuss tool trade-offs without just reciting marketing copy from each tool’s homepage?
Strategic thinking: Do you know when not to automate? Can you make a case for test prioritization to an engineering manager who doesn’t care about QA metrics?
Collaboration signals: How do you work with developers who think their feature works fine when your test says it doesn’t? How do you push back on unrealistic sprint timelines?
Most candidates over-prepare for depth and under-prepare for the other two. That imbalance shows fast.
The automation tools question has gotten more nuanced
A few years ago, “Selenium or Cypress?” was a reasonable proxy question. Now interviewers at modern-stack companies are just as likely to ask about Playwright, and the answer isn’t “Playwright is better.” The Stack Overflow Developer Survey 2024 tracks Playwright adoption accelerating, but Selenium still runs the majority of existing enterprise test suites.
What interviewers want to hear is a framework for choosing, not a winner:
- What’s the existing stack? What languages does the dev team write in?
- Is cross-browser coverage actually required, or is Chromium enough?
- Does the team have CI/CD? What does the pipeline look like?
- How much ongoing maintenance capacity exists for the test suite?
If you walk in with a prepared opinion on tools before gathering that context, experienced interviewers will notice. The better answer is “it depends, and here’s what I’d need to know.”
Testing fundamentals that still trip people up
Some questions look basic but have layered answers. These are worth preparing properly:
Smoke vs. regression testing. Smoke testing is a shallow pass to verify the build is deployable. Regression is broader and checks that existing functionality hasn’t broken. The confusion happens when teams use “smoke” to mean “our regression suite on a subset of features,” which is a different thing with a misleading name.
Equivalence partitioning and boundary value analysis. These come up in technical screens more than people expect. Equivalence partitioning means grouping inputs that should behave identically and testing one value from each group. Boundary value analysis tests at the edges of those groups. Together, they’re a systematic way to reduce the number of test cases without reducing coverage. I honestly think these are more useful in practice than most candidates give them credit for.
Why the test pyramid falls apart in microservices. The classic pyramid (lots of unit tests, fewer integration tests, few E2E tests) assumes a single deployable application. When you have 30 microservices, the integration layer explodes in complexity and the pyramid model starts to break down. Contract testing emerges as a partial answer. This is worth mentioning if you’re interviewing at a company with a distributed architecture.
API and CI/CD: where the depth questions live
Mid-level and senior QA roles expect you to own API testing, not just UI automation. A few things worth knowing cold:
- The difference between unit, integration, contract, and E2E tests as they apply to APIs
- How to test for backward compatibility when an API version changes
- What a test doubles (mock, stub, spy, fake) is and when each is appropriate
On CI/CD: the practical question interviewers ask is “how do you decide what runs on every commit vs. nightly vs. pre-release?” The answer involves test execution time, risk surface, and team deployment frequency. If your answer is “we run everything on every commit,” most senior interviewers will push back and ask what happens when that takes 90 minutes per commit.
The BLS data on software QA roles shows consistent demand growth, with the most growth concentrated in companies that have formal CI/CD pipelines. That means the CI/CD integration knowledge isn’t optional for competitive applications.
Performance testing, even if you think it won’t come up
I’ve heard from enough engineers that performance testing questions appear in mid-level QA screens to recommend preparing at least the basics. You don’t need to know k6 or Gatling in depth, but you should be able to explain:
- Load testing (expected concurrent users at normal load)
- Stress testing (increasing load until the system breaks)
- Soak testing (sustained normal load over hours or days to catch memory leaks)
- Spike testing (sudden burst of traffic)
The scenario question version: “Your app is 3x slower after a new feature release. Where do you start?” Walk through a structured diagnostic (not just “I’d add logging”), but a prioritized checklist of likely culprits: database query changes, external API call latency, connection pool settings, cache invalidation. Showing a process is what matters, not having the right answer immediately.
How to actually prepare in the two weeks before an interview
Most people read articles and take notes. That’s fine, but it doesn’t prepare you for speaking under pressure. A few things that actually help:
Write out answers to the five hardest scenario questions and read them aloud. You’ll immediately find the gaps in your reasoning that read-and-nod studying misses.
Pick one tool you know well (say, Playwright) and one you’ve only used a little (say, REST-Assured for API testing). For each, prepare a 60-second “here’s what I know, here’s where my knowledge gets thin” answer. Interviewers respect that framing more than candidates who fake depth they don’t have.
Do at least one mock interview session where you answer questions out loud to something other than your own reflection. Craqly’s AI interview copilot runs during live or practice sessions without joining as a visible bot, which is useful for practice runs where you want real-time feedback on how complete your answers actually are.
The thing nobody tells you before a QA interview: the interviewers are often developers who moved into QA, not career testers. They’ll ask developer-style questions. Prepare for “show me your code” as much as “explain your process.”