What makes a good bug report? Walk me through one you would write.

A good bug report is one that a developer can act on without coming back to ask you anything. It should let a stranger reproduce the problem on the first attempt, understand why it matters, and find it again later through search. In practice that means a precise title, environment, minimal steps, expected versus actual behaviour, evidence, and a severity you can justify.

The anatomy

• Title: symptom plus location plus trigger. “Checkout: ‘Place order’ returns 500 when cart contains a gift card” beats “Checkout broken”.
• Environment: application build or commit, environment (staging, prod), browser and version, OS or device, user role, feature flags if relevant.
• Preconditions and test data: the account, the cart contents, the locale. Bugs that “cannot be reproduced” are very often data-dependent.
• Steps to reproduce: numbered, minimal, one action per step. Remove every step that is not needed to trigger the bug.
• Expected result: what should happen, ideally with a reference to the requirement, acceptance criterion or previous behaviour.
• Actual result: what happened, including exact error text.
• Evidence: screenshot or short video, browser console errors, the failing request and response (a HAR file or a copied cURL), server log excerpt or correlation/trace ID.
• Frequency: always, intermittent (3 of 10 attempts), only once.
• Severity (and suggested priority if your process allows it), plus any known workaround.

An example

Title: Checkout - "Place order" returns HTTP 500 when cart contains a gift card

Environment: staging, build 2026.11.03-a41f2c, Chrome 142 on Windows 11, logged-in customer
Preconditions: user test.buyer+gc@example.com, gift card GC-TEST-0001 (balance 20.00)

Steps:
1. Add "Basic T-shirt" (19.99) to the cart
2. Apply gift card GC-TEST-0001 on the cart page
3. Click "Checkout", choose "Card", complete payment details
4. Click "Place order"

Expected: order is created, confirmation page shows order number, gift card balance reduced
Actual: spinner for ~5s, then "Something went wrong". POST /api/orders returns 500.
        Response body: {"error":"NullPointerException","traceId":"8c1e..."}
Frequency: 5/5 with a gift card; 0/5 without
Severity: Major (checkout blocked for gift card users; workaround: remove gift card)
Attachments: video.mp4, checkout.har, console.png

Note how the frequency line already narrows the cause: it is the gift card, not checkout in general. Isolating the variable before filing is part of writing the report.

Habits that make reports better

• One defect per report. Two problems in one ticket get half-fixed and closed.
• Search for duplicates first, and link related tickets.
• Neutral, factual tone. Describe behaviour, not people.
• Verify on the latest build before filing, and note if it is a regression and from which build.

What interviewers look for

• Expected versus actual result and reproducible steps, said without prompting.
• Evidence beyond screenshots: network responses, logs, trace IDs.
• Isolation of the triggering condition before filing.
• Awareness that the reader is busy and the report must stand on its own.

Common mistakes

• Vague titles like “Login not working”.
• Steps that rely on knowledge in the tester’s head (“use the usual account”).
• Mixing several issues or adding opinions about the fix.