How to answer the defect before go-live interview question

The short answer

Interview Coach asks this question in these words:

Tell me about a defect or a gap you caught before go-live. How did you find it, and what happened next?

Pick one defect or requirements gap you caught before it reached production, ideally in user acceptance testing. Say what it was and how you found it: a test case, a data check, a question nobody asked. Then say what you did and who decided on the fix, and end with what it would have cost if it had gone live, from a record you can name.

What the interviewer is checking

This question checks rigour. Interviewers want to hear how you look for problems, not that you were lucky once. The bank lists three things a strong answer does:

  • Describes the defect or gap and how you found it. A rounding rule wrong for one currency, a field that dropped leading zeros, a missing approval step. And the test or check that found it.
  • Says what you did and who decided on the fix. Who you told, with what evidence, and who had the right to decide between fixing, delaying or going live with a workaround.
  • Names what it would have cost if it had reached production. Refunds, fines, manual work, customer calls. Put a figure or a record on it if you can.

Avoid presenting the developers as careless. A gap found in testing is the process working; your part is that you looked.

A structure that works

Interview Coach describes a story answer in five parts:

  1. Situation. Two or three sentences on the context and what was at stake. Here: the system, the release and the gap.
  2. Action. What you did yourself, said with I, in the order you did it. Here: how you found it and what you did next.
  3. Result. What changed, and how you know. Here: the fix decided and the go-live.
  4. Evidence. A figure before and after, or a record a reader could ask for. Here: the defect tracker, the test report or the go-live sign-off.
  5. Length. About one to two minutes when spoken. Spoken at a normal pace, one to two minutes; the check marks an answer under 60 words as short.

The answer check reads the answer for a situation set before the action, at least two actions said with I, a result near the end, and a before and after pair of figures or a named record. It also reads the balance between "we" and "I", the length of a spoken answer, and words that weaken an answer: filler, hedges, weak ownership and vague claims.

Answers as written, and what the check says

Illustrative, not a real client. Each answer below was sent on its own through the answer check of Interview Coach. All of them are also marked short for a spoken answer, because each is one or two sentences; the table shows the other finding, word for word, and one way to fix it.

Answer as writtenWhat the check saysWhat to change
When user acceptance testing was underway for the new billing system, a rounding gap was traced in the test invoices and logged with evidence for the product owner, and the fix was approved before release, per the test report.No sentence says what you did yourself, with I.Say which of these steps were yours, with I.
When user acceptance testing was underway for the new billing system, I traced a rounding gap in the test invoices, and the fix was approved before release, per the test report.Only one first person action found. Say what you did yourself.Add the second step that was yours, in the order you took it.
When testing was underway, we ran tests, we compared invoices, we checked totals, we logged defects and we retested fixes. I traced the gap and I logged it, and the fix was approved, per the test report.Mostly we and the team. The interviewer cannot tell which part was yours.Give the team's work one sentence, then say which calls were yours.
I traced a rounding gap in the test invoices and I logged it with evidence for the product owner, and the fix was approved before release, per the test report.No context is set before the action. Add what was at stake.Open with what was at stake before you acted.
When user acceptance testing was underway for the new billing system, I traced a rounding gap in the test invoices and I logged it with evidence for the product owner, per the test report.No result is named. Say what changed.Say what changed in the end, and where it shows.
When user acceptance testing was underway for the new billing system, I traced a rounding gap in the test invoices and I logged it with evidence for the product owner, and the fix was approved before release.No figure and no named record. Name where the result shows, if you have it.Name where the outcome is recorded, or give the figure before and after.
When user acceptance testing was underway for the new billing system, I traced a rounding gap in the test invoices and I logged it with evidence for the product owner, and the fix was approved before release with 2 days to spare.A figure is given, with no starting point.Give the starting figure too, or name the record that holds both.
When user acceptance testing was underway for the new billing system, I basically traced a rounding gap in the test invoices and I logged it with evidence for the product owner, and the fix was approved before release, per the test report.Filler words found.Drop the filler word and say the step plainly.

The check never adds a figure or a record for you. If the defect went live with a workaround, say who accepted the risk.

An illustrative answer

Illustrative, not a real client. Every figure is invented. This answer gets all nine marks of the story check: length, situation, own action, team versus me, result, evidence, and no vague words, filler or hedges.

When a utility company was in user acceptance testing for its new billing system, I compared a sample of test invoices with the same customers' invoices from the old system, line by line. I found that the new system rounded each line item before adding the tax, while the old one rounded the total, so customers with many line items were overcharged by a cent or two per line. I wrote it up in the defect tracker with twenty examples and the rule from the tariff document, and I took it to the product owner and the finance lead the same day. They decided to fix it before go-live rather than refund later. The fix was retested and signed off nine days before the go-live date, per the test report. Finance estimated that the error would have touched 140,000 invoices a month and forced a refund run the regulator would have had to approve.

Why it works. The gap is concrete and so is the method that found it. The analyst brings evidence to the people who decide, the decision and the fix are recorded, and the cost of missing it is stated by the people who own that cost.

What the check cannot see

The answer check reads the words of your answer, not the testing behind them. This answer, sent on its own, gets every mark except length:

When testing was underway, I traced a gap and I logged it, and the fix was approved, per the test report.

Structurally complete, and an interviewer would still ask: what gap, how did you find it, who decided, and what would it have cost? A defect story without the method is hard to tell apart from luck.

Choosing your story

  • Pick a gap found by method. A comparison, a test case, a data profile. The method is what the interviewer is buying.
  • Pick one with a decision. Fix, delay or accept with a workaround: someone chose, and you prepared the choice.
  • Pick one with a cost you can state. Money, regulatory exposure, manual work. If you do not know the figure, name who estimated it.
  • A requirements gap counts. A missing rule found before build is the same story, often a better one.

Your resume is where an interviewer looks for these stories, and a line such as "led user acceptance testing" invites this question. Get a free AI review of your resume and see which lines Reed flags first.

Prepare the follow-up questions

  • How do you decide what to test when time is short?
  • What would you have done if the product owner had chosen to go live anyway?
  • Which defect did you miss, and what did you change afterwards?

Check your answer with Interview Coach in Claude

This question is in the business or process analyst track of the Interview Coach question bank. Write your answer the way you would say it and ask for a check.

  • It reads the answer for a situation, your own action said with I, a result, and a before and after figure or a named record.
  • It flags filler, hedging, weak ownership and vague claims, and says when the answer is short or long for a spoken answer.
  • It does not judge whether the story is true or good, and it never adds a figure you did not give.

Your answers start from your resume. The free review quotes your own lines and flags the 5 to fix first, so you know which lines an interviewer may question.

Free in Claude, no account. We do not store the text you send through it.

Questions

What if I am not a tester?

Most analysts are not. The question is about catching a gap before it reaches users, in testing, in a requirements review or in a data check. Say where you looked and why.

Is this question only for business analysts?

It is in the business and process analyst track of the Interview Coach question bank. Quality leads, product owners and project managers who ran acceptance testing meet it too.

Does Interview Coach know whether my story is true?

No. Interview Coach runs in Claude and checks the structure of an answer by fixed rules: a situation, your own action, a result, a figure or a record. It does not judge whether the story is true or good. You decide what to say.

Keep going

Last updated: October 14, 2026