TL;DR: The disclosure timeline is the test, not the bug. Pick a real incident you caused, then show you called the customer within the hour of confirming it, before root cause, with a clean structure: what happened, impact on you, what we're doing, next update time.
How to approach it
Two questions hide inside this one. The surface question is competence under fire. The real question is disclosure ethics: when you broke something at a customer, how long did you sit on it? FDEs operate inside customer trust, and the interviewer is measuring the gap between "you knew" and "they knew." Pick an incident where you (or your team) caused harm, data wrong, system down, money lost, not a near-miss, and structure the story around the communication timeline as much as the technical fix.
A strong answer
"During a deployment I shipped a pipeline change that silently double-counted transactions in the customer's revenue dashboard, the one their CFO looked at. We caught it nine days later; the numbers had been wrong the whole time.
What I told them and when: within the first hour of confirming the bug was real, before we fully understood the blast radius, I called our customer counterpart. The message was: 'We found a defect we introduced. Your revenue dashboard has been overstating by roughly 3–6% since the 14th. We don't yet know the exact extent. Treat those numbers as suspect, here's what we know, next update at 4pm.' I did not wait for the root cause, because every hour they made decisions on bad numbers was harm we were choosing.
The structure I follow: what happened, what's the impact on you, what we're doing, when you'll hear from me next, and never speculate beyond what's confirmed, never blame, and give the next-update time even when there's no news. We sent corrected historicals in 48 hours, then a written post-mortem with the fix and the regression test that now guards it.
The counterintuitive outcome, and the reason I'd do it the same way again, is that the relationship got stronger. The CFO told our sponsor it was the first time a vendor had called them before they noticed. Trust isn't built by never breaking things; it's built by what you do in the first hour after."
The timeline is the answer, and the gaps in it are what get scored:
| Moment | What a strong answer contains |
|---|---|
| You detected it | How, and whether it was your alerting or their phone call |
| You told them | Early, incomplete, and before they asked. This is the whole question |
| You contained it | Narrowed capability rather than switching everything off |
| You established blast radius | Who was affected, and whether you could actually say |
| You resolved it | And what you said when you were not yet sure |
| Afterwards | What changed in the system, not in your intentions |
If the customer found out before you told them, say so plainly. Everyone in the room has had that happen; what they are listening for is whether you learned to shorten that gap.
It is worth rehearsing what the first call sounds like when you know almost nothing, because that is the moment people freeze and the hour slips away. The version that works is built entirely from confirmed facts plus explicit ignorance: "We found a defect we introduced. It affects your revenue dashboard. We believe the overstatement started around the 14th; we do not yet know the exact size or whether anything downstream consumed those numbers. Treat them as suspect until we say otherwise. Next update at 4pm either way." Every sentence is either verified or labeled unknown, which means nothing in it needs retracting later. Two sentences to never say in that call: "it looks minor" before you have measured blast radius, because if it grows you have now misled them twice; and "we'll have it fixed by tonight" before you have a root cause, because a missed promise in hour two converts a technical incident into a credibility incident. The discipline is asymmetric on purpose: over-disclose uncertainty, under-promise resolution, and let the 4pm update be where good news arrives if there is any.
What interviewers probe next
- "Why nine days to catch it?" Own the detection gap honestly, that's where your monitoring lesson lives ("we now alert on day-over-day deltas beyond X%").
- "What if your own leadership said wait before telling the customer?" The strong answer: escalate fast and argue for disclosure, silence compounds; if overruled on timing, get the reason and the new deadline in writing.
- "What did the post-mortem change?" Name a durable mechanism: a check, a gate, a runbook, not "we're more careful now."
- "Were there contractual/SLA implications?" Showing awareness that disclosure has legal texture (loop in your account lead, don't freelance on liability language) reads senior.
Common mistakes
- Picking a sanitized non-incident ("we almost had an outage"). They asked for your worst; a clean record reads as either inexperience or evasion.
- A timeline where you quietly fixed it and never told the customer. Instant fail at trust-sensitive companies.
- Blaming the customer's data, a teammate, or the provider. First-person ownership is explicitly scored.
- All technical detail, no communication detail. The question literally asks what you told them and when, answer that question.