QA Engineer interview kit: questions and rubric

How to use this kit

1. Agree the competencies with the hiring manager before the job is posted.
2. Give each interviewer one or two competencies, so nothing is asked twice.
3. Ask every candidate the same core questions; follow up freely.
4. Rate each competency against the anchors straight after the interview, alone.
5. Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

1. What draws you to testing and quality work, and what kind of testing do you want to do more of?
2. Tell me about a bug you found that would have hurt users if it had shipped. How did you find it?
3. Which of the tools named in the job description (a test framework, a browser or mobile automation tool, a bug tracker, a CI system) have you used at work, and for what?
4. The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

1. Exercise, 20 minutes: here is a half-page spec for a discount-code field at checkout. Codes are a percentage or a fixed amount, have an expiry date and a minimum order value, and some are single-use. Tell me how you would test it, starting with what you would test first and why. There is no build to click through.

   Follow up with

   • What would you ask the product manager before testing?
   • Which of these tests would you automate, and at what level?
   • You have one hour before release. What do you test?
   Strong answer

   Questions the gaps in the spec first (can codes stack? when exactly does a code expire, and in which time zone? what if the cart drops below the minimum after the code is applied?). Covers boundaries, invalid input, a single-use code used twice at once, refunds, and abuse such as guessing codes. Ranks the tests by risk and places each at the unit, API or UI level.

   Weak answer

   Lists happy-path checks only (enter a valid code, see the discount), or a long unordered list with no sense of priority. Never questions the spec.

2. Tell me about a release where you had to decide what not to test. How did you decide, and what happened?

   Follow up with

   • Who did you tell about the risk you were accepting?
   • Would you make the same call again?
   Strong answer

   Explains a risk-based choice (what changed, what users rely on most, what has broken before), made the accepted risk visible to the team and the product owner, and checked the outcome after release.

   Weak answer

   Tested in order until time ran out, or skipped areas without telling anyone. Treats coverage as the goal rather than risk.

1. Work sample, 10 minutes: here is a sign-up form in a small practice app built for interviews, with a few known bugs. Explore it with this charter: "find problems a first-time user on a phone could hit." Think aloud as you go.

   Follow up with

   • What did you try that you would not find in a scripted test?
   • What would your session notes say?
   • What would you explore with another 30 minutes?
   Strong answer

   Works to the charter and varies input on purpose: very long names, leading spaces, non-Latin characters, the back button, a double submit, a slow network, a small screen. Notes what was covered and what was not, and finds at least one of the planted bugs.

   Weak answer

   Clicks around with no plan, tries only valid input, or stops after the first bug. Keeps no record of what was covered.

2. Tell me about a serious bug you found by exploring rather than by following a test case.

   Follow up with

   • What made you look there?
   • What did you add to the regression checks afterwards?
   Strong answer

   Names the heuristic or clue that led there (an odd state, a recent change, a boundary, an interrupted flow), how they reproduced it reliably, and how it became a lasting regression check.

   Weak answer

   Found it by accident and cannot say why they looked there. Did not turn it into a check that would catch it again.

1. Work sample, 10 minutes: here is a short UI test in Playwright, Cypress or Selenium. It waits a fixed five seconds, finds a button by a long CSS path tied to the layout, and logs in through the UI at the start of every test. What would you change?

   Follow up with

   • How would you find the button instead?
   • What should this test check through the UI, and what through the API?
   Strong answer

   Replaces the fixed wait with the tool's built-in waiting or a condition-based assertion, finds the button by role, label or a test id, logs in once through the API or a saved session, and keeps the UI test to the behavior only the UI can show.

   Weak answer

   Makes only cosmetic changes, or lengthens the wait to make it pass more often. Does not see why the CSS path will break.

2. Tell me about an automated test suite you built or maintained. How was it structured, and how reliable was it?

   Follow up with

   • How long did it take to run, and what did you do about it?
   • How did you handle test data?
   Strong answer

   Describes a deliberate shape (many fast unit and API tests, fewer UI tests for key journeys), stable locators, independent test data, and runs in CI on every change. Knows the run time and how often it failed for no reason, and what they did to improve both.

   Weak answer

   Automated every manual test case through the UI with fixed waits and shared accounts. Cannot say how long the suite takes or how often it fails falsely.

3. What would you do if the UI suite fails on a different test about one run in five, and developers have started re-running it until it passes?

   Follow up with

   • What would you do this week while you investigate?
   Strong answer

   Treats flakiness as a bug: tracks which tests flake, reproduces them, fixes the usual causes (fixed waits, order dependence, shared data, an unstable environment), and quarantines visibly with an owner meanwhile, so the team trusts a red run again.

   Weak answer

   Adds automatic retries or longer waits, or switches the suite off. Accepts re-running as normal.

1. Work sample, 10 minutes: write the bug report for this. On checkout, applying a valid discount code and then removing an item sometimes leaves the discount in place below the minimum order value. You saw it on the staging build in Chrome on Android.

   Follow up with

   • What severity and priority would you give it, and why?
   • What would you check before filing it?
   Strong answer

   A title that names the behavior, exact steps with test data, expected and actual results, environment and build, how often it happens, and evidence such as a screenshot or a network log. Checks for duplicates and narrows the conditions first. Argues severity from user and business impact.

   Weak answer

   A vague title ('Discount broken'), missing steps or environment, or an opinion instead of an observation. Severity is guessed or set to critical by default.

2. Tell me about a time a developer or product manager disagreed that something was a bug, or that it mattered. What did you do?

   Follow up with

   • What evidence did you bring?
   • What was decided, and did you agree?
   Strong answer

   Brought evidence of user impact (a reproduction, a support ticket, the spec), listened to the other view, let the right person decide, and accepted the decision while recording the risk.

   Weak answer

   Escalated straight away or argued until they won. Dropped it without recording the risk, or treats developers as opponents.

1. Tell me about a time you changed how your team tested, not just what you tested.

   Follow up with

   • How did you get developers on board?
   • How did you know it helped?
   Strong answer

   Describes a concrete change (testable acceptance criteria agreed in refinement, pairing with developers on tests, a test-data tool, contract tests between services) and the evidence it helped in their team, such as fewer bugs found after release.

   Weak answer

   Describes quality as their job alone, or a change imposed without buy-in that the team quietly dropped.

2. What would you do if the team wants to release today and you have found a bug you think is serious, but the product owner thinks it is minor?

   Follow up with

   • What would you say, and to whom?
   • What would you do if they release anyway?
   Strong answer

   States the impact and the evidence plainly, offers options (fix now, hide it behind a feature flag, release with a known issue and a monitor), and accepts that the product owner decides. Records the risk and checks it after release.

   Weak answer

   Blocks the release on their own authority, or says nothing and lets it go. Sees QA as the gatekeeper rather than the adviser.

Never ask

• Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about testing skill, and age-based decisions are unlawful in many places.
• Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
• Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
• Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region, language and community. If location matters, ask whether the candidate can work from the job's location.
• Don't ask about citizenship or nationality. Why: it is not job-related and can be unlawful discrimination in the US, the EU and elsewhere. Ask only whether the candidate has the right to work in the job's location, or will need sponsorship.
• Don't ask about health conditions, disabilities or past medical leave. Why: the only relevant question is whether the candidate can perform the essential functions of the job, with or without reasonable accommodation.
• Don't ask for salary history where the law restricts it: many US states and cities do, and the EU Pay Transparency Directive requires member states to. Why: it carries past pay gaps into the new offer. Ask for the expected range; in India, where current pay is commonly asked, still set the offer from the role's band.
• Don't ask the candidate to test your live product or find bugs in your real app as an assignment. Why: that is unpaid QA work. Use a practice app or a prepared spec with planted issues, like the exercises in this kit.

Questions people ask

What is a good practical exercise for a QA engineer interview?

A short "test this feature" exercise. Hand the candidate a half-page spec with a few gaps, such as the discount-code field above, and ask how they would test it. In 20 minutes it shows whether they question the spec, think in risks and boundaries, and pick the right level for each test.

Should a QA engineer be able to code?

It depends on the role. For a QA automation engineer or SDET, yes: test code is production code, so review it like code. For a role focused on exploratory testing, reading code helps but is not a must-have. Say which role you are hiring for in the job description.

How do we interview a manual tester moving into automation?

Rate test strategy, exploratory skill and bug reporting as you would for anyone, and judge automation on reasoning rather than polish. The ten-minute review of a flawed UI test shows whether they know why tests break. Testing instincts are harder to teach than a framework.

Do ISTQB certifications matter when hiring QA engineers?

A certification shows the candidate knows the vocabulary of testing. It does not show judgment, and many strong testers have never taken one. Treat it as a small plus at most, and let the exercises show the skill.