QA Engineer interview questions (India, 2026): what to ask and what to listen for

12 interview questions for a QA Engineer role, grouped by what each round should establish, each with what a strong answer contains, plus a five-point scorecard so every interviewer rates the same things.

Last updated 3 September 2026. Competitor pricing and plan limits are re-verified against each vendor’s own pages.

Interviewing a QA Engineer well means asking about work the candidate has actually done, listening for specifics, and scoring every candidate on the same five criteria. The questions below are grouped by what they establish; each one comes with what a good answer contains, which is the part most question lists leave out.

A QA Engineer owns the quality of what the team ships — test planning, manual and exploratory testing of every release, automated regression suites, bug reporting that developers can act on, and the release sign-off — for an Indian product team that cannot afford a broken release.

Use the screening questions on the job description page to filter before anyone reaches an interview, and the scorecard at the end so a panel can compare candidates rather than impressions.

How they test

Here is a short feature spec [e.g. apply a coupon at checkout]. Tell me what you would test, in the order you would test it.: A strong answer: Happy path, then boundaries, invalid inputs, concurrency, state after failure, and the device matrix — prioritised by risk. The order shows judgement.
Describe the best bug you ever found. How did you find it, and how did you report it?: A strong answer: Exploratory instinct, a precise reproduction, and a report that a developer could act on immediately.
Tell me about a bug that escaped to production on your watch. What did you change afterwards?: A strong answer: Honesty, root-cause thinking about the test gap, and a specific change to the process or the suite.
How do you test on the devices and networks our users actually have?: A strong answer: A device matrix with low-end Android, network throttling, real devices for critical flows — awareness that the simulator is not the user.

Automation and technical depth

Show me an automated test you wrote. What did it cover, how did you keep it from being flaky, and how did it run in CI?: A strong answer: Real code, sensible scope, stable selectors and waits, and CI integration. Flakiness handling separates practitioners from tutorial-followers.
What should be automated and what should stay manual in a product like ours?: A strong answer: Critical flows and regression automated; exploratory and visual checks manual — with a reason for each, not dogma.
How would you test an API directly, without the UI? Walk me through one endpoint.: A strong answer: Understands requests, status codes, validation, auth and error cases; can use a tool or write a script.
A test fails intermittently. What do you do?: A strong answer: Investigates — timing, data, environment — rather than retrying or deleting the test; fixes the cause or quarantines it with a ticket.

Judgement and the team

It is release day, two medium bugs are open, and the founder wants to ship. What do you say?: A strong answer: States the risk clearly with specifics, proposes options — ship with a known-issues note, hotfix plan, or hold — and respects the decision once made.
A developer disagrees that something is a bug. How do you handle it?: A strong answer: Refers to the spec or user expectation, gathers evidence, escalates to the product owner if needed — without making it personal.
How do you keep test documentation useful rather than a graveyard?: A strong answer: Living documents tied to the suite, pruned regularly, written for the next person.
What do you want to grow into — automation architect, SDET, product, lead — and does this role offer it?: A strong answer: A direction with a reason — more automation depth, a move towards development, leading a small QA function — and an honest read of whether a first-QA role in a small team leads there. Candidates who want a large QA organisation to grow inside will not stay.

Scorecard for QA Engineer interviews

Score each candidate on these five criteria, one to four, straight after the interview and before talking to the other interviewers. Written scores taken independently are what make a panel decision defensible; a discussion first produces one opinion with several signatures.

Test design judgement: prioritises by risk from a spec, finds the non-obvious cases.
Bug quality: precise reports; honest about escapes and what changed.
Automation competence: real, stable tests in CI; knows what to automate.
Technical depth: tests below the UI, understands the system.
Release judgement: communicates risk clearly and respects the decision.

Screen before you interview

Most QA Engineer interviews that go badly were avoidable at the application stage. The job description template for this role carries five screening questions that settle the deal-breakers — notice period, location, the one or two hard requirements — before anyone books a slot.

How many years of professional software testing experience do you have across product releases? — knockout
Have you written and maintained automated tests in [Playwright / Cypress / Appium / API tooling] that ran in CI? — for context
Are you able to work [from our City office X days a week / remote with overlap hours]? — knockout
What is your current notice period, in days? — for context

Questions, answered straight

What is the best QA Engineer interview question?

Give them a short feature spec and ask what they would test, in order. The cases they think of and the order they put them in show judgement about risk, which is the core of the role. Then ask about a bug that escaped and what they changed.

Should a QA interview include a practical test?

Yes: thirty minutes exploring your actual product or a staging build, reporting what they find. The quality of the bug reports — precision, severity, reproduction — is the most direct evidence you can get.

How do I assess automation skills without a long take-home?

Ask them to show an automated test they wrote and explain how they kept it stable and ran it in CI, then describe an intermittent failure and what they did. Real practitioners have flakiness stories; tutorial-level candidates do not.