You join a team with a 30% flake rate in their CI test suite. How do you approach fixing it?

First, instrument — add labels to failures (which test, which env, which time). Most flake is concentrated in 5-10% of tests. Quarantine the most flake-prone tests immediately so they do not block merges, but track them. Categorize root causes: timing/race conditions, test interdependencies (shared state), environment instability, real product bugs. Fix per category — timing flake fixed with explicit waits not arbitrary sleeps, interdependency flake fixed with proper test isolation. Set a flake budget (e.g., 2% target) and enforce it. Most important: prevent new flake by adding pre-merge stability checks (run new tests 10x).

Walk me through how you would write an automation test for a feature you have never tested before.

Read the spec/ticket and the existing manual test cases first. Identify the user journey to automate. Sketch the test on paper — what setup, what assertions, what teardown. Identify selectors that are stable (data-testid attributes > IDs > classes). Write the test in your framework — Playwright/Cypress with page object pattern. Run it locally 5-10 times to check for flake. Add to CI. Document what it covers and what it does NOT cover (manual cases remaining). Most important: do not just translate manual cases 1:1 into automation — automation tests should be designed differently.

Here is an API endpoint. What tests would you write for it?

Categorize. Functional: happy path, valid payload variants, response schema validation. Validation: missing required fields, wrong types, boundary values, malformed JSON. Authentication: valid token, expired token, missing token, wrong scope. Authorization: cross-tenant access attempts, role-based access. Error handling: 4xx/5xx response codes, error message format. Performance: response time under expected load, concurrent requests. Idempotency: same request twice produces same result. Walk through which tool you would use — Postman/RestAssured/Pytest/SuperTest. Most important: contract testing if the API is consumed by other services.

Tell me about a bug you found that the team initially did not believe was a bug.

Pick a real example. Describe the bug and why it mattered (severity, customer impact, edge case probability). Describe the initial response — what was the reason the team dismissed it. Describe what you did to escalate — reproduction steps, impact data, user research, similar prior incidents. Close with the resolution — was it fixed, was it accepted as a known issue, what process changed.

What is the difference between unit, integration, and end-to-end tests, and when do you write each?

Unit: tests a single function or class in isolation, mocks all dependencies. Fast (<10ms), cheap, run on every commit. Write for: branching logic, edge cases, complex calculations. Integration: tests multiple units together, real dependencies (DB, queues) but in test env. Slower (100ms-1s), medium cost. Write for: API contracts, database interactions, service-to-service flows. E2E: tests full user journey through UI/API. Slow (seconds to minutes), expensive, flaky. Write for: critical user paths (signup, checkout, login) and regression of core flows. Pyramid: lots of unit, fewer integration, very few E2E. Modern shift: trapezoid (more integration, fewer unit) as microservices proliferate.

How do you decide what to automate and what to keep manual?

Automate: anything run repeatedly (regression suites), anything with predictable input/output, anything sensitive to small regressions, anything time-consuming to run manually. Keep manual: exploratory testing (where you find unknown unknowns), one-off experiments, UX feedback, accessibility evaluation (some auto-checks exist but human judgment matters), brand-new features where the design is still changing. Automation has cost (maintenance) — only worth it when ROI is positive. Most important: never automate a test that has not been run manually first.

Write a function to check if a string is a palindrome. Then extend it to handle Unicode and whitespace.

Start with the simple version: lowercase the string, compare to its reverse. Discuss complexity (O(n) time and space). Then add whitespace handling: strip whitespace before comparing. Then Unicode: normalize the string (NFC normalization), handle combining characters, consider whether case-folding is just lowercase or full Unicode case-folding. Discuss edge cases — empty string, single character, all-whitespace string. Most important: write the tests for your function before declaring done.

Tell me about a time you owned the on-call or incident response for a release.

Pick a real example. Describe the release scope. Describe how you prepared (test coverage gaps you flagged, rollback plan, monitoring you added). Describe what happened (ideally something went wrong and you caught it). Walk through the response — how you detected, how you communicated, what you did. Close with the postmortem and process change. Even better if you can describe a release that had ZERO incidents because of your prep.

What is your experience with performance and load testing?

Be specific about tools used (k6, JMeter, Locust, Gatling — pick one you actually know). Describe a real load test you designed: what was the SLA you tested against (p99 < X ms), what was the load profile (ramp-up, steady-state, peak), what bottleneck you found. Discuss the difference between load test (sustained expected traffic) vs stress test (find breaking point) vs spike test (sudden traffic). Acknowledge what is hard — getting production-like test data, dependency simulation, environment parity.

How do you stay current with QA tooling and practices?

Be specific. Conferences (STAR/SauceCon if you have been). Newsletters (Test Automation University). Open-source tool exploration — what have you tried in the last 6 months. Community (TestingPodcast, Ministry of Testing). Then mention one specific recent tool or practice you adopted. AI test generation, visual regression with ML, contract testing with Pact, observability-driven testing — pick one you can actually defend.

What metrics do you track for QA effectiveness?

Defect escape rate (bugs that reached production / total bugs found) — primary measure of QA effectiveness. Test coverage on critical paths. Mean time to detect production issues. Test suite flake rate. Test suite runtime. Automation coverage growth over time. Lead time from feature ready to release. Avoid: pure bug count (rewards reporting noise), test case count (rewards busywork). Most important: measure trends, not absolutes — defect escape rate going down quarter-over-quarter is the actual signal.

Where do you see your career going — IC depth or management track?

Be honest about direction. If IC: staff/principal SDET working on test infrastructure, framework architecture, performance engineering. If management: QA manager → director → VP of quality. If unsure, say so and explain how you would figure it out (try a tech-lead role, mentor more, see what energizes you). Acknowledge if you might pivot to adjacent roles — SWE, DevOps, security — that's also valid.

Do you have any questions for me?

Tailor by interviewer. For hiring manager: "What does test infrastructure look like today, and what investment is planned?" For SDET peer: "What is the most painful part of the test stack right now?" For dev manager: "How does engineering view QA — partner, gatekeeper, or after-thought?" Avoid logistics until late.

How long does the QA engineer interview process take?

3-4 weeks for most US companies in 2026. SDET roles at FAANG can stretch to 5-6 weeks. Manual-QA-only roles often close faster (2-3 weeks).

Do I need to know coding for a QA role?

For SDET / Test Automation Engineer roles, yes — you should be able to write functions, handle string/array manipulation, and reason about complexity. For pure manual QA roles, no, but knowing one scripting language (Python or JavaScript) significantly expands your opportunities even for manual-leaning roles.

Are AI-driven testing tools changing the interview format?

Slightly. Some companies now ask how you would integrate AI test generation (Mabl, Testim) into your workflow. The core skills tested (test design, automation fundamentals, debugging) remain identical. AI tools are a question, not a replacement.

Is ISTQB certification useful for QA interviews?

Varies by company type. Strongly valued at large traditional enterprises (finance, healthcare, government). Mostly ignored at tech companies and startups, where automation portfolio matters more. Worth getting if your target is the former; skip it if your target is the latter.

How are entry-level QA opportunities in 2026?

Tighter than in 2022-23. Many companies eliminated junior manual QA roles in 2024-25 layoffs, expecting AI tools to cover that work. SDET entry-level is more available but requires coding fluency. The cleanest entry: a smaller company where you can wear both manual and automation hats and build up framework experience.

Technology$70,000 - $140,000

QA Engineer Interview Questions

Q: Design a test plan for a new login feature with email/password, OAuth, and magic-link options.

Group tests by category before writing cases. Functional: happy path for each auth method, validation of email format, password rules, OAuth token handling. Security: brute-force, account enumeration, token expiry, CSRF, session fixation. Performance: concurrent logins, OAuth callback latency, magic-link rate limiting. Integration: with downstream services (analytics, audit log, billing). Negative: malformed tokens, expired OAuth state, magic-link replay. Cross-browser. Mobile vs desktop. Add boundary conditions for each. Estimate effort and prioritize by user impact × likelihood.

Q: How do you decide what to automate and what to keep manual?

Automate: anything run repeatedly (regression suites), anything with predictable input/output, anything sensitive to small regressions, anything time-consuming to run manually. Keep manual: exploratory testing (where you find unknown unknowns), one-off experiments, UX feedback, accessibility evaluation (some auto-checks exist but human judgment matters), brand-new features where the design is still changing. Automation has cost (maintenance) — only worth it when ROI is positive. Most important: never automate a test that has not been run manually first.

Q: Write a function to check if a string is a palindrome. Then extend it to handle Unicode and whitespace.

Start with the simple version: lowercase the string, compare to its reverse. Discuss complexity (O(n) time and space). Then add whitespace handling: strip whitespace before comparing. Then Unicode: normalize the string (NFC normalization), handle combining characters, consider whether case-folding is just lowercase or full Unicode case-folding. Discuss edge cases — empty string, single character, all-whitespace string. Most important: write the tests for your function before declaring done.

Q: Tell me about a time you owned the on-call or incident response for a release.

Pick a real example. Describe the release scope. Describe how you prepared (test coverage gaps you flagged, rollback plan, monitoring you added). Describe what happened (ideally something went wrong and you caught it). Walk through the response — how you detected, how you communicated, what you did. Close with the postmortem and process change. Even better if you can describe a release that had ZERO incidents because of your prep.

Q: What is your experience with performance and load testing?

Be specific about tools used (k6, JMeter, Locust, Gatling — pick one you actually know). Describe a real load test you designed: what was the SLA you tested against (p99 < X ms), what was the load profile (ramp-up, steady-state, peak), what bottleneck you found. Discuss the difference between load test (sustained expected traffic) vs stress test (find breaking point) vs spike test (sudden traffic). Acknowledge what is hard — getting production-like test data, dependency simulation, environment parity.

What 2026 QA interviews actually test

QA interviews in 2026 have shifted away from "find the bug in this UI" and toward test strategy, automation framework design, and CI integration. SDET-track roles add coding rounds. This guide separates manual-QA-track from SDET-track questions and shows how senior hiring managers score each.

Typical rounds

End-to-end time

3-4 weeks

Questions covered

What the QA Engineer interview loop actually looks like

Recruiter Screen

• Phone call• 30 min

Background, automation experience inventory, comp expectations. Recruiters filter aggressively on automation tool fluency here.

Hiring Manager Screen

• Video call• 60 min

Past projects — go deep on one test framework you built or test strategy you owned. They listen for ownership and decision quality, not tool name-dropping.

Technical Screen

• Live coding or framework discussion• 75 min

For SDET: live coding (medium-difficulty algorithm or test-framework code). For QA: design a test plan for a hypothetical feature, walk through your testing approach.

Onsite Panel

• 3-4 back-to-back interviews• 240 min

Test strategy, automation framework deep-dive, API/integration testing, behavioral. Cross-functional partner (dev manager or PM) usually sits in.

14 QA Engineer interview questions

Tap any question to see what the interviewer is really asking, how to structure your answer, and the red flags to avoid.

What they're really asking

Can you break a feature down into testable areas systematically, or do you just start running test cases? Strong QA candidates always start with structure.

Answer framework

Group tests by category before writing cases. Functional: happy path for each auth method, validation of email format, password rules, OAuth token handling. Security: brute-force, account enumeration, token expiry, CSRF, session fixation. Performance: concurrent logins, OAuth callback latency, magic-link rate limiting. Integration: with downstream services (analytics, audit log, billing). Negative: malformed tokens, expired OAuth state, magic-link replay. Cross-browser. Mobile vs desktop. Add boundary conditions for each. Estimate effort and prioritize by user impact × likelihood.

What a strong answer signals

You start with categories, not individual cases. You include security testing without being prompted. You prioritize, not just enumerate. You ask 1-2 clarifying questions about scope.

Red flags to avoid

•Jumping to specific test cases without grouping
•Missing security and performance categories
•No prioritization framework — treating all cases as equal

How QA Engineer hires actually get decided

Approximate weight hiring committees place on each dimension. Use this to focus your prep on what actually moves the decision.

Automation framework and tool fluency

30%

Can you build and maintain test automation. Single biggest weight for SDET; high for senior QA.

Test strategy and design thinking

25%

How you break down a feature into testable areas. The differentiator between mid and senior QA candidates.

Production / incident response judgment

15%

Increasingly important as the QA-SRE line blurs. Senior+ candidates need this.

Cross-functional collaboration

15%

How you partner with developers and PMs. Adversarial QA candidates fail loops regardless of technical skill.

Coding ability (SDET roles)

15%

For SDET roles, basic algorithm fluency and framework-level coding. Lower weight for pure QA roles.

How to prepare for a QA Engineer interview

Build a real automation framework as your portfolio piece

Theoretical answers about automation lose to specific examples. Pick a public website, build a 20-test Playwright or Cypress suite with page object pattern, CI integration, reporting, and flake handling. Push to GitHub. Walk every interviewer through it.

Memorize one bug taxonomy framework

For "find the bug" or "design a test plan" questions, having a mental framework (functional / security / performance / accessibility / integration / negative / boundary) prevents you from spotting only obvious issues. Practice with public bug bounty writeups.

Know your tools to the keyboard-shortcut level

If your resume says Playwright, you should be able to write a basic test live without IDE autocomplete. Tool-fluency questions weed out resume inflation fast.

Prepare 3 incident stories at increasing severity

Low: a unit test gap you caught in code review. Medium: a regression you found that delayed release. High: a production incident you investigated. Senior QA loops weight your incident vocabulary heavily.

For SDET roles, do 20 LeetCode medium problems

SDET coding screens are slightly easier than SWE screens but still real. Focus on string manipulation, hashmap problems, basic graph/tree, and array two-pointer patterns. Skip advanced DP and bit manipulation.

QA Engineer interview FAQs

More for QA Engineers

QA Engineer resume example QA Engineer cover letter QA Engineer salary guide Skills for QA Engineers How to become a QA Engineer

Interview prep for related roles

Software Engineer interview questions

Technology • $80,000 - $180,000

DevOps Engineer interview questions

Technology • $90,000 - $180,000

Frontend Developer interview questions

Technology • $70,000 - $150,000

Backend Developer interview questions

Technology • $80,000 - $160,000

Data Analyst interview questions

Technology • $60,000 - $120,000