Free download. Use it offline or customize it for your company.
Welcoming questions
Can you tell us about yourself and the products you have tested?
What to look for: A strong answer connects specific products and testing contexts to the skills your role needs, rather than reciting a resume chronologically.
Sample answer: I have spent the last four years testing SaaS products, most recently a B2B invoicing platform where I owned QA for the payments module. I started out doing mostly manual regression, then built the team's first Playwright suite, which now covers about 60 percent of our critical flows. Before that I tested a consumer mobile app, so I have seen both fast-release web environments and app store release cycles.
What drew you to quality assurance work?
What to look for: Look for genuine curiosity about how software breaks and pride in preventing user pain, not a story of QA as a fallback from development.
Sample answer: Honestly, I discovered I was the person on every team who found the weird edge cases, and I enjoyed it. There is a puzzle-solving element to figuring out why something fails only on the third submission or only in Safari. I also like that QA sits at the intersection of the product and the user: when I catch a bug before release, I know exactly who I just saved from a bad day.
Role-specific and technical questions
How do you design test cases for a new feature? Walk us through your method.
What to look for: Strong candidates start from requirements and risk, cover negative and boundary cases explicitly, and prioritize; a red flag is jumping straight to happy-path clicks.
Sample answer: I start with the spec and write down what the feature promises, then I list the ways each promise could break: invalid inputs, boundary values, permission differences, and state conflicts. From there I group scenarios by risk, so a payment calculation gets exhaustive coverage while a cosmetic label gets a quick check. I usually sketch this as a one-page test charter and review it with the developer before the code is even finished, because that conversation alone often surfaces gaps in the spec.
Which automation frameworks have you used, and how do you keep suites stable and fast?
What to look for: Listen for concrete stability tactics like proper waits, test isolation, and parallelization, plus honesty about flakiness they have actually fought.
Sample answer: I have worked mostly with Playwright and some Cypress before that. For stability, the biggest wins were replacing fixed sleeps with condition-based waits, seeding test data through the API instead of the UI, and making every test independent so they can run in parallel. On my last project we cut the CI run from 40 minutes to under 12 by sharding across four workers and deleting tests that duplicated API-level coverage.
How do you decide what to automate and what to keep manual?
What to look for: A strong answer weighs repetition, stability, and risk rather than aiming to automate everything, and reserves human judgment for exploratory work.
Sample answer: I automate what is repetitive, stable, and high-risk: login, checkout, the regression paths we run before every release. I keep manual what needs judgment, like a redesigned onboarding flow where I want to feel the UX, or a brand-new feature whose behavior is still shifting weekly, because automating a moving target just creates maintenance debt. My rough rule is that if I have run the same check by hand three times and the feature is stable, it goes into the suite.
Describe how you test an API beyond the happy path.
What to look for: Expect specifics like invalid payloads, auth boundaries, error codes, idempotency, and rate limits; vague answers signal shallow API experience.
Sample answer: Beyond checking a 200 with valid data, I send malformed and missing fields to verify the error codes and messages are correct, and I test authorization by calling endpoints with the wrong user's token. I also look at contract details: does a duplicate POST create two records or is it idempotent, what happens at pagination boundaries, and does the API behave sanely under a burst of requests. In Postman or in code, I always assert on the response schema, not just the status, because that catches silent contract changes.
What makes a bug report excellent? Show us with an example.
What to look for: Strong candidates name reproduction steps, expected versus actual behavior, evidence, environment, and severity, and clearly care about the developer reading it.
Sample answer: An excellent report lets a developer reproduce the bug in under two minutes without asking me anything. My template is a one-line summary, numbered reproduction steps starting from a known state, expected versus actual result, environment details, and evidence like a screenshot or HAR file. For example, I once reported a rounding bug as: invoice total shows 99.99 instead of 100.00 when three line items of 33.333 are added, with the exact API response attached, and it was fixed the same afternoon because there was nothing left to investigate.
Behavioral and culture fit questions
Tell us about a critical bug you caught late. How was it missed, and what changed afterward?
What to look for: Look for honest ownership and a concrete process change; blaming developers or claiming it never happens is a red flag.
Sample answer: We shipped a release where saved filters silently stopped working for a subset of users, and I only caught it two days later from a support ticket. It was missed because our regression suite covered filter creation but not loading old saved filters with a legacy data format. I added migration-data fixtures to the suite, and we started keeping a small pool of aged production-like accounts in staging, which has since caught two similar issues before release.
Describe a disagreement with a developer about a bug's severity. How did you resolve it?
What to look for: Strong answers ground severity in user and business impact with data, and show the candidate can disagree without turning it personal.
Sample answer: A developer wanted to ship with a bug where the export button failed for files over 10 MB, arguing almost nobody exports files that large. Instead of debating opinions, I pulled usage numbers and found about 8 percent of exports crossed that threshold, mostly from our two biggest accounts. Once we saw whose workflows would break, he agreed to fix it before release, and we now check usage data whenever severity is contested.
How do you advocate for quality when the team is under release pressure?
What to look for: Look for framing quality as risk information for the business rather than gatekeeping, and willingness to propose scoped compromises.
Sample answer: I try not to be the person who just says no. Under pressure, my job is to make the risk visible: here is what has been tested, here is what has not, and here is what could go wrong in each untested area. Then the release decision belongs to the team with open eyes. Often we find a middle path, like shipping behind a feature flag for 10 percent of users, which lets the deadline hold while containing the blast radius.
Problem-solving and case questions
You have one day to test a release that normally takes a week. How do you prioritize?
What to look for: Expect risk-based triage that starts from what changed and what is business-critical, plus clear communication of what will remain untested.
Sample answer: First I read the changelog and diff to see what actually changed, because that concentrates the risk. Then I spend the morning on the critical money paths: signup, login, checkout, and anything the release touched directly, leaning on the automated suite for broad regression while I test the new code by hand. I skip low-traffic settings pages and cosmetic checks, and before sign-off I send the team a short note listing exactly what was covered and what was not, so the residual risk is a shared decision.
A flaky test fails randomly in CI and the team wants to delete it. What do you do?
What to look for: Strong candidates investigate the root cause before deciding, and recognize that flakiness sometimes hides a real race condition in the product.
Sample answer: Before deleting anything, I would quarantine it so it stops blocking merges, then dig into the failure pattern: does it fail only in parallel runs, only at certain times, only on one browser. Roughly half the flaky tests I have investigated were bad waits in the test, but the other half exposed real race conditions, and one of those was a genuine double-submit bug in checkout. If the test covers something important, I rewrite it properly; I only delete it if the coverage is duplicated elsewhere.
Users report a bug you cannot reproduce in any environment. Walk us through your approach.
What to look for: Look for systematic narrowing using logs, environment and data differences, and direct evidence from affected users rather than closing it as cannot reproduce.
Sample answer: I start by gathering everything about the affected users: browser, device, account age, plan type, and locale, because the difference between them and my test account is usually the key. Then I check logs and error monitoring like Sentry for their sessions to see what the system recorded even if I cannot see the failure myself. If that is not enough, I ask support to get a screen recording or a HAR file from one user. The last one of these I solved turned out to be a timezone issue that only triggered for accounts west of UTC-6, which no staging account happened to have.
Generate custom QA Engineer interview questions
Need questions tuned to your industry, seniority level, or interview stage? Describe the role and our AI interview questions generator will draft a set in seconds.
