QA Engineer interview
QA Engineer interview practice, out loud
A QA interview is really a test of how you think about what could go wrong. Anyone can run through the happy path; the job is the edge cases, the risk-based judgement of what to test first, and knowing what's worth automating. Interviewers probe with "how would you test this?" and then push on everything you missed.
This rehearsal is a spoken interview built around a real QA posting. It moves from your testing approach, into how you'd test a specific feature, the edge cases you'd hunt for, a bug report you'd write, and what you'd automate versus check by hand.
The report tells you whether you thought in risks and edge cases or just steps, how clearly you'd communicate a defect, and whether your automation instinct was sensible.
QA Engineer interview at a glance
- Rounds
- Usually three — a screen, a test-design round, and an automation or process round, with a manager conversation at the end
- Length
- 30–50 minutes each; the test-design round is the one that decides the outcome
- The signature question
- "How would you test this?" — scored on categories covered per minute, not on list length
- Asked almost verbatim
- The difference between severity and priority, with an example where the two diverge
- Where candidates actually lose
- Answering an escaped-defect question by naming who missed it
- Prep that pays
- Testing one everyday object out loud, against a five-minute timer
What actually happens in a QA Engineer interview
Screen~20 min
How your time splits between manual and automated work, the domain you have tested in, and whether you have ever signed off a release. That last one is the differentiator at this level — most early-career testers have executed cases, and rather fewer have been the person who said it was ready to go.
The test-design round~45 min
You are given something — a feature, a form, sometimes an object in the room — and asked how you would test it. The interviewer is quietly ticking off categories: functional, boundary, negative, data, security, performance, usability, compatibility. Sweeping those in order is what makes the round scoreable at all.
Automation round~45 min
Your framework, how you locate elements, how you wait, and what you do with a test that fails one run in ten. Some loops hand you an existing test and ask what is wrong with it, which is a fairer read of judgement than writing one from scratch under a clock.
Process and defect round~40 min
The bug lifecycle, severity against priority, an acceptance criterion written badly enough to be ambiguous, and a release you could not fully test. This is where a tester who has worked inside a real sprint separates from one who has only run suites.
Manager round~30 min
The defect that escaped, and a developer who closed your bug as working on their machine. Both look for whether you can hold a position on evidence without turning the relationship adversarial, because a tester who fights with developers stops being told things early.
What this interview assesses
Test Thinking & Edge Cases
Given a feature, do you find the edge cases, failure modes and risky paths — not just the happy path — and prioritise by what matters most?
Bug Reporting & Rigour
Can you write a defect anyone can reproduce, isolate the real trigger, and distinguish a symptom from a root cause?
Automation Judgement
Do you know what's worth automating versus checking by hand, and reason about coverage rather than automating everything blindly?
Sample QA Engineer interview questions
A feel for the kind of questions you’ll face. The real interview reacts to your answers with live follow-ups — these are examples, not the exact set.
1.How would you test a login form?
What lands: Go past the happy path fast — empty fields, wrong password, lockouts, special characters, session, security. Breadth of edge cases is the whole point.
2.You find a bug. What goes into the report?
What lands: Steps to reproduce, expected vs actual, environment, and the smallest reproduction — so a developer never has to ask you a follow-up.
3.What would you automate, and what would you keep manual?
What lands: Automate stable, repetitive, high-value paths; keep exploratory and fast-changing UI manual. Reason about cost vs value.
4.A release is tomorrow and you can't test everything. How do you decide what to test?
What lands: Risk-based — highest-impact and most-recently-changed areas first. Show judgement, not exhaustiveness.
5.A developer says 'it works on my machine' and closes your bug. What do you do?
What lands: Reproduce with exact steps and environment, share evidence, and stay collaborative rather than adversarial.
The job description it’s built around
The free taster rehearses against this realistic QA Engineer posting. In a full rehearsal you can paste the exact job you’re targeting instead.
Read the sample job description
QA Engineer (0–3 yrs) · Product Company · Hyderabad / Hybrid About the role We care about shipping quality software, and we want a QA engineer to own testing for our product features — finding the problems before our users do, and building the automation that keeps them found. What you'll do - Design and run test cases for new features, covering edge cases and failure modes - Write clear, reproducible bug reports and verify fixes - Build and maintain automated tests (UI and/or API) - Do exploratory and regression testing before releases - Work with developers and product to define acceptance criteria - Think about risk: what's most important to get right What we're looking for - 0–3 years in QA, testing or a quality-focused role (freshers welcome) - A mind that naturally asks "what could break here?" - Understanding of test design, bug reporting and the SDLC - Some exposure to test automation (Selenium, Cypress, Playwright, or API tools) - Clear written and spoken communication Nice to have - Basic SQL or scripting - Experience with CI-integrated test suites
QA Engineer interview — the specifics worth knowing
- The design round is scored on how many distinct categories you reach, not on how many cases you produce. Twenty functional cases score below eight spread across functional, boundary, negative, security and usability.
- How we know: An interviewer can count categories against a mental rubric; an unbounded list of similar cases gives them nothing to mark. Naming the category before the case is what makes your coverage visible to them.
- Severity and priority are asked almost verbatim in most QA loops, and the expected answer includes an example where they pull apart — a spelling mistake in the company name on the landing page is cosmetic and still ships as urgent.
- How we know: The pair is asked because the distinction governs everyday triage. A definition without a diverging example is the answer of someone who has read it rather than used it.
- The escaped-defect question is about the gap in the process, not the person who missed the case. An answer that names a colleague, or blames the timeline, closes the question badly.
- How we know: The interviewer is hiring for what you would change next time, and a process step can be changed while a person cannot. It is also a quiet character question wearing a technical one's clothes.
- A flaky test is expected to be quarantined and then fixed or deleted. Leaving a retry around it is the answer that fails, because a retry hides a real failure as reliably as it hides a false one.
- How we know: A suite people have learned to re-run is a suite nobody believes, and a disbelieved suite has negative value — it costs time and blocks nothing.
- Automation questions want you to say what you would not automate. A candidate who would automate everything is describing a suite that will be abandoned within two quarters.
- How we know: Automation carries a maintenance cost that scales with how often the interface changes, so the judgement being tested is where that cost is worth paying.
- A bug report is assessed on one criterion: whether a developer could act on it without asking you anything. Steps, expected against actual, environment, build, and the smallest reproduction you could find.
- How we know: Every follow-up question a report generates is a round trip through two people's day. Teams that measure this usually find it is their largest single source of testing overhead.
- Basic SQL turns up in a large share of QA loops — enough to check that what the screen shows matches what the row actually holds.
- How we know: A defect that lives in the data is invisible from the interface, so a tester who cannot look behind it keeps filing symptoms. The queries asked are ordinarily a select with a where clause and one join.
- "You cannot test everything before tomorrow's release" expects risk-based prioritisation and one thing candidates leave out: telling the person signing off what you did not test.
- How we know: The decision to ship with known gaps belongs to whoever accepts the risk, and they can only accept a risk they were told about. Prioritising silently makes it your decision instead of theirs.
- For freshers, a break-it instinct demonstrated on a real product outscores a testing certificate, and interviewers ask for it directly — the last bug you found in an app you use yourself.
- How we know: The instinct is slow to teach and the tooling is fast to teach, so hiring optimises for the half that is hard to install. Have one ready, with steps.
Common mistakes — and what to do instead
Answering the design round with a long list of near-identical functional cases.
Name the category, give one case inside it, then move on. Breadth first and depth on request — the interviewer will ask you to go deeper on whichever category interests them.
Explaining an escaped defect by saying the timeline was too short.
Name the specific gap — no coverage of that path, an environment that did not match production, an acceptance criterion nobody questioned — and the change that followed it.
Saying you would automate the whole regression suite.
Say what stays manual and why: exploratory work, a screen being redesigned this quarter, anything whose value is a human noticing something odd.
Filing a defect as broken, with a screenshot attached.
Give the smallest reproduction you can get to, the expected and actual behaviour side by side, the build and environment, and the last build where it worked if you know it.
Preparation checklist
- Test one everyday object out loud against a five-minute timer
- Have a severity-versus-priority example where the two genuinely diverge
- Prepare one defect that reached production and the process change that followed
- Decide what you would refuse to automate, and be able to say why
- Write one bug report a developer could act on without asking a question
- Revise enough SQL to check the row behind a screen
- Plan how you would sign off a release you could not fully test
- Memorise your category sweep so you can cover it aloud in order
QA Engineer interview — FAQs
Is this for manual or automation QA?
Both. It centres on test thinking and edge-case judgement — the core of any QA role — and includes what and how you'd automate. Bring your automation experience if you have it.
Do I need to code live?
No. It's a spoken interview about how you'd test, report and automate — with follow-ups — not a coding round.
I'm a fresher moving into QA. Will it fit?
Yes. The posting welcomes freshers, and the questions reward a naturally curious, break-it mindset over years of experience.
How long is it?
The free taster is about five minutes. A full rehearsal runs 15 or 30 minutes and reviews every answer.
What does a QA interview actually assess?
How wide you can think, how fast, and whether you can be specific about a defect under pressure. The test-design round decides it, and it is scored on categories covered per minute rather than on how many cases you can list — an interviewer can count categories against a rubric but cannot count an unbounded list of near-identical functional cases. The second half of the assessment is rigour: whether a developer could act on your bug report without asking you a single follow-up question, and whether you can talk about a defect that reached production as a gap in the process rather than a person who missed it.
Related interviews
How to rehearse this exact thing
The how-would-you-test-this sweep
You get an underspecified feature and a clock, the way the real round runs. The report tells you which categories you never reached and how long you spent inside the first one.
The escaped defect, told without blame
The follow-up pushes for what changed afterwards rather than what broke. The report flags whether your answer landed on a system or on a person.
Defending a bug a developer closed
The rehearsal pushes back on your finding the way a busy developer would. The report shows whether you reached for evidence or for volume.
Ready to rehearse for real?
Start a free five-minute QA Engineer interview now. You’ll get a spoken interview with live follow-ups and a feedback report that quotes your own answers back.