Candidates who know every definition by heart can still struggle in a QA interview, because the questions rarely test definitions. They test how you think.
Below are five questions that come up again and again for junior and mid-level testers, what the interviewer is actually looking for, and how to build an answer. They are not scripts. Read them, close the tab, and write your own version with an example from your own work or practice projects.
TL;DR
- Answer with reasoning, not vocabulary. Interviewers want to hear how you decide, not a textbook quote.
- Use risk to prioritize, and say out loud what you did not test.
- A bug report is judged on one thing: can a developer reproduce it on the first try?
- For "how would you test X?", ask questions first, then structure your ideas.
- For automation, show judgment about what not to automate.
A quick word on how QA interviews are built
Most hiring processes for testers combine some of the same building blocks: a short screening call, a technical interview, a practical exercise (live or take-home), and a behavioral interview. The names and order change from one company to the next, but each round looks for something different. The five questions below are mostly technical-interview material, and the fourth one often turns into the practical exercise.
1. "Time is short. What do you test first?"
What they are checking: prioritization. Nobody tests everything, so the interviewer wants to see how you choose.
How to answer: talk about risk. Look at what changed in this release, what users rely on most, and what would hurt the business if it broke. Test the main happy paths of those areas first, then the most likely failure cases.
Then add the part most candidates forget: tell the team what you did not get to. A release decision made with a clear list of untested areas is a good decision, even if the coverage is incomplete.
"I'd start from what changed and what users depend on most, check the main flows there, then the likely failures. Before the release, I'd share exactly what I didn't cover, so the team decides with full information."
2. "What should a good bug report contain?"
What they are checking: clear communication. A vague report costs a developer time and costs you credibility.
How to answer: list the parts, then give the goal behind them.
- a title that says what is wrong and where;
- the environment: build or version, browser or device, operating system;
- exact steps to reproduce;
- expected result and actual result;
- severity, with a one-line reason;
- evidence: screenshot, short video, logs, the failing network request.
One bug per report. The goal: a developer reproduces it on the first try without having to ask you anything. If you can, mention a bug you reported and what made the report effective.
3. "A developer says: 'It works on my machine.' What do you do?"
What they are checking: collaboration under mild friction. Are you defensive, or curious?
How to answer: stay curious. Reproduce it again on your side, then compare the two environments: build version, browser, test data, user permissions, configuration, cached data, feature flags. Share the exact steps and the evidence, and offer to reproduce it together.
The point worth saying out loud: the difference between the two environments is often the clue to the bug itself. That turns a disagreement into a joint investigation, which is exactly what a team wants from its tester.
4. "How would you test this login page?"
What they are checking: structured thinking. This question (or "how would you test a pen / an elevator / a coffee machine?") is less about the object than about how you organize your ideas.
How to answer: start with questions. Who uses it? Is there "remember me", a lockout policy, single sign-on, two-factor authentication? What are the password rules? Then group your ideas instead of listing them at random:
- Happy path: valid credentials log the user in and land on the right page.
- Negative cases: wrong password, unknown email, empty fields, expired account.
- Boundaries: minimum and maximum length, spaces, special characters, copy-paste.
- Security: password is masked, lockout after repeated failures, error messages don't reveal whether the email exists.
- Usability and accessibility: keyboard navigation, labels read by a screen reader, clear error messages.
- Compatibility: the main browsers and a mobile viewport.
Finish by saying which of these you would run first, and why. The structure of your answer matters more than its length.
5. "What would you automate first?"
What they are checking: judgment. Automation is a cost as well as a benefit, and mid-level candidates in particular are expected to know the difference.
How to answer: automate what is stable, repetitive and valuable: smoke tests, core user journeys, regression checks, and API tests with many data combinations. Keep exploratory testing, usability judgment, one-off checks and features that still change every sprint as manual work, at least for now.
If the role mentions a tool, connect your answer to it. With Playwright, for example, you can mention that the official best practices recommend testing user-visible behavior, using locators, and keeping tests isolated from one another. Be honest about your level: "I've used it on a personal project, here is what I built" beats bluffing every time.
API questions often follow this one. A classic: what is the difference between 401 and 403? A 401 means the request lacks valid authentication; a 403 means the server understood who you are but refuses access.
Tool expectations also vary by market. When we counted the skills in 405 QA job ads in France in October 2026, Playwright appeared in 24.2% of them and Selenium in 21.7%. Read the job ad closely and prepare for the tools it names.
How to practice in the week before
- Write your answers down, then say them out loud with a timer. Most answers should take between 45 and 90 seconds.
- Prepare four to six real stories in STAR format (Situation, Task, Action, Result) for behavioral questions. Say "I", not "we", and keep the Action part the longest.
- Redo one practical exercise: write test cases for a login form, or a bug report for a bug you found in any app you use.
- Prepare two or three questions for them, for example: "Who decides when a release is ready?"
If you want a structured workbook
I put all of this, and more, into a printable and fillable PDF: the Software Testing Interview Workbook (36 pages, in English). It covers 30 common questions with model answers, 13 core testing concepts, three practical exercises with worked solutions (login test cases, a checkout spec review, a bug report), automation and API basics, STAR worksheets and a 7-day prep plan. It's a paid product on Etsy ($10.99): Software Testing Interview Workbook. Everything in this article is free to use without it.
Over to you
Which interview question caught you off guard the most, and how would you answer it today? Share it in the comments; I'll reply to each one.
Sources: Playwright — Best Practices · MDN — 401 Unauthorized · MDN — 403 Forbidden · AutomationDataCamp — QA Skills Barometer, October 2026
Written with AI assistance and reviewed by a test automation engineer; links were checked on 7 October 2026. The interview advice reflects our own experience, not a survey.
AutomationDataCamp is an online software testing academy (Playwright, API testing, CI, AI-assisted testing, ISTQB prep). More on our site.
Top comments (0)