incident response

A principal-level question about recovering from failure in public. Apologies are necessary and not sufficient; users come back when the product visibly changes and the company keeps its promises.

Every AI product depends on services it does not control. The interviewer wants a degradation plan by feature, written and tested before the outage starts.

An incident question where the root cause is almost never 'the model made a mistake'. The interviewer wants containment first, honest communication, and a fix to the permission design that made deletion possible.

Green dashboards and angry users at the same time. The strong answer treats the complaints as evidence about the eval, not noise to explain away.

Rank surviving signals by what they actually prove, decide when to pause exposure and reconcile missing events without inventing outcomes.

AI incidents often have no outage, no error and no deploy: just a model saying or doing something harmful at scale. The plan has to detect those, contain them fast, and learn from them.

Part incident response, part communications, part safety engineering. The interviewer wants a calm sequence: verify, contain, fix the class of attack rather than the one prompt, and communicate honestly.

Crises reveal leadership. Panels want calm prioritisation, clear roles, honest communication, care for the team, and a lasting fix rather than heroics.