incident response

The staff-level reliability question for agent platforms. Refunds went out, emails sent, tickets closed, and now you have to triage at fleet scale without double-refunding. The recovery model interviewers actually score.

A wrong answer inside one conversation dies with the conversation. A wrong answer written to memory becomes a retrievable fact that conditions every later run, and the agent then derives new conclusions from it. Deleting it is the part nobody designed for.

Nobody deployed anything is true of your repository and false of the system. The model provider, a tool behind an API, the knowledge base and the traffic mix all change without a commit. Segmentation comes before theory: a broken intent and a mix shift produce the same headline and need different fixes.

The signature production-ML incident, and a pure FDE test: a ranked differential diagnosis run live on a call, because 'nothing changed' is always false, and one hypothesis explains half of all cases.

This isn't a deployment question, it's a judgment question wearing one. Interviewers are scoring whether you have a decision framework, a safety checklist, and the spine to say no to a customer politely.

A signature FDE triage question with a hidden rubric: interviewers score the *order* of your moves, not just the list. There's a reason 'what changed?' beats 'check the dashboards', and a reason mitigation beats diagnosis.

The nightmare scenario every agent deployment signs up for. Interviewers grade the first hour hardest, containment before diagnosis, honoring the invented policy, and who you call in what order.

A board isn't an engineering audience and the postmortem they want isn't the one you'd write for your team. Lead with the wrong thing and you confirm their fear that this is unmanageable. Here's the board-grade structure, blameless but accountable, that restores confidence.

Reported from JPMorgan's MLE loop, and graded on one distinction most candidates miss: rollback is a capability you build before the incident, not an action you improvise during it. The pointer-flip mechanics, the auto-trigger debate, and when rollback itself is unsafe.

An incident question graded on method, not tools: interviewers want ordered hypotheses, each with a five-minute test. The version-skew check most candidates never think of, the cache trap, and the triage tree that finds the usual culprit fast.

The lead-level capstone: not 'which metrics' but 'what's your operating program.' SLOs per model, a drift policy with teeth, retraining as routine rather than rescue, and the inventory discipline that separates teams who run models from teams who babysit them.

The incident with no onset spike and no pager: precision bled out over weeks while every dashboard stayed green. How to run a blameless postmortem when the incident has no clean start time, the root-cause classes that hide this long, and the action items that actually prevent the next one.

An ambiguous, time-pressured staff scenario: the signal is soft, labels won't confirm anything for weeks, and rollback itself has risks. The decision framework under uncertainty, when to revert on a proxy, and the remediation for decisions the bad model already made.

The staff on-call simulation: three alarms at once, partial information, and pressure to do something. How to separate symptom from cause, the common-cause hypothesis that explains all three, and why mitigating before diagnosing is the senior move, not a shortcut.

ATLAS questions filter candidates who can name the framework from those who can run an incident through it. The mapping exercise, one concrete attack, kill-chain stage by stage, is what the interviewer actually wants to hear.

The capstone governance round: AI incidents break standard IR playbooks in three specific places, containment without rollback, blast-radius over probabilistic systems, and root cause for nondeterministic behavior. Interviewers grade you on knowing which three.

Cross-tenant or cross-user data exposure through a model is the breach that starts regulatory clocks. The runbook has to answer 'whose data, to whom, how many' from logs that most teams never designed for, and contain a leak that may live in a cache or a fine-tuned model, not a deploy.