Most QA interview prep advice is useless. It tells you to memorize definitions, practice scripting Selenium, and show up with a polished resume. Then you get into the interview and the first question is something like: "Walk me through how you'd test a new checkout flow end-to-end with a two-day deadline."

That question doesn't have a definition. It has a thousand possible answers, and only a handful of them signal that you actually know what you're doing.

This guide covers what actually happens inside QA interviews — what interviewers are looking for, where candidates consistently fail, and the specific preparation moves that separate hires from rejections.

1. What QA interviewers actually look for

The gap between what bootcamps teach and what interviewers evaluate is larger than in any other engineering discipline. Here's what's actually being assessed:

Coverage instinct, not coverage theater. Interviewers want to know if you instinctively think about edge cases, boundary conditions, and failure modes — not whether you can recite the IEEE definition of a test plan. When given a feature to test, candidates who immediately think "what breaks this?" score higher than candidates who immediately think "what document do I produce?"

Communication without jargon. QA engineers work with developers, product managers, and sometimes customers. Interviewers watch for candidates who can explain a security header vulnerability to a non-technical PM without losing accuracy. If you lean on acronyms as a shield, that's a signal.

Judgment over process. A lot of junior candidates treat testing as a checklist: execute the test cases, file the bugs, repeat. Senior-leaning candidates ask "what's the actual risk here?" and prioritize accordingly. The fastest way to signal maturity in an interview is to explicitly reason about risk and time rather than just thoroughness.

💡
The interviewer's real question: "Can I trust this person to be the last line of defense before we ship something broken?" Every question they ask is really this question in disguise.

Curiosity about the product. Interviewers notice candidates who researched the product they're testing. Not just the company — the product. The candidate who scanned the company's site before the interview and can say "I noticed your checkout doesn't have a Content-Security-Policy header — that's a common finding I'd flag on day one" will be remembered long after every other candidate has blurred together.

2. The 5 question categories every QA candidate must master

QA interviews cluster questions into five predictable categories. Candidates who prepare across all five avoid the most common failure mode: being strong in two categories and blank in three.

Category 1 — Manual Testing Fundamentals
Q1 What is the difference between verification and validation?
Verification asks "are we building the product right?" — it checks spec conformance through reviews. Validation asks "are we building the right product?" — it tests against real user requirements. Classic example: you can verify a form has required fields (spec-compliant) while validation tests whether the form actually works end-to-end for users.
Q2 When would you use exploratory testing over scripted testing?
Exploratory testing wins when the product is new (no spec), when a scripted suite just surfaced anomalies that need human investigation, or when you inherit a codebase with zero documentation. Scripted testing wins in regression cycles where you need repeatable coverage fast. Most real teams need both.
Q3 How do you prioritize which bugs to report first?
Severity × likelihood of user encountering it × proximity to shipping date. A crash on the signup flow that affects 100% of new users beats a cosmetic overlap that affects 0.1% on a niche browser. Always frame bugs in terms of user impact, not technical severity alone — product teams respond to business risk.
Category 2 — Automation
Q1 Playwright vs. Selenium — when would you choose each?
Playwright for new projects: modern API, built-in network interception, parallel execution, and better TypeScript support. Selenium when you're maintaining existing test suites, need broad browser matrix coverage, or the team already has Selenium expertise. Don't rebuild Selenium infrastructure for the sake of it — migration cost is real.
Q2 How do you prevent flaky tests in a CI pipeline?
Explicit waits over fixed sleeps. Stable selectors (data-testid over CSS classes or XPath). Isolated test data per run — never share state between tests. Network stubs for external dependencies. Retry logic for genuinely intermittent infrastructure. And a zero-tolerance policy: a flaky test that passes half the time provides negative value because it trains the team to ignore failures.
Q3 What goes into a CI/CD test pyramid?
Many fast unit tests at the base. A smaller suite of integration tests. A small, curated set of E2E tests that cover critical user journeys only. The mistake is inverting the pyramid: slow E2E suites with no unit tests means a 45-minute CI run and zero developer confidence. E2E tests should be the smoke check, not the primary coverage mechanism.
Category 3 — API Testing
Q1 What do you check when testing a REST API endpoint manually?
Status code (correct for the action), response body (matches schema and expected data), response time (within SLA), error messages (meaningful, no stack traces), boundary conditions (missing required fields, malformed JSON, max-length inputs), and authentication (expired tokens, missing tokens, wrong-scope tokens).
Q2 How would you test an API without documentation?
Intercept network traffic in browser DevTools to reverse-engineer the actual calls. Use Postman's import-from-curl feature. Look for OpenAPI/Swagger endpoints at /api/docs, /swagger, /openapi.json. Test common patterns (pagination via ?page=, filters via query params). Document findings as you go — the test process creates the spec.
Q3 What's the difference between load testing and stress testing?
Load testing validates behavior under expected peak load — "does it handle our projected Black Friday traffic?" Stress testing pushes past designed limits to find the breaking point — "where does it actually fail?" Load testing confirms SLAs. Stress testing reveals failure modes and recovery behavior. Both matter, and they answer different questions.
Category 4 — Performance & Security
Q1 What performance metrics matter for a web application?
Core Web Vitals: LCP (largest contentful paint, target <2.5s), CLS (cumulative layout shift, target <0.1), INP (interaction to next paint, target <200ms). Time to first byte, total blocking time, and page weight for mobile. Real user monitoring data beats lab data — what your fastest users see isn't what your median user experiences.
Q2 What's a Content Security Policy and why would a QA engineer flag its absence?
A CSP is an HTTP response header that tells the browser which sources are allowed to load scripts, styles, and other resources. Its absence means the site is vulnerable to cross-site scripting attacks — malicious scripts can be injected and run in users' browsers. Flagging a missing CSP in a security audit shows you understand both the technical mechanism and the business risk (data theft, session hijacking).
Q3 Name three OWASP Top 10 vulnerabilities and how you'd test for each.
Injection: Submit SQL metacharacters, script tags, and OS commands in all input fields — watch for errors, unusual behavior, or reflected input. Broken authentication: Test password reset flows, session token entropy, concurrent session limits, and whether sessions invalidate on logout. Security misconfiguration: Check HTTP headers (missing CSP, X-Frame-Options, HSTS), default credentials, verbose error messages, and directory listing.
Category 5 — Behavioral & Process
Q1 Tell me about a time you found a critical bug late in the release cycle.
Structure: what the bug was, how you found it, what the production risk was, how you communicated it to the team (clarity and calm matter here), and what the outcome was. The sub-answer interviewers are evaluating: "Can this person deliver bad news without creating panic, and do they have the judgment to assess real severity?"
Q2 How do you decide what not to test when time is short?
Risk-based prioritization: highest user impact paths first, recent code changes second, known fragile areas third. Explicitly document what you're leaving out and why — untested scope with documented rationale is better than pretending coverage is complete. Never let unstated assumptions bite a release.
Q3 How do you work with a developer who pushes back on your bug report?
Lead with reproduction steps, not assertions. "Here's what I did, here's what happened, here's what I expected" is harder to dispute than "this is broken." If the disagreement is about severity, anchor to user impact and business risk, not personal preference. If still stuck, bring in a product manager to arbitrate on user value. The goal is resolution, not being right.

3. The scan trick that makes you memorable

Here's a preparation move almost no QA candidates make: scan the company's website before your interview.

Not browse it — scan it. Run a full automated audit that surfaces accessibility issues, missing security headers, broken links, privacy compliance gaps, and performance problems. Get a structured report with specific findings.

Then walk into the interview ready to say: "I ran a quick audit on your public site before today. I noticed a few things — your checkout flow is missing a Content-Security-Policy header, there are some alt-text accessibility gaps on product images, and your third-party cookie usage might create GDPR exposure if you have EU users. I'd flag these as early priorities."

This does several things at once:

🦅
TestHawk's free scanner does exactly this. Paste any URL, get a full audit in under a minute — accessibility issues, security headers, privacy flags, broken links, performance metrics, and a health score. It's free and takes 30 seconds. Try it on the company you're interviewing at →

If you want to go further, use TestHawk's Playwright learning path to build automation skills you can reference in the interview, or generate a professional PDF report via the Interview Report Builder in QA Lab to bring as a leave-behind.

4. Common mistakes QA candidates make

❌
Memorizing definitions instead of building intuition
You can recite the textbook difference between smoke testing and sanity testing without being able to actually design a smoke test suite. Interviewers probe for intuition, not recall. Prepare by doing: scan real sites, write real test cases, break real things.
❌
Ignoring the business context of bugs
Junior candidates describe bugs technically. Senior candidates describe bugs in terms of user impact and business risk. "The form doesn't validate email format" is a technical description. "New user registrations fail silently for ~15% of inputs, which means we're losing signups we'll never recover" is a business description. Practice translating everything.
❌
Specializing too early in one area
Candidates who only know Selenium, or only know manual testing, are easy to pass over for candidates who have breadth. Companies want someone who can cover manual testing on Monday, review an API test suite on Tuesday, and flag a privacy compliance gap on Wednesday. Build enough breadth to have an opinion across all five question categories before you specialize.
❌
Not researching the company's stack
If the job description mentions Playwright and you only know Selenium, say so — but add that you've been building Playwright skills and can show them a test you wrote. If they mention React, understand that SPAs have different testing patterns than server-rendered pages. Tailor your examples to their context, not a generic context.
❌
Treating the interview as a one-way interrogation
The strongest candidates ask questions that reveal domain knowledge: "How does your current test suite handle flakiness in CI?" or "What's your process when QA and engineering disagree on severity?" These questions show you've thought about the job, not just the offer. They also give you signal on whether this is actually a team you want to join.

5. Free resources to keep preparing

Everything below is free. Build a structured prep routine using these — the candidates who land QA roles aren't the ones who cramped a few days before. They're the ones who put in 2–4 hours a week for 4–6 weeks.

🎓
QA Lab
530+ Q&As, 5 learning paths, 6 hands-on labs, and an Interview Readiness Score.
🎭
Playwright Path
Structured Playwright learning from zero to a test suite you can show in interviews.
✅
Interview Checklist
The 30-point checklist that covers everything to prepare the week before your interview.
💸
Pricing
Full QA Lab access with the Interview Report Builder to bring real findings to your interview.

Ready to actually prepare?

TestHawk's QA Lab has 530+ practice questions, structured learning paths, and the scan tool that lets you show up to your interview with real findings about the company you're joining. One-time access.

🎓 Start with QA Lab Get the Free Checklist →