Bug reporting interview questions, with model answers

You are twenty minutes into a QA interview. The manager stops asking about tools and says: "Walk me through the last bug you filed." Most candidates freeze here, then give a vague answer about a login page.

That question is not small talk. Bug reporting is the part of the job the whole team sees. A hiring manager can read your bug reports and know how you think.

This guide covers 15 questions that come up in real screens and panels. Each one has a model answer and a note on what the interviewer is actually checking.

Short version

Answer with a real example, not a definition. Names, dates, error strings.
Say the impact in user terms before you say the technical cause.
Severity is about damage. Priority is about order of work. Never mix them.
Senior questions are about process and cost, not about writing steps.
Prepare three bugs you can describe in detail from memory.

How to use these answers

Do not memorise them word for word. An interviewer can hear a script. Instead, take the shape of each answer and swap in your own project.

Every strong answer follows the same pattern:

One line that states the point.
One concrete example with real detail.
One line on the outcome or the trade-off.

That is it. Thirty to sixty seconds per answer.

Junior level questions

These check that you know the basics and that you write clearly.

1. What goes into a good bug report?

What they check: whether you know the standard fields.

A title that says what broke and where. Steps to reproduce, numbered. Expected result and actual result. Environment: browser, version, operating system, and the build number. Evidence: a screenshot or a short video, plus console and network logs if the failure is technical. Severity and the account I used. On my last team we also added the test data, so [email protected] and the order ID.

2. Write me a title for this bug.

What they check: clarity under pressure.

They will describe a failure out loud. Answer with the pattern what broke + where + when.

Weak title	Strong title
Checkout broken	Checkout: "Place order" button does nothing when cart has 1 item and a discount code
App crash	Android app closes on opening Settings > Notifications after upgrade to 4.2.1
Login issue	Login fails with 500 error for accounts created before 2024-01-01

3. What is the difference between severity and priority?

What they check: the single most common QA confusion.

Severity is how much damage the bug does. Priority is how soon we fix it. A typo on the homepage is low severity but can be high priority before a launch. A crash in an admin tool used by two people is high severity but low priority. I set severity. The product owner usually sets priority, and I give them the data to decide.

4. What is the defect life cycle?

What they check: whether you have used a real tracker.

New, then assigned, then in progress, then fixed, then ready for test. From there it either goes to closed or back to reopened. There are two side branches: rejected, when it is working as designed, and deferred, when we agree to fix it later. I keep the ticket in my name until I have retested it, so nothing closes without a check.

5. A developer says "cannot reproduce". What do you do?

What they check: whether you argue or investigate.

First I reproduce it again myself on a clean session, to be sure it is real. Then I compare environments. Nine times out of ten it is a difference in browser, screen size, account state, or feature flag. Last month a bug only appeared for accounts with more than 50 saved addresses. I added that detail and a database seed script, and the developer had it in five minutes.

6. How much detail is too much?

What they check: judgement, not thoroughness.

If a line does not help someone reproduce, fix, or verify the bug, I cut it. I do not write "I opened Chrome, I typed the URL, I pressed enter". I start at the first step that matters. Long reports get skimmed, and skimmed reports get misread.

Mid level questions

These check that you can handle mess: flaky failures, unclear ownership, and pushback.

7. How do you report an intermittent bug?

I say up front that it is intermittent and give the rate: "seen 4 times in about 30 attempts". I list everything that was the same each time and everything that changed. I attach network logs from a failing run and a passing run, so the developer can diff them. If I cannot pin the trigger, I say so plainly rather than guessing.

8. How do you decide severity?

I use a fixed scale so it is not a feeling. Blocker: no one can work, no workaround. Critical: data loss or money lost. Major: a main flow is broken but there is a workaround. Minor: it is wrong but the flow completes. Trivial: cosmetic. I write the reason next to the choice, for example "Critical: duplicate charge of $49 on retry".

9. You find a bug on the day of release. Walk me through it.

I check impact first: how many users, is there money or data involved, is there a workaround. Then I file it with everything the developer needs and message the release owner directly, because a ticket alone is too slow at that hour. I give a recommendation, not just a report: "I would ship with the feature flag off and fix on Monday." The call is theirs.

10. How do you avoid duplicate bug reports?

I search the tracker with the error string and the screen name before filing, not with my own wording. If I find a near match, I add my case as a comment rather than opening a new ticket. Duplicates are not just noise. They split the evidence across two tickets and both look weak.

11. What evidence do you attach, and why?

A screenshot for anything visual, with the broken part visible in context, not cropped to a single button. A short video for anything with timing or animation. Console errors copied as text, so they are searchable, for example TypeError: Cannot read properties of undefined (reading 'total'). The failing network request with its status code and response body. And the URL, such as https://staging.example.com/checkout/review.

Capturing all of that by hand takes several minutes per bug, which is why many teams use a browser tool like Crosscheck that grabs the screenshot, console log, network requests, and environment details in one step from the page where the bug happened.

12. A developer marks your bug as "works as designed". How do you respond?

I ask where the design is written down. If there is a spec and I misread it, I close the ticket and say thanks. If there is no spec, then we have found a real disagreement, and I move it to the product owner with a screenshot and the user impact. I do not reopen the same ticket twice with a stronger tone.

Senior level questions

These check that you think about the system, not the ticket.

13. Your bug backlog has 400 open tickets. What do you do?

I do not try to fix the backlog by reading it. I sort by last activity and close everything untouched for a year with a note that it can be reopened. Then I group the rest by area. Usually two or three areas hold most of the tickets, and that points at a design problem, not 400 separate problems. I bring that to the team as one conversation.

14. How do you measure whether bug reporting is working?

Three numbers. Reopen rate: how often a fixed bug comes back, which shows weak verification. Clarification rate: how often a ticket needs a comment before work starts, which shows weak reports. Escape rate: bugs found in production that our tests should have caught. I do not track raw bug count, because it rewards filing noise.

15. How would you improve bug reporting for a team of 30?

I would start with a template that has required fields, so the floor is set without training anyone. Then I would sample twenty recent tickets and find the top two failure patterns, usually missing environment details and missing steps. Then one short session on those two things only. Small, measurable, and repeated beats a long standards document nobody reads.

Three things that lose interviews

Talking about tools instead of thinking. Naming Jira, TestRail, and Playwright proves nothing on its own.
Blaming developers. Any story where the developer is the villain reads as hard to work with.
No numbers. "I found a lot of bugs" is weaker than "I cut our reopen rate from 22% to 9% in one quarter".

Before the interview, write down three bugs in full: the symptom, the impact, how you found it, and how it ended. Most of these fifteen questions can be answered from those three stories.

Frequently asked questions

How long should my answers be?

Thirty to sixty seconds. State the point, give one example, then stop. Silence after a short answer is fine, and the interviewer will ask for more if they want it.

Should I bring sample bug reports to the interview?

Yes, if they contain no company data. Recreate one or two on a public demo site instead of exporting real tickets. Showing a real report you wrote beats describing one.

What if I have never used a formal bug tracker?

Say so, then describe how you did track issues, even if it was a spreadsheet or a shared document. Interviewers care that you had a system, not which tool it was.

Do these questions change for automation roles?

The core ones do not. Automation interviews add questions about flaky test triage and how you tell a real failure from a broken test, but severity, evidence, and reproduction still come up.

Is it bad to say "I do not know"?

No, as long as you follow it with how you would find out. "I have not handled that. Here is how I would start" is a stronger answer than a confident guess that falls apart on the follow-up.