What Do QA Engineer Interviews Actually Test?

Who's in the room and what they're checking

For a QA engineer role, the person running the interview is usually the QA lead or test manager, sometimes with a developer or the engineering manager sitting in for at least one round. If the company has a dedicated automation team, you may get a separate round with a senior SDET whose only job is to check whether your code is any good, not just your testing instincts. Smaller companies sometimes skip the QA specialist entirely and have a developer interview you, which changes the questions: expect more focus on code and less on test strategy or defect management.

What they're checking, underneath the small talk, is whether you can find problems a developer would miss, whether you can explain a bug so precisely that someone else can reproduce it without asking you a follow-up question, and whether you understand why a test exists rather than just how to run it. None of that shows up if you only rehearse definitions of testing terms.

The practical exercise: what it actually looks like

Most QA interviews at mid-size and larger companies include some form of hands-on assessment, not just conversation. The common formats:

• Live exploratory testing. You're given a small web app, a staging build, or sometimes just a public site, and asked to find bugs in fifteen or twenty minutes while narrating your thinking out loud. What they're watching is your method: do you start with the obvious happy path and stop there, or do you move into boundary values, unexpected input, session handling, browser back-button behaviour, and concurrent actions?
• Test case design on paper or a shared doc. You're given a feature description, sometimes as vague as a single sentence like "a user can reset their password", and asked to write test cases. This checks whether you think about negative cases, expired tokens, rate limiting, and account states, not just whether you can format a spreadsheet.
• A bug report exercise. You're shown a defect and asked to write it up, or you're given a badly written bug report and asked to critique it. They're looking for steps to reproduce, environment details, expected versus actual result, and a sensible severity/priority split — not a paragraph of prose.
• An automation coding task. For SDET-leaning roles, you'll be asked to write or extend a test using Selenium, Playwright, or Cypress, sometimes against a real test app they provide. Interviewers care about selector strategy (do you reach for a fragile XPath or a stable data-test attribute), waits (explicit versus arbitrary sleep calls), and whether your test would survive a minor UI change.
• A SQL or API exercise. If the role touches backend testing, expect a query task — validating data integrity after a migration, or checking a join for duplicate records — or a request written in Postman against a documented API, checking status codes, response schema, and error handling.

Take-home assignments are common for QA roles specifically because the work itself is asynchronous and written — a company can learn a lot from how you structure a test plan or a bug report with no time pressure, which is harder to fake than a live conversation.

Questions that sound like small talk but aren't

Some questions look like warm-up chat but are doing real diagnostic work.

"Walk me through a bug you found that nobody else caught." This isn't asking for a war story. It's checking whether you understand why the bug was missed — was it an edge case in date handling across time zones, a race condition under load, a regression introduced by a dependency bump — and whether you can describe the reasoning that led you there rather than just the outcome.

"How would you test a login form?" Everyone can list username, password, submit. The answer that shows competence covers account lockout after repeated failures, session expiry, password field masking, autofill behaviour, SSO redirect handling if it applies, and what happens when the backend is slow or down. It also prioritises: which of those would you test first if you had one hour, and why.

"What's the difference between a smoke test and a regression suite, and when do you run each?" The definitions are in any textbook. What separates a real answer is placing them in a pipeline: smoke tests run on every build to catch a broken deploy fast, regression suites run before a release or on a schedule because they're slower and more expensive, and a mature team tags tests so CI can choose which subset to run based on what changed.

"Tell me about a time you disagreed with a developer about whether something was a bug." This is testing judgement and communication under disagreement, not conflict-avoidance. A good answer names the actual criterion used to resolve it — the spec, the acceptance criteria, a product decision — not just "we talked it through."

"How do you decide what not to test?" This is one of the most revealing questions in the whole interview, because untestable scope and risk-based prioritisation are things a shallow candidate has never had to think about. Someone who has shipped under a deadline will talk about risk, usage frequency, and blast radius. Someone who hasn't will say "I try to test everything."

What a shallow answer sounds like

An experienced interviewer can tell within a minute or two when a candidate is reciting rather than reasoning. The tells are specific:

• Defining terms — smoke testing, sanity testing, regression, exploratory testing — correctly but never connecting them to a pipeline, a release cadence, or a real decision about when to run which.
• Saying "I test edge cases and boundary values" without naming a single edge case for the feature actually in front of them.
• Describing automation experience only in terms of tools used ("I've used Selenium and Cypress") with no mention of what made a suite flaky, how they debugged a failing test in CI, or how they decided what to automate versus leave manual.
• Writing a bug report in the exercise that has a description but no steps to reproduce, no environment, and no clear severity — which is exactly the kind of report that gets bounced back by a developer in real teams.
• Answering "how would you test X" with only the happy path, or with an exhaustive list that shows no sense of priority when asked what they'd do with limited time.
• Claiming familiarity with a specific tool — TestRail, Zephyr, BrowserStack, JMeter — but being unable to describe one specific thing they did in it beyond "logged test results."

None of these are disqualifying on their own. Everyone has gaps. The problem is when every answer has the same shape: correct vocabulary, no evidence of having actually made the decisions that vocabulary describes.

What to do before you walk in

Pick two or three bugs from your own work that you can describe in under ninety seconds each: what the symptom was, how you isolated the cause, and why it mattered. Have one example ready where you disagreed with a developer or product owner about severity and how it was resolved. If the role lists a specific automation framework, write a small test in it beforehand rather than only reading about it — interviewers ask about locator strategy and waits because those are the things that separate someone who has run a suite from someone who has copied one. If a take-home or live exercise is likely, treat the bug report format as seriously as the bug itself; a clean, reproducible report is often what the interview is actually scoring.

And read the job advert itself closely before the call — the tools, the test types, and the release process it mentions (manual regression, CI-driven, exploratory-only) tell you which of the questions above will matter most. jobmarket.pro reads that advert in full and prepares an application from your actual work history against it, so the fit it points you towards is one you can defend under the kind of questioning above.