Skip to main content
VirtualInterview.ai
Sign InSign Up

Mock interviews by role · Software & Engineering

QA Engineer mock interview

QA interviews reward people who can find the risky path and explain it so a team will act. A long list of test types, with no example of a bug you caught and no opinion about what not to automate, sounds junior even when the list is correct.

For each question below, answer with a real flow: the user, the risk, the check, and the bug or the release call.

Practice this role with an AI interviewer

What the loop usually looks like

  1. Screen

    30 min

    How you test a feature and how you report a bug.

  2. Exercise

    45 min

    Write cases for a small product, or find bugs in a build.

  3. Strategy

    30–45 min

    Automation boundaries and a release go or no-go.

What interviewers score

  • Risk-based testing
  • Clear reproduction
  • Automation judgment
  • Release decisions

10 qa engineer interview questions and model answers

  1. Domain

    1. How do you test a payments change when you cannot run real cards all day?

    What they are testing: Risk and environments.

    I map the paths that move money and run those against a sandbox with success, decline, and timeout. I automate the repeatable ones and keep a short manual pass for the receipt and the ledger. I do not spend the day on cosmetic cases while the timeout path is untested.

  2. Technical

    2. What do you automate first?

    What they are testing: Automation priority.

    I automate the path that breaks often, costs a lot when it breaks, and is stable enough to assert. A flaky end-to-end test that everyone ignores is worse than a smaller check at the API. UI tests cover a thin smoke path, not every pixel.

  3. Technical

    3. A bug only happens after a specific sequence. How do you write it up?

    What they are testing: Reproduction quality.

    I number the steps, include the account state before step one, and say what I expected versus what happened. I add the build and the browser. If I cannot reproduce it twice, I say that, and I include the once-through notes anyway.

  4. Situational

    4. Developers say a bug is not severe because there is a workaround. What do you do?

    What they are testing: Severity judgment.

    I describe who hits it and what the workaround costs. If support will hear about it every day, it is not minor because a developer can avoid it. I ask for a decision in the ticket, not in a hallway.

  5. Behavioral

    5. Tell me about a release you stopped.

    What they are testing: Courage with evidence.

    Checkout failed when the cart had a discount and a gift card together. I had a recording and a log. We slipped one day and shipped the fix. I also added that pair to the smoke list so it was not a one-time hero moment.

  6. Domain

    6. How do you test a fix without retesting the whole product?

    What they are testing: Regression scope.

    I test the fix, the adjacent path that shares the code, and one happy path that proves the build is alive. I widen the pass only if the change is in shared auth, payments, or a library every screen uses.

  7. Technical

    7. Where do flaky tests come from, and what do you do with one?

    What they are testing: Signal quality.

    Common causes are time, order, and shared data. I quarantine the test the day it flakes, assign an owner, and do not leave it failing in the required check. A required check that is red for other reasons teaches the team to ignore red.

  8. Behavioral

    8. Describe how you worked with a developer who disliked QA.

    What they are testing: Collaboration.

    I brought bugs with repros and joined the debugging instead of throwing tickets over a wall. I also asked to be in the design review so the risky case was visible before the code existed. The tone changed when the first bug was found there, not after the build.

  9. Situational

    9. You have one hour before a release. What do you run?

    What they are testing: Triage under time.

    I run the money path, the login path, and the new feature’s main success and main failure. I write down what I did not run. A false all-clear is worse than a short list of gaps.

  10. Domain

    10. How do you measure whether QA is helping?

    What they are testing: Outcomes, not case counts.

    I look at escaped bugs, time to reproduce, and whether automation caught a regression before a user did. A rising case count with the same escapes is not progress.

Frequently asked questions

Should I talk about tools or about bugs?

Lead with a bug and the risk. Mention the tool when it changes the story, such as a trace that proved the race.

Do QA interviews include coding?

Many automation roles include a small scripting exercise. Manual roles still ask how you would automate one case. Be ready to write a short test or to describe it line by line.

How do I show seniority?

Talk about what you chose not to test and why, and about a release decision. Junior answers list every case. Senior answers pick.

Can I practice the release-call question?

Yes. Use a QA mock and answer the go or no-go out loud. The useful follow-up is what evidence would change your call.

Keep practicing