QA interview questions for 3–5 years of experience

With three to five years of experience the interview stops being about definitions. Expect most of the time to go on your project, your automation, and your decisions. The interviewer is deciding whether you can work without being told what to do next.

"Explain your project and your role."

Prepare a one-minute version and a five-minute version. Cover: what the product does and who uses it, the team size and sprint rhythm, the stack under test, what you personally owned (not "we"), the size of your suite (number of tests, run time, pass rate), and one result you can measure, such as cutting the regression run from six hours to 90 minutes.

Expect the interviewer to pick one thing you mention and go deep. Do not mention anything you cannot go five questions deep on.

"Walk me through your automation framework."

Draw it as you talk: test runner (TestNG, JUnit, Playwright test), layers (tests, page objects or screens, utilities, test data, config, reporting), how a test starts, how data is supplied, how the driver is created per thread, how failures produce a screenshot and a log, how it runs in CI. Then say what you would change. Honest weaknesses beat a perfect-sounding answer.

Likely follow-ups, with the point to hit:

• How do you handle test data? Create it through the API in set-up and remove it in tear-down, so tests are independent and repeatable. Avoid sharing one user between tests.
• How do you run in parallel? One driver per thread, no shared mutable state, tests that do not depend on order.
• How do you handle different environments? Config files or environment variables, never URLs hard-coded in tests.
• How do you deal with flaky tests? See the next section.

"How do you handle flaky tests?"

Quarantine first (tag them so they stop blocking the pipeline but stay visible), then find the cause: timing, shared data, order dependence, environment. Fix the cause. Keep a count of flaky tests and the time spent re-running as a visible number. Say clearly that you do not use blanket retries as a fix.

"What do you automate and what do you not?"

Automate what is stable, repeated, high-risk and has clear expected results: regression paths, data-heavy checks, API contracts. Do not automate what changes every sprint, one-off checks, or things that need human judgement (look and feel). Mention the pyramid: many API and unit-level checks, few UI journeys.

API and database depth

• Design tests for an endpoint with pagination, filtering and auth (API testing questions).
• Explain how you verify data in the database after a UI action (SQL for testers).
• A request works in Postman and fails in the framework: what do you check? Headers, auth token expiry, content type, base URL and environment, TLS settings, request body encoding.

Process and ownership

"How do you estimate testing effort?"

Break the work into test design, data set-up, execution, regression, defect retesting and reporting. Estimate each by past similar work, add a buffer for retesting (usually a second cycle), and state your assumptions in writing (for example, "assumes the build is stable on day one"). Give a range, not a single number.

"How do you decide the release is ready?"

By exit criteria agreed in advance: critical and high defects closed, regression passed, known issues documented with impact. You report the evidence and the risk; the product owner makes the decision. See scenario-based questions for the late bug example.

"Tell me about a defect you found that mattered."

Pick one with real impact. Structure: what you were testing, what looked wrong, how you proved it, what it would have cost, what changed afterwards. Avoid a trivial UI typo.

"A time you disagreed with a developer or a manager."

Choose a real one about a technical or priority question, say what each side wanted, what evidence you brought, and how it ended. Interviewers listen for whether you can disagree without making it personal.

Twelve more questions at this level

1. How do you decide what to test at which level of the test pyramid?

Unit tests for logic, API tests for business rules and integrations, and a small number of UI tests for the key user journeys. Push each check as far down as it can go while still testing what matters: it is faster, more stable and points closer to the cause. A suite that is mostly UI tests is slow and flaky.

2. How have you used CI/CD with your tests?

Describe a real pipeline: what triggers it (a pull request, a merge, a schedule), which tests run at each stage (a fast smoke set on every change, the full regression nightly), how failures are reported, and what blocks a merge or a release. See CI/CD interview questions and the GitHub Actions tutorial.

3. How do you review test code, and what do you look for?

Readable names, one purpose per test, no fixed sleeps, independent tests, data created and cleaned up by the test, assertions on behaviour, no copied locators (use page objects), and no secrets. Review tests with the same care as product code.

4. How do you test an API that other teams depend on?

Cover the contract: status codes, schema, error cases, authentication and authorization, limits and idempotency. Keep consumer-focused checks (contract tests) so a change by the provider that breaks a consumer is caught before release. Version the API and test the old version as long as it is supported.

5. How do you find a performance problem?

Define the target first (for example p95 under 800 ms at 200 users). Measure with a realistic load test, find the slow part with monitoring or profiling (database queries, an external call, a missing index), change one thing, and measure again. Report percentiles, not averages.

6. How do you handle security testing as a tester, without being a security expert?

Check the basics on every feature: authorization (can user A see user B's data), input handling (script and SQL characters), session handling (logout, expiry), sensitive data in responses and logs, and HTTPS. Use a checklist, run an automated scanner as a first pass, and escalate what you find to the security team.

7. A feature passes every test and users still complain. What do you do?

The tests did not model what users do. Look at support tickets, analytics and session recordings; find the real flow; reproduce it; add that as a test; and ask why the original acceptance criteria missed it. Quality is about the user's result, not the number of green tests.

8. How do you mentor a junior tester?

Pair on a real task rather than lecture; review their test cases and bug reports with specific feedback; give them a small area to own; explain why, not only what; and let them make safe mistakes. The goal is that they stop needing you for that kind of task.

9. How do you estimate when requirements are still changing?

Estimate a range, list the assumptions, and update the estimate when they change. Split the work into a stable core and a part that will change, commit to the first and keep a buffer for the second. In agile teams, estimate relative size and track velocity rather than hours.

10. How do you decide whether to automate a test?

Ask how often it runs, how stable the feature is, how costly a manual run is, and how bad a miss would be. Stable, repeated, high-risk checks with clear results are first. A feature that changes every sprint, or a check needing human judgment, is not. Also ask whether it can be an API test instead of a UI test.

11. What would you do in your first 30 days on a new project?

Learn the product and the users, read the requirements and the past defects, run the existing tests and find which are flaky or missing, meet developers and the product owner, and deliver one small improvement quickly, such as fixing a flaky test or adding missing smoke coverage. Write down what you find, and propose rather than rewrite.

12. What is your approach to a production defect?

Reproduce it, find the scope (who is affected, since when), help with a mitigation or a hotfix, test the fix on a copy of production-like data, and then do a blameless review: why was it missed, and what test or check would catch it next time.

Questions to ask them

Ask about how releases happen, what the test pyramid looks like on the team, how flaky tests are treated and who owns the framework. These show you think like a senior.

Check yourself

Take the Selenium quiz and the API testing quiz. If the score is below 70%, revisit the matching topic page before the interview.