In this article
The job and the basics
For the wider coding picture, see the coding interviews guide. The questions below are the ones specific to testing.
What does a QA engineer do?
A QA engineer plans and runs tests, records defects and tells the team how risky a release is. The U.S. Bureau of Labor Statistics (BLS) lists creating test plans, scenarios and procedures, identifying project risks, running manual, automated and exploratory tests, documenting defects and giving feedback on usability and function (BLS, last modified August 2026). Name which of these you have done.
Why it is asked: it checks that your picture of the job matches theirs.
What is the difference between QA, quality control and testing?
Quality assurance is the work of preventing defects through agreed processes, such as reviews and standards. Quality control checks the product against requirements, and testing is the main way of doing that check. Many teams use the three words loosely, so say how your last team used them and what you actually did day to day.
Why it is asked: it tests whether you know the vocabulary and can still be practical.
What is the difference between verification and validation?
Verification asks whether the product was built right, meaning it matches the specification, for example by reviews and tests against requirements. Validation asks whether the right product was built, meaning it meets what users actually need, for example in acceptance testing or a pilot. A product can pass verification and still fail validation if the specification was wrong.
Why it is asked: it separates checking against a document from checking against reality.
What is the difference between a test case, a test scenario and a test plan?
A test scenario is a situation to cover, such as a user resets a password. A test case is one concrete check with steps, data and an expected result. A test plan is the document that sets scope, approach, resources, risks and schedule for a body of testing. One scenario usually becomes several test cases.
Why it is asked: it checks that you can organise testing at three levels.
What are the seven testing principles?
The International Software Testing Qualifications Board (ISTQB) Foundation syllabus lists seven: testing shows the presence, not the absence, of defects; exhaustive testing is impossible; early testing saves time and money; defects cluster together; tests wear out, so repeated tests stop finding new defects; testing is context dependent; and the absence-of-defects fallacy: a defect-free product can still miss users' needs (ISTQB syllabus v4.0, April 2023). Older material calls the fifth the pesticide paradox. Pick two and give a real example of each.
Why it is asked: they are the shared language of the testing profession.
Test design
How do you decide what to test when you cannot test everything?
Exhaustive testing is impossible, so you use risk to choose. The American Software Testing Qualifications Board (ASTQB) page says testing everything, meaning all combinations of inputs and preconditions, is not feasible except for trivial cases (ASTQB, read October 2026). Rank features by the damage a failure would do and the chance of failure, then test the top of the list first.
Why it is asked: judgement about priorities is the heart of the job.
What are equivalence partitioning and boundary value analysis?
Equivalence partitioning is a technique that splits inputs into groups that should behave the same and tests one value from each group. Boundary value analysis is a technique that adds tests at the edges of each group, where errors cluster. For an illustrative age field that accepts 18 to 60, test 17, 18, 19, 59, 60 and 61: one below, on and above each edge. The ISTQB's leaner two-value version tests only 17, 18, 60 and 61.
Why it is asked: it shows that you can cut a huge input space down on purpose.
How would you test a login page?
Group the checks and rank them. Cover valid and invalid credentials, empty fields, a lockout after repeated failures, masked passwords, session expiry and the reset link. Then add accessibility, a basic security check such as odd characters in the fields, and behaviour under slow connections. Say which two groups you would run first and why.
Why it is asked: it is an open question that shows how you structure thinking.
What is the difference between regression testing and confirmation testing?
Regression testing is re-running checks after a change to confirm that existing behaviour still works. Confirmation testing, also called retesting, re-runs the failing case to confirm that a fixed defect is truly fixed. You usually do confirmation first, then regression, because a fix can break something else.
Why it is asked: it checks that you know why a fix is not the end of testing.
What is exploratory testing, and when do you use it?
Exploratory testing is testing in which you learn about the product, design tests and run them at the same time, guided by a goal rather than a script. The BLS lists exploratory testing alongside manual and automated testing as ways testers evaluate software (BLS, last modified August 2026). Use it when the specification is thin, after scripted tests pass, and to look for what scripts miss.
Why it is asked: it tests whether you are more than a script runner.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Defects
What goes in a good bug report?
A short title that names the problem, the steps to reproduce it, the expected result against the actual result, the environment and version, and evidence such as a screenshot, a log or a short recording. Report one issue per report. State the impact in a sentence. A developer should be able to reproduce the bug without asking you anything.
Why it is asked: a bug that cannot be reproduced is a bug that is not fixed.
What is the difference between severity and priority?
Severity is how much damage a defect does when it occurs, and priority is how soon the team should fix it. They can differ: a crash in a rarely used admin screen is high severity and low priority, while a typo in the company name on the home page is low severity and high priority. Product and engineering usually set priority.
Why it is asked: it separates impact from scheduling.
A developer says "cannot reproduce". What do you do?
Compare environment, data, version and exact steps, and add logs or a recording. Offer to reproduce it together on a call. Narrow the conditions; if it is intermittent, record how often it happens and under what load or timing. Stay factual and avoid blame. Close it only when you agree the evidence is not enough.
Why it is asked: it tests collaboration under friction.
Automation and APIs
How do you decide what to automate?
Automate checks that are repeated often, stable, important and quick to run, such as login and checkout regression. Keep exploratory work, new features still in flux and one-off checks manual. Weigh the cost of writing and maintaining a test against the time it saves. See the Java automation testing questions for framework detail.
Why it is asked: automating everything is the common mistake, so the interviewer looks for judgement.
What is the test pyramid?
The test pyramid is a model for balancing automated tests: many fast low-level unit tests, fewer service-level tests and a small number of tests that drive the user interface (UI). Martin Fowler wrote that you should have many more low-level unit tests than high-level tests running through a graphical user interface, because UI tests are brittle, expensive to write and slow to run (Fowler, 1 May 2012). He credits the idea to Mike Cohn's book Succeeding with Agile.
Why it is asked: it tests whether you design a suite for speed and reliability.
Text description of the diagram
- A balanced suite has many more low-level unit tests than high-level tests running through a user interface.
- User-interface tests are brittle, expensive to write and slow to run.
What causes flaky tests, and how do you fix them?
A flaky test is a test that passes and fails on the same code without any change. Selenium's documentation names the race between the browser's state and the script as one of the primary causes, and advises explicit waits for a named condition and warns against mixing implicit and explicit waits (Selenium waits, read October 2026). Also isolate test data, and treat re-running as a diagnosis, not a fix.
Why it is asked: flaky tests destroy trust in a suite.
How do you test an API?
Test each endpoint for the expected response, then for failures. Hypertext Transfer Protocol (HTTP) status codes fall in classes: the 4xx class is client errors and 5xx is server errors (Request for Comments (RFC) 9110, June 2022). Check valid requests, missing or malformed fields, authentication and permission failures (401 and 403), missing resources (404), conflicts (409), response shape, and limits. Read the representational state transfer (REST) application programming interface (API) questions for more.
Why it is asked: much testing happens below the user interface.
Which tools and languages do you use, and why?
Name the tools you have really used, say what each was for, and say what you would change. For example, a browser-automation tool such as Selenium, a test runner such as JUnit or pytest, and an API client. Interviewers care more about your reasons than the list. The JUnit questions and Python questions pages cover the languages.
Why it is asked: it separates hands-on experience from a list of names.
Process and fit
Why did you choose QA as a career?
Give a short, true reason tied to the work itself: you like finding how things break, you care about the people who use the software, or a bug you caught early changed a release. Then say what you want to learn next, such as automation or performance testing. If testing was not your first plan, say so briefly and explain what made you stay.
Why it is asked: it checks that you chose testing on purpose and will stay engaged.
How does QA work in an Agile team?
QA joins the team from the start of the sprint: reviewing stories for clear acceptance criteria, planning tests while code is written, testing as features land and agreeing the definition of done. The ASTQB list gives the reason: early testing saves time and money (ASTQB, read October 2026). Say how you flag risks in planning.
Why it is asked: most teams no longer test at the end.
How do you decide whether a release is ready?
Use evidence, not a feeling: open defects by severity, whether the critical user flows pass, the regression results, and the monitoring and rollback plan. State the risks and recommend; the product owner or release manager makes the decision. If you recommend a delay, say what would change your mind.
Why it is asked: it tests whether you can give a clear, honest recommendation.
Tell me about a serious bug you found.
Use a short situation, task, action, result story: how you found it, how you proved its impact, how you reported it and what changed afterwards, such as a new automated check. The situation, task, action, result (STAR) method guide shows the structure. Do not blame the developer; the point is how you worked with the team.
Why it is asked: it shows depth and what you consider important.
What questions do you have for us?
Ask how the team decides what to automate, how many bugs escape to production and how they learn from them, who owns the test environments and what the first project would be. The questions to ask the interviewer page lists more.
Why it is asked: it shows how you think about quality as a team practice.
How these interviews are run
QA interviews test the same skills under any of the job's titles. The BLS counts about 187,600 quality assurance analysts and testers in the United States in 2025, within 1,905,400 jobs for developers, analysts and testers together, and projects 10% growth for the combined group from 2025 to 2035 (BLS, last modified August 2026). Prepare a one-minute introduction, and see the interview loops guide for how rounds fit together.
Follow-up questions
How do I prepare for a QA engineer interview?
Write an answer to each question above in your own words, practise the "how would you test X" structure on three everyday objects, and prepare two stories about bugs you found. Say each aloud against a timer.
Do I need to know how to code for a QA interview?
For automation roles, yes; expect a short coding exercise in a language such as Java or Python. For manual testing roles, expect questions on test design and defect reports. Read the job description for the word automation.
What questions are asked in a QA interview?
Most QA interviews mix three kinds: knowledge questions like the ones above, a practical task such as "test this login page" or "write a test for this function", and questions about your past projects. Automation roles usually add a short coding exercise.
- A QA engineer plans tests, finds and reports defects, automates checks and advises on release risk.
- You cannot test everything, so choose by risk and use techniques such as equivalence partitions and boundaries.
- A good bug report lets a developer reproduce the problem without asking you anything.
- Automate stable, repeated, important checks, and keep a pyramid: many fast low-level tests, few slow UI tests.
- Give release advice from evidence, and say what would change your recommendation.
Sources
- Software Developers, Quality Assurance Analysts, and Testers: Occupational Outlook Handbook — U.S. Bureau of Labor Statistics, 27 Aug 2026
- ISTQB Foundation Level: Seven Testing Principles — ASTQB (page shows copyright 2026; date = read date), 24 Oct 2026
- Test Pyramid, Martin Fowler — martinfowler.com, 1 May 2012
- Waits, Selenium documentation — Selenium project (page last modified 16 September 2026), 16 Sep 2026
- ISTQB Certified Tester Foundation Level Syllabus v4.0 — ISTQB (PDF hosted by ASTQB), 21 Apr 2023
- RFC 9110: HTTP Semantics — IETF (Internet Engineering Task Force), 1 Jun 2022
