How QA engineer interviews work
QA engineer interviews test both theoretical testing knowledge and practical skills. For manual testing roles, expect questions on test case design, defect lifecycle, test planning, and exploratory testing techniques. For automation roles, expect coding questions in the target language (Python, Java, or JavaScript are most common), questions on automation frameworks (Selenium, Playwright, Cypress, Appium), and system design for test infrastructure. Senior QA and SDET roles add test strategy, CI/CD integration, and quality metrics questions.
The seniority of the role shapes what is emphasised. Entry-level QA interviews are heavy on fundamentals: what is a test case, what is a bug report, how do you prioritise defects. Senior SDET or Quality Lead interviews focus on test architecture, shift-left testing strategy, reducing toil, and quality culture rather than individual test execution.
Testing fundamentals questions
"What is the difference between verification and validation?" Verification checks that you built the product right (against requirements). Validation checks that you built the right product (it solves the user's actual problem). Verification happens at every stage (code review, unit tests, acceptance tests). Validation happens when real users confirm the product does what they actually need. Both matter: a perfectly verified product that solves the wrong problem still fails.
"What are the main test levels and when do you use each?" Unit tests: fast, developer-written, test individual functions in isolation. Integration tests: test that components work together correctly. System tests: test the full system end-to-end. Acceptance tests: validate against business requirements. The testing pyramid concept suggests most tests should be unit tests (cheap, fast) with fewer integration tests and even fewer end-to-end tests (slow, expensive, brittle). Most real codebases are inverted from this ideal and have too many slow end-to-end tests relative to fast unit tests.
Test case design questions
"How would you write test cases for a login form?" Strong answer covers: positive cases (valid email/password, remember me, password visibility toggle), negative cases (wrong password, wrong email, empty fields, invalid email format, very long inputs), boundary cases (maximum length email, special characters), security cases (SQL injection in the fields, repeated failed attempts and lockout, password reset flow), and accessibility cases (keyboard navigation, screen reader labels). Show that you think systematically across categories rather than listing obvious cases.
"How do you decide how much testing is enough?" This is a judgment question, not a technical one. Strong answer: testing is risk-based. I consider the probability of failure in each area, the impact of that failure on users or the business, and the cost of testing. I invest most testing effort in high-impact, high-risk areas. I accept lower coverage in low-risk, low-impact areas. I track defect escape rate as a lagging indicator to validate whether my risk assessment was right.
Automation questions and example code
"What is the Page Object Model and why is it used in Selenium or Playwright tests?" The Page Object Model (POM) is a design pattern where each page of the application is represented as a class, with methods representing user actions on that page. Benefits: test code becomes more readable (tests read like user journeys, not raw locator strings), changes to the UI only need to be updated in one place (the page class), not across every test that touches that page. Anti-pattern to mention: tests that directly call driver.find_element in every test method, making maintenance a nightmare.
"How would you approach automating tests for an API?" Strong answer: use a tool like REST Assured (Java), pytest with requests (Python), or Supertest (Node). Test: status codes, response body schema validation, response data correctness, error handling (what does the API return for invalid inputs?), authentication (token required, token expired, insufficient permissions), and performance (response time under expected load). Treat API tests as the most valuable layer of your automation suite because they are faster and less brittle than UI tests.
Test strategy and quality culture questions
"How would you implement shift-left testing in a team that currently does all testing at the end of the sprint?" Shift-left means involving QA earlier in the development lifecycle. Practical steps: involve QA in requirements review before a story is written (catching ambiguity early), write test cases as acceptance criteria in JIRA before development starts (so developers know the definition of done), run unit and integration tests in the CI pipeline so failures are caught before code review, and do exploratory testing on features as they are completed rather than all at once at sprint end.
"How do you measure the quality of a testing effort?" Leading indicators: test coverage (code, requirement, risk), defect detection rate (what proportion of defects did testing find vs production), test execution time (how fast is the CI pipeline). Lagging indicators: production defect rate, defect escape rate, customer-reported issues. Show that you think about both leading and lagging metrics and that you use production data to continuously improve your test strategy.