L4 / IC3 · 2–5 years
QA Engineer interview prep, what to expect
If you're prepping for a QA or SDET loop, the biggest shift to plan for is that the bar moved to code. Most mid-level QA interviews now include a coding screen that sits just under the SWE bar, and the automation round assumes you've built and maintained a real suite, hunted flaky tests, and argued about what belongs in CI.
A typical loop runs: recruiter screen, a coding screen, a test-design round (enumerate the cases for a feature, then defend what you'd automate), a practical automation or API-testing round, and behavioural with the hiring manager. Big tech hires this role under SDET or SETI titles and pulls from the SWE question pool; smaller companies compress to three or four rounds with more hands-on exercises.
The IC3 bar is owning quality for a product surface: the automation suite, the CI quality gates, the release call, and the escape rate your team gets judged on.
Make it yours
This guide is the general bar at QA. Paste your actual job and Calibrd makes it personal: exactly what that company asks, where your CV is thin, and a full round you rehearse out loud until you're ready. Calibrd reads your level off your CV, from intern to director. Reports are free, up to three a day.
2026 update
This guide covers the general bar at QA. A few things have changed in 2026, AI is now allowed in coding rounds at Canva and Meta, detection has improved at companies that still ban it, comp has split at staff+, and the post-onsite wait got longer. Read what changed in 2026 →
What you'll be expected to do
- Own the test strategy for a product surface: what gets covered by unit, integration, and end-to-end tests, and what stays manual
- Build and maintain the automated suite (Playwright, Cypress, or Selenium, plus API-level tests) and keep it fast enough that engineers trust it
- Quarantine and root-cause flaky tests so a red CI run means something
- Run risk-based exploratory testing on new features and bring data to the ship / hold call
- Push testability into the codebase with engineers: seams, test hooks, seeded environments, realistic test data
- Track the numbers quality is judged on: escape rate, flake rate, time-to-feedback
Typical interview process
Most companies follow a similar shape for QA interviews. Total calendar time: 3–5 weeks from recruiter screen to offer.
Sample questions you should be ready for
Representative of what companies ask at this level, not a complete list. Run the free scan above for predicted questions tied to a specific job posting. Calibrd adds voice practice with AI coaching on every answer (technical, system design, behavioural, motivation), and a full voice mock interview: a live round with an AI interviewer who has read the role and your CV, then an honest debrief.
- “A test fails one run in ten and passes on retry. Walk me through finding the cause, and what you do with the test while it's still flaky.”
- “Write the test cases for a date-range picker used to book flights. Which ones would you automate, which stay manual, and why?”
- “Your UI suite has 4,000 tests and takes three hours. Get feedback under 15 minutes without deleting coverage. What goes where?”
- “Design the test automation framework for a web app with 40 engineers shipping daily. Cover the pyramid split, environments, test data, and reporting.”
- “Design the quality gates for a pipeline that deploys 20 times a day. What runs on every commit, what runs nightly, and what actually blocks a deploy?”
- “Design the load-testing plan for an e-commerce checkout ahead of a sale event. What do you measure, and which number says don't launch?”
- “Tell me about the worst bug that reached production on your watch. How did it get past the tests, and what changed afterwards?”
- “Describe a time you argued a release should be blocked. What evidence did you bring, and how did it land?”
- “Tell me about a bug report an engineer pushed back on. How did you make the case?”
Compensation benchmark
Median compensation for QA at major US tech companies, headline numbers in USD. Pay in markets like London, Berlin and Singapore tends to be meaningfully lower in base terms, and equity ratios vary by company stage.
Big-tech SDET and SETI ladders (Google, Amazon, Microsoft) pay close to the SWE band at the same level, roughly $220–300k total at IC3. Automation-light QA roles price 20–30% under that, which is the financial case for clearing the coding bar.
How to prep, five tactical tips
Lead behavioural answers with the STAR method, Situation, Task, Action, Result. The tactical tips below build on that structure for this specific role.
- Drill LeetCode easys into mediums for 4+ weeks (arrays, strings, hash maps). The SDET coding bar at big tech sits just under SWE, and it's where most QA candidates get filtered
- Build a small Playwright suite against a public demo app before the loop. The practical round grades locator strategy, waits, and flake handling, and answers from experience sound different from answers from docs
- Practise test-case enumeration out loud: pick any feature and list 20 cases in five minutes, grouped into happy path, boundary, permission, and failure mode. The test-design round is a structured-thinking round; volume alone loses it
- Read the testing chapters of Software Engineering at Google (free online, linked below). The small / medium / large test vocabulary and the flake-budget mindset come from there, and interviewers use both
- Prepare 4–5 bug stories with numbers: how the bug was found, the escape impact, and what test or gate changed because of it. "I found a lot of bugs" pegs you as junior
Where QA candidates fail
A few common mistakes that get QA candidates rejected even when they're otherwise strong. Worth spotting in a mock interview before they show up in a real one.
Answering the test-design round with a long flat list of happy-path cases.
Why it fails
The round grades structure: risk categories first (boundaries, permissions, concurrency, bad data), then cases inside each. Twenty unranked cases signal checklist QA; the hire signal is finding the two cases that would actually block the release.
Fix
Group out loud before you enumerate: "I'd split this into functional, boundary, permission, and failure-mode cases, and start where release risk is highest." Then fill in. The grouping sentence alone changes how the round is scored.
Talking about flaky tests as something you retry rather than something you own.
Why it fails
Flake handling separates the SDET from the script-runner in most loops. "We re-run it and it usually passes" tells the interviewer the suite gates nothing. The expected vocabulary is quarantine, root-cause, and a flake budget managed the way SREs manage error budgets.
Fix
Describe a policy rather than an incident: quarantine on first flake, root-cause within the sprint, track the flake rate over time, and delete tests that cost more than they catch.
Positioning yourself as the person who finds bugs instead of the engineer who makes them impossible.
Why it fails
Finding bugs is the junior half of the job. The IC3 bar is systems: the automation, the CI gates, and the testability pushes that remove a whole class of escapes. Stories that end at "so I filed the ticket" cap the level assessment.
Fix
Extend every bug story one step past the fix: the test, gate, or code change that means this class of bug can't ship again. That last step is the level signal.
Recommended resources
Books, courses, and tools that come up most often in QA prep. No affiliate links.
- 01Software Engineering at Google — testing chapters →Free online. Chapters 11–14 are the source of the small / medium / large test sizes and the flaky-test discipline this guide leans on; interviewers at big tech use the same vocabulary.
- 02Martin Fowler, The Practical Test Pyramid →The canonical version of the pyramid split the framework-design round asks for. Worth citing directly when you defend what you'd automate.
- 03Google Testing Blog →Where flaky-test policy gets debated in public, including the posts behind the quarantine-and-root-cause pattern above.
- 04Playwright documentation →The framework most current web loops assume. The auto-waiting and locators guides answer the exact questions the practical round asks.
- 05Test Automation University →Free structured courses from Applitools. The fastest on-ramp if you're moving from manual QA into automation.
Common scenarios
How do I move from manual QA into an SDET role when my current job has no automation in it?
Build the proof yourself, because the interview will ask for it. Pick one stack (TypeScript + Playwright is the safest bet), automate 15–20 scenarios against a public demo app, put it on GitHub with a README explaining your locator strategy and how you handle waits and flakes. That repo becomes your answer to half the practical round. In parallel, drill LeetCode easys into mediums for 8–12 weeks, since automation-first teams filter at the coding screen before anyone looks at your test skills. Apply to titles that say SDET, QA Automation, or Test Engineer rather than plain QA Analyst; the loops match the prep described in this guide. An ISTQB certificate helps with consultancies and enterprise IT in Europe but carries little weight at product companies.
Is the SDET coding interview as hard as the software engineer one at big tech?
Same question pool, slightly more forgiveness. Google, Amazon, and Microsoft pull SDET coding questions from the SWE bank, mostly LeetCode easy-to-medium on arrays, strings, and hash maps, and grade on working code plus how you test it. Where a SWE candidate might need the optimal solution quickly, an SDET candidate usually passes with a clean correct solution plus strong test-case reasoning about their own code. The trap is assuming the bar is low: most rejected QA candidates fail here, not on test knowledge. Four weeks of daily drilling covers it; the guide's prep plan splits time half on coding, half on automation for exactly this reason.
How should I approach a QA take-home that asks me to automate a demo website?
Reviewers grade structure, not scenario count. Five well-organised tests beat twenty brittle ones. Use page objects or a similar separation so a UI change touches one file, prefer role- and text-based locators over CSS chains, rely on the framework's auto-waiting instead of sleeps, and make assertions specific enough to fail usefully. Then spend 30 minutes on the README: what you covered, what you deliberately skipped, how you'd scale it to CI, and how you'd handle flakes. That README is often the tiebreaker, because it shows the judgment the on-site would otherwise have to probe for. Submitting a day early with a smaller, cleaner suite is the right trade.
What do I say when an interviewer asks why I chose QA instead of software engineering?
Answer with ownership, never with apology. The losing versions are "I'm working toward a developer role" (tells them you'll leave the function) and "I fell into it" (tells them nobody chose you). The winning version names what the role uniquely owns: you sit where the release decision gets made, you build the automation other engineers depend on, and you're the person who knows how the system actually fails. If you do want to move to SWE eventually, keep that out of this loop; interviewers hire for the role in front of them. A concrete story about a release call you made or a bug class you eliminated lands the point better than any framing sentence.
Frequently asked questions
I've done five years of manual QA. Does this guide still apply to me?
Yes, and the gap to close is specific: the coding screen and the practical automation round. The test-design and behavioural rounds will play to your strengths, since manual QA builds exactly the case-enumeration and bug-advocacy skills those rounds grade. Budget 8–12 weeks: one language (Python or TypeScript), LeetCode easys into mediums, and a small Playwright suite you built end to end. Automation-first teams filter at the coding screen, so that's where the prep time goes.
How long should I prep before my QA onsite?
Loops run 3–5 weeks. Give yourself 6–8 weeks of prep, split roughly half on the coding screen and half on one automation project you can defend in detail. Practise test-case enumeration out loud; it's the round people wing and lose.
What's the most common mistake candidates make at the QA bar?
Underestimating the coding round. QA candidates prepare test theory, then get filtered by a LeetCode-medium, because at big tech the SDET coding bar sits just under SWE. Four weeks of drilling moves more than any amount of framework knowledge.
What if my interview process is different from what's listed?
Most variation is at the edges. Major tech companies (FAANG, scale-ups, mid-size SaaS) follow processes within 1–2 rounds of what's described. Smaller startups often run fewer rounds (3–4) but the bar at each round is similar; less-tech-mature companies sometimes skip system design or behavioural rounds entirely. Read the JD and ask the recruiter at the screen, they'll tell you what's coming.
How does this guide compare to running a free scan?
This guide covers the general bar at L4 / IC3. The free scan reads your specific job description and returns predicted questions for that exact role + company, a calibrated comp benchmark, and (with your CV) experience-gap analysis and an ATS resume check. PDF emailed.
Walk in ready
Walk into your next QA interview ready.
Paste your actual job and Calibrd shows you exactly what that company asks, where your CV is thin, and what it should pay. Then rehearse the round out loud with honest feedback until you're confident. Any tech role. Free to start.
Free to start, 8 coaching credits · No credit card · Your CV stays on your device