QA Engineer
Interview Questions.

What the interviewer is looking for: Strong answers automate stable, repetitive, high-value regression paths and keep exploratory and one-off checks manual, weighing maintenance cost. Trying to automate 100% of everything is a red flag.

What the interviewer is looking for: Look for risk-based prioritisation — critical user journeys, recent changes, and high-impact areas first. Testing in random order or trying to test everything equally is a red flag.

What the interviewer is looking for: A strong answer distinguishes a broad shallow build-verification (smoke), focused re-check of a fix (sanity), and full re-verification after changes (regression). Blurring the three suggests limited process experience.

What the interviewer is looking for: Strong candidates suspect timing/implicit waits, use explicit waits, stabilise selectors, and isolate test data. Adding sleep() everywhere to mask flakiness is a red flag.

What the interviewer is looking for: Look for auto-waiting, faster and more reliable execution, built-in tracing, and modern browser support. Not being able to articulate any concrete advantage is a red flag.

What the interviewer is looking for: Strong answers cover status codes, schema validation, boundary and error inputs, auth, and chained requests with assertions. Only checking that a 200 comes back is a red flag.

What the interviewer is looking for: Look for querying the database to assert state, checking edge cases and referential integrity, not just trusting the UI. Being unable to write a basic verification query is a red flag for a QA role.

What the interviewer is looking for: Strong candidates structure the test clearly, assert on meaningful outcomes and negative cases, and keep it independent. Asserting only that the page loaded, with no negative test, is a red flag.

What the interviewer is looking for: Strong answers separate page structure from test logic, reuse page objects, and keep selectors in one place for maintainability. Tests with hardcoded selectors and duplicated logic scattered everywhere are a red flag.

What the interviewer is looking for: Look for treating test code as real code — branches, PRs, and review — and keeping it in sync with the feature it tests. Untracked local scripts or test code that drifts from the app are red flags.

What the interviewer is looking for: Look for clear repro steps, expected vs actual, environment, severity/priority, and evidence like logs or screenshots. Vague 'it does not work' reports are a red flag.

What the interviewer is looking for: Strong answers define load profiles and SLAs, ramp gradually, and measure latency percentiles and error rates under load. Reporting only average response time is a red flag.

What the interviewer is looking for: Look for calm, evidence-based collaboration — reproducible steps, environment details, and shared debugging — rather than escalating emotionally. Backing down without evidence, or antagonism, are red flags.

What the interviewer is looking for: Strong candidates value exploratory testing, edge cases, and a user's-eye view of the whole experience. Relying solely on the automation suite is a red flag.

What the interviewer is looking for: Look for a layered test pyramid, fast checks on every commit, and heavier suites gated appropriately, plus reliable (non-flaky) tests. A slow, flaky suite that blocks releases is a red flag.

What the interviewer is looking for: Strong answers reflect honestly, avoid blame, and describe a systemic improvement to coverage or process. Claiming nothing ever escaped, or blaming developers entirely, are red flags.

What the interviewer is looking for: Look for shifting testing left, involving QA early in design, and shared ownership of quality. Positioning QA as the last gate that catches everything is a red flag.