QA and test engineer interview questions and how to answer them
Questions on the skills open QA and test engineer listings mention and on the core work of the role. For each: what the interviewer is checking, and a STAR answer outline with placeholders for your own example.
Based on 72 open QA and test engineer listings on ROLIVA as of . Each question below is about a term from ROLIVA’s skills vocabulary that appears in at least two of these listings, most-mentioned first.
01 Tell me about something you built or automated in Python that other people relied on. What would you do differently now?
Why this question: Python is mentioned in 37 of 72 listings.
What the interviewer is checking. Whether you write Python that works beyond your own laptop: structure, error handling, tests or checks, and whether you can judge your earlier work honestly.
Answer outline (STAR)
Situation.[The task or problem, and who depended on the script, notebook or service].
Task.[What it had to do and any constraint, e.g. data size, run frequency or a deadline].
Action.[The approach and libraries you used, how you handled failures or bad input, and how you tested it].
Result.[What it replaced or made possible, and the one thing you would change today]. If there is no number you can support, say what changed as a result or what you learned.
02 How have you used Jira to keep a piece of work visible and on track? Tell me about a time the board did not match reality.
Why this question: Jira is mentioned in 17 of 72 listings.
What the interviewer is checking. Whether you use the tool to support delivery rather than for its own sake, and whether you notice and fix it when tickets drift from the real state of the work.
Answer outline (STAR)
Situation.[The team, the work and how it was tracked in Jira].
Task.[What went wrong or what you were responsible for, e.g. a board everyone had stopped trusting].
Action.[What you changed, e.g. clearer ticket definitions, a workflow fix or a regular review, and how you got the team to adopt it].
Result.[Whether status became reliable and what decisions it supported]. If there is no number you can support, say what changed as a result or what you learned.
03 Walk me through a Java service or component you worked on. What design decision are you most and least happy with?
Why this question: Java is mentioned in 13 of 72 listings.
What the interviewer is checking. Whether you can explain design trade-offs in a typed, object-oriented codebase and reflect honestly on your own decisions.
Answer outline (STAR)
Situation.[The system and your part in it].
Task.[The requirement or problem that shaped the design].
Action.[The decision you made, the alternatives you considered, and how you tested it].
Result.[How the design held up in production, and what you would change]. If there is no number you can support, say what changed as a result or what you learned.
04 Walk me through work you did on Azure. How did you handle identity, access and environments?
Why this question: Azure is mentioned in 12 of 72 listings.
What the interviewer is checking. Whether you can work safely in a cloud platform: least-privilege access, separate environments, and repeatable deployment instead of manual changes.
Answer outline (STAR)
Situation.[The system or migration and the Azure services involved].
Task.[What you were responsible for and the constraint, e.g. a compliance requirement].
Action.[How you set up access, environments and deployment, and any problem you solved along the way].
Result.[The result, e.g. a successful migration or fewer manual changes]. If there is no number you can support, say what changed as a result or what you learned.
05 Walk me through a SQL query you wrote that answered a real question. How did you know the result was right?
Why this question: SQL is mentioned in 12 of 72 listings.
What the interviewer is checking. Whether you can turn a question into joins, filters and aggregations, and whether you check your own output instead of trusting the first number the query returns.
Answer outline (STAR)
Situation.[The question someone needed answered and the tables or data sources involved, e.g. orders joined to customers].
Task.[What you had to produce, for whom, and by when].
Action.[How you built the query: the joins, filters and grouping you chose, and how you checked it, e.g. row counts, a hand-checked sample or a comparison with a known total].
Result.[What the answer showed and what was decided because of it]. If there is no number you can support, say what changed as a result or what you learned.
06 Tell me about a time an Agile way of working was not helping your team. What did you change?
Why this question: Agile is mentioned in 10 of 72 listings.
What the interviewer is checking. Whether you understand the purpose behind Agile practices and adapt them to the team, rather than following ceremonies for their own sake.
Answer outline (STAR)
Situation.[The team and the practice that was not working, e.g. planning that never matched delivery].
Task.[What you were responsible for or chose to take on].
Action.[What you noticed, what you proposed, and how the team agreed to try it].
Result.[What changed in delivery or in how the team worked]. If there is no number you can support, say what changed as a result or what you learned.
07 Describe something you built or ran on AWS. Which services did you choose, and what went wrong at some point?
Why this question: AWS is mentioned in 10 of 72 listings.
What the interviewer is checking. Whether you understand the trade-offs behind the services you used, including security, cost and failure modes, rather than just naming them.
Answer outline (STAR)
Situation.[The system and what it did, e.g. an API, a data pipeline or a batch job].
Task.[Your part in building or operating it].
Action.[The services you used and why, how you handled permissions and cost, and how you dealt with the failure].
Result.[How the system ran afterwards and what you changed to prevent a repeat]. If there is no number you can support, say what changed as a result or what you learned.
08 Describe a JavaScript bug that was hard to find. How did you track it down?
Why this question: JavaScript is mentioned in 8 of 72 listings.
What the interviewer is checking. Whether you understand the language’s sharp edges (asynchronous code, scope, type coercion, the event loop) and debug systematically.
Answer outline (STAR)
Situation.[Where the bug appeared and how it showed itself to users].
Task.[Your responsibility for finding and fixing it].
Action.[The debugging steps, e.g. reproducing it, narrowing it down, reading the call order, and the fix].
Result.[How you confirmed the fix and what you added so it would not return, e.g. a test]. If there is no number you can support, say what changed as a result or what you learned.
Questions about the core work of a QA and test engineer
These follow from the work the role title describes, not from a count of listings.
09 Tell me about a defect that reached production even though it should have been caught in testing. What happened, and what did you change afterwards?
What the interviewer is checking. Whether you can own a quality gap without blaming others, trace it to a cause in the test approach, and make a change that prevents the same class of defect rather than patching one test.
Answer outline (STAR)
Situation. Describe [the product area and the defect], [how it was found in production], and [who was affected], without exaggerating the impact.
Task. Explain [your responsibility for testing that area] and [what the existing test coverage or process was at the time].
Action. Walk through [how you found why testing missed it: missing case, environment gap, data gap or time pressure] and [the change you made to tests, environments or the release checklist].
Result. State [a result you can support, e.g. "no repeat of that defect class over the next releases"]. If you cannot measure it, say [what changed in how the team tests that area].
10 You have two days before a release and far more to test than time allows. How do you decide what to test and what to leave?
What the interviewer is checking. Risk-based judgement: whether you prioritise by user impact, change size and failure history, and whether you make the remaining risk visible to the people who decide on the release instead of silently cutting scope.
Answer outline (STAR)
Situation. Set out [the release, its deadline] and [roughly how much testing was planned versus possible].
Task. Explain [what you were accountable for: a test plan, a sign-off or a recommendation].
Action. Describe [how you ranked areas by risk], [which tests you ran, automated or deferred], and [how you told the release owner what was not covered].
Result. Give [the outcome you can support, e.g. the release went out with known risks documented]. If issues followed, say [what they were and how your notes helped].
11 A developer tells you the bug you raised is "working as designed". How do you handle it?
What the interviewer is checking. Whether you separate a code defect from a requirements disagreement, argue from evidence and user impact rather than opinion, and know who should make the final call.
Answer outline (STAR)
Situation. Describe [the behaviour you reported] and [why you believed it was wrong].
Task. Explain [what you needed: a fix, a requirement clarification or a documented decision].
Action. Walk through [the evidence you gathered: spec, acceptance criteria, user impact], [who you brought in, e.g. the product owner], and [how you kept the conversation constructive].
Result. Say [how it was resolved, fixed or accepted as designed] and [what you changed, such as clearer acceptance criteria], using only results you can support.
12 How did you decide what to automate in a test suite you were responsible for, and what did you deliberately keep manual?
What the interviewer is checking. Whether you treat automation as an investment with maintenance cost, can explain the balance between unit, API and UI tests, and can recognise flaky or low-value tests.
Answer outline (STAR)
Situation. Describe [the product and the state of the test suite when you started: size, speed, flakiness].
Task. Explain [the goal you were given or set, e.g. faster feedback before merge].
Action. Explain [the criteria you used to choose what to automate], [the layer you put tests at], and [how you handled flaky tests].
Result. Give [a result you can support, e.g. "suite run time from 40 minutes to 12"]. If unmeasured, say [what the team could do afterwards that it could not before].
Using the outlines
One real example per answer. Replace every [bracketed] part with something you did and can talk about in detail.
Keep the situation short. Spend most of the answer on what you did and why.
Say “I” for your part. Name the team’s work as the team’s, and your own decisions as yours.
Results you can support. If there is no number, say what changed or what you learned. Never estimate a figure you cannot back up.
How these questions are chosen
Each open QA and test engineer listing’s description and stated skills are checked, on whole words, against the fixed skills vocabulary ROLIVA uses on its job pages, resume examples and monthly skills reports. A listing counts once per term. A mention is not a requirement, and the counts change as employers open and close roles. The questions and outlines are preparation prompts written for this role. They are not a record of what any employer has asked, and no employer’s process is described here.
Interview Studio prepares questions and STAR outlines for a real job from its description and the experience you have confirmed. No generative AI: when a detail is missing, it asks you instead of inventing one.