QA interview in 2026: how to prepare and what's actually asked

A QA interview tests not so much the volume of your knowledge as how you think: can you break a task down structurally, tell severity from priority, explain a decision, and argue without aggression. Below — a prep map: what’s asked by section and how to answer to stand out.

What an interview usually consists of

Testing theory (types, levels, test-design techniques).
Practice: “test X” and/or write test cases / a bug report.
API / SQL — a basic level almost everywhere.
Automation — if it’s a QAA role (locators, waits, flaky, architecture).
Behavioral: conflicts, prioritization, working with the team.
Your questions for the company (yes, this is evaluated too).

Theory: what’s actually asked

Test-design techniques: equivalence classes, boundary values, decision tables, pairwise, state transitions. Not definitions for their own sake — the ability to apply them.
Severity vs Priority: severity — how badly it breaks (technical severity), priority — how urgently to fix (business). The classic: a typo in the logo on the homepage = low severity, high priority.
Levels and types: unit/integration/e2e; smoke/regression/sanity; functional vs non-functional.
Pyramid/Trophy: where there should be more tests and why (fast and cheap — lower).
Terminology baseline — via ISTQB Foundation (even if you don’t take the cert, it’s a shared vocabulary).

”Test X”: a framework, not a stream of cases

The main mistake — dumping random cases. The interviewer wants to see structure. First ask clarifying questions (what product, who’s the user, what are the requirements), then go along the axes:

Functionality: the main happy path — does it work as intended.
Data and boundaries: empty, min/max, over the limit, special chars, format.
Negative: invalid input, errors, failures — a clear reaction.
Non-functional: performance, security, accessibility, localization.
Environment/compatibility: devices, OS, browsers, network, orientation.
Integrations and states: dependent systems, interruptions, recovery.

Example “test a login form”: happy path → empty fields, boundary length, wrong password, lockout after N attempts, SQL/XSS in fields, paste password, show/hide, forgot password, session, slow network, different browsers, screen reader. It shows thinking, not memorization.

Bug report at the interview

If asked to write a bug — give a reproducible structure: title (the gist briefly), environment, steps, actual result vs expected, attachments (log/screenshot), severity and priority. The key — that the bug can be reproduced from the report without you.

API and SQL — the minimum that’s asked

API: methods (GET/POST/PUT/PATCH/DELETE), response codes (2xx/4xx/5xx, the difference between 401 and 403), idempotency, status vs body, how to test REST (positive/negative/boundaries/authorization).
SQL: SELECT with WHERE, JOIN (inner/left), GROUP BY/COUNT, simple subqueries. People often trip on JOINs and on “find the duplicates”.

Automation (for QAA)

Locators: why resilient ones (data-testid/role) beat brittle index-based XPath.
Waits: explicit/auto-wait instead of sleep; why sleep is a source of flakiness.
Flaky tests: causes (timing, shared data, isolation) and how to fight them.
Architecture: Page Object and why; where to draw the layer boundary.
What to automate and what not (ROI, stability, the pyramid).

Behavioral: answer with STAR

The STAR structure (Situation — Task — Action — Result) turns “well, there was this time…” into a clear story. Common questions:

Conflict with a developer (“it’s not a bug, it’s a feature”) — how you reached agreement.
A release shipped with a bug — what you did and what you learned (without shifting blame).
How you prioritize under time pressure (risk-based).
How you delivered bad news to stakeholders (problem + options + recommendation).
Tell us about the hardest bug — what it was and how you found it.

Prepare 4–5 real stories in advance and reuse them across different questions.

Your questions for the company (and red flags)

At the end it’s almost always “any questions?”. Silence = a minus. Ask about processes and the quality culture:

How is the release cycle set up and who’s responsible for quality? Is there automation and CI?
How are bugs filed and prioritized? Are there quality metrics?
How does QA get involved early (requirements, design)?
Red flags: “QA should catch all bugs”, no process, manual deploy on Friday evening, the tester = the only quality gate, overtime as the norm.

Preparation: a week out and a day out

A week out

Review test-design techniques and severity/priority on examples.
Solve 5–10 SQL tasks (JOIN, GROUP BY) and poke at an API in Postman/Bruno.
Prepare 4–5 STAR stories; say them out loud.
Run 2–3 “test X” exercises with the framework (a form, an elevator, a cart).
Study the company’s product — test it and come with observations.

A day out

Re-read your framework for answering “test X”.
Prepare questions for the team.
Check your tech for the online format (camera, screen sharing, coding environment).
Get sleep — it genuinely affects how structured your answers are.

Preparation checklist (10 points)

I know test-design techniques and apply them, not recite them.
I clearly explain severity vs priority with an example.
I have a framework for “test X” (axes, not a stream of cases).
I can write a reproducible bug report.
API: response codes, methods, how to test REST.
SQL: SELECT/WHERE/JOIN/GROUP BY confidently.
For QAA: locators, waits, flaky, Page Object.
4–5 STAR stories ready and rehearsed.
I have 4–5 questions for the company; I know the red flags.
I’ve studied the company’s product and come with observations.

Bottom line

A strong candidate stands out not by the number of memorized definitions, but by their structure of thinking: breaking “test X” into axes, separating severity from priority, telling a STAR story, and asking smart questions about processes. Prepare not by “reading the theory”, but by saying it out loud — the interview is a spoken genre.