Tell me about a bug you found: model answers

Choose a defect you can explain from observation to retest. Separate what you saw, what you inferred and what another person confirmed. All three model stories below are hypothetical, with invented products and outcomes; they are not personal experience or claims about ShopLite.

Construct the story

1. What structure makes a bug answer convincing?

Describe the intended behaviour, the observed mismatch, your investigation, impact and verification. Include one detail that distinguishes the defect: a second cart item, a different account or a timeout followed by retry. Avoid beginning with the ticket's severity label; first give the listener enough evidence to judge the impact.

2. How would you describe a checkout total bug?

Hypothetical model answer: “I would test a cart containing two eligible items and compare the discount with the agreed per-order rule. If the UI applied the discount once per item, I would capture the item values, displayed total and checkout request to locate the first disagreement. I would report the risk of an incorrect charge without claiming actual financial loss. After a fix, I would retest one item, multiple items and ineligible items, including the final persisted order total.”

The distinguishing detail is a rule applied at the wrong scope. Do not claim the server is wrong merely because the UI is wrong; compare the layers before assigning a cause.

3. How would you describe an access-control bug?

Hypothetical model answer: “In an authorized test environment, I would create an order under fake account A, then attempt to read its ID while authenticated as fake account B. If B received A's order, I would retain minimal sanitized evidence and notify the agreed security contact. I would test the fix with owned and unowned orders and an unauthenticated request. I would not access real customer records to demonstrate reach.”

This is a proposed test, not a reproduced exploit. Expected status codes depend on the API contract; the essential assertion is that unauthorized data is not disclosed.

4. How would you describe a retry-related booking bug?

Hypothetical model answer: “I would investigate a booking attempt where the client times out after the server may have accepted it. I would compare request identifiers and reservation records before retrying in the test environment. If the retry created a second reservation for the same logical attempt, I would report the duplicate-effect risk and ask the team to clarify the retry contract. Verification would include delayed responses, repeated delivery and a genuinely new booking attempt.”

Do not say every repeated request must be deduplicated: a new purchase may be intentional. The difficult part is defining a logical operation and its identity.

Evidence and follow-ups

5. What if the interviewer asks for the root cause?

Distinguish a symptom from a cause. “I isolated the mismatch to the server response; the developer confirmed the discount loop used item scope” is credible only if that confirmation actually happened. If you never saw the fix, say the root cause was not confirmed and explain what your evidence ruled out.

6. How do you discuss severity and priority?

Explain user impact, reach, workaround and release context before proposing labels. A duplicate reservation can affect inventory even when no money is captured; a cosmetic issue may still be urgent for a contractual demo. The team's label definitions vary, so do not present your previous employer's taxonomy as universal.

7. What if the developer cannot reproduce it?

Record the exact build, fake data prerequisites, sequence and relevant timing. Reduce the case and pair on a shared environment; intermittent failures need attempt counts and preserved failures rather than “always happens” language. If evidence remains inconclusive, mark it as an investigation with uncertainty instead of forcing a definitive root cause.

8. How do you explain what happened after the fix?

Describe direct retesting and adjacent regression separately. For the discount example, direct retesting checks the original multi-item cart; regression checks ineligible items, boundaries and persisted totals. Mention a lasting prevention change only if it occurred, such as adding a focused regression test or clarifying acceptance criteria.

Likely follow-up: How much money did you save? Do not extrapolate hypothetical loss into a claimed saving. State the verified incorrect behaviour and say the financial impact was not measured.

9. What if you have no production bug story?

Use a real staging or practice defect and state where you found it. A practice report can demonstrate reproduction, expected results and investigation without implying paid work. Do not relabel a tutorial's known bug as an original discovery; explain what you independently tested and learned.

10. What should you remove before sharing evidence?

Remove customer details, tokens, private endpoints and confidential business data. Recreate the minimal case with obvious fake values when permitted. The interview answer should explain your method without requiring the interviewer to view proprietary screenshots or records.

Practise it

Investigate one issue in ShopLite, write a report and keep your observations separate from guesses. Rehearse a short answer and a deeper follow-up. Say “practice project” each time you use it as experience evidence.