Tell me about a model that failed in production: root cause and permanent fix

In this article

1. Before you start
2. Why interviewers ask this
3. A model that failed in production from first principles
4. The Staff-level answer
5. The rubric
6. Three variants of this question
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This question belongs to the behavioral interview guide, and the story format is the one in how to answer interview questions.

Why interviewers ask this

A failure story shows whether you own the whole system around a model, not only the model. Candidates report versions of this question at AI labs and large technology companies, often worded as "tell me about a time a model failed in production", "a model that didn't work", "performance degradation" or "good metrics but a poor user experience".

A weak answer blames bad data or another team and ends with "we retrained it". A strong answer is specific about the stake, says how the failure was found and how long it ran, names one root cause with evidence, and describes a change that stops the whole class of failure. Interviewers may also listen for ownership and honesty about what you got wrong. How a given company scores this is not public, so treat that as advice, not a rule; the Google behavioral question guide and the Amazon Leadership Principles page show how such stories are framed for two employers.

A model that failed in production from first principles

Drift

Drift is a change over time in the data a deployed model sees, or in the link between inputs and outcomes, that makes the old training data a poorer guide and quietly lowers quality without raising any error message.

In plain words

Think of a car that passes inspection in a garage. On real roads, weather and potholes change how it behaves. A model is the same: it is tested on past data, then meets a world that moves.

The analogy breaks in one place. A car rattles when something is wrong. A model keeps driving smoothly and simply gets worse.

In one precise sentence, a production failure story explains how a deployed model stopped doing its job, how you found out, why it happened, and what you changed in the system so it could not happen the same way again. Google's guidance says the same thing about the symptom: Rule 10 of Rules of Machine Learning is to watch for silent failures.

1 · Stake2 · Detection3 · Root cause4 · Permanent fixReplay

Step-by-step description

1. Name the model, the user and the cost.
2. Say what showed it and why nothing alerted sooner.
3. One cause, with evidence.
4. A check and an owner.

• A strong failure story names the stake, how it was found, the root cause and a permanent fix.
• The story ends on a change to the system.

Step 1: Name the model, the user and the stake

The first part of the story names what the model did, who depended on it and what was at risk, in two or three sentences. A reader should know whether the model ranked products, flagged fraud or routed support tickets, and what a wrong output cost in money, time or trust.

Keep this short. The interviewer needs enough context to judge how serious the failure was, not a tour of your architecture. If you can, state your own role in one clause: you built it, you inherited it, or you owned the on-call rotation.

Pick a stake you can state without an invented number. If you have a real figure from your work, use it. If you do not remember it, say "a large share of requests" instead of guessing. You now have the opening; the next part is the one interviewers remember.

Step 2: Say how you found out, and why nothing alerted sooner

The detection part says what showed the failure and how long it ran before anyone noticed. This is the part that separates levels, because machine learning systems can degrade without any error. Google's engineers write that the system adjusts and behavior decays gradually, and a Google Cloud post of 2021 describes a case where the model kept generating predictions with lower accuracy and no error.

A concrete picture helps. In an illustrative decay, the model's AUC (area under the receiver operating characteristic curve, the probability that the model scores a randomly chosen positive example above a randomly chosen negative one) starts at 0.84 and falls to 0.72 by week 7. An alert on a drop of 0.03 would first fire in week 4.¹ If a team only checks uptime and latency, no alert fires at all.

Text description of the diagram

• Illustrative AUC is 0.84 in week 0 and 0.72 in week 7.
• A drop of 0.03 from launch is first reached in week 4.

Say honestly what noticed it: a business metric, a user complaint, a dashboard you built afterwards. Then say what was missing. The answer to "why nothing alerted sooner" is the part you will fix in Step 4.

Step 3: Name one root cause and show the evidence

The root-cause part states one cause, the evidence for it, and why the model code itself was or was not at fault. The Google Cloud post lists three common causes of training-serving skew: a discrepancy in how data is handled in the two pipelines, a change in the data between training and serving, and a feedback loop. In its incident example, a serving-stack refactor pinned one feature to -1 while the model itself was fine.

Evidence beats assertion. A simple one is a distance score between the training and serving distributions of one feature. A population stability index (PSI) is such a score:

Here $p_i$ and $q_i$ are the shares of examples in bin $i$ in training and serving. For an illustrative feature split into three bins, a shift from 25%, 50%, 25% to 10%, 45%, 45% gives a PSI of 0.2603.¹ The cutoff for "too high" is a team choice; say which you used.

A feedback loop needs a different fix from drift, because serving data reused for training makes the problem persist and get worse until it is discovered.

Step 4: Fix it with a permanent check, not a promise

The last part describes what you changed so the whole class of failure is caught next time, which is a check in the system, not a resolution to be more careful. Sculley et al. (2015) argue that machine learning systems are cheap to ship but costly to maintain over time, and that "all debt needs to be serviced".

Monitor input data for change, which Google calls just as important as writing unit tests. Check that the same model gives the same score in training and serving. Decide how fast the model goes stale and set the retraining and alert schedule to match, as Rule 8 advises. Detection speed matters: with an illustrative 200,000 requests a day and 30% affected, a weekly check leaves up to 420,000 bad predictions before detection, against up to 60,000 for a daily check.¹

Close with the result, then one sentence on what you do differently now.

The Staff-level answer

The answer above is an illustrative composite. The spoken structure is stake, detection, root cause, permanent fix. It is Staff-level because it admits the monitoring gap, shows evidence for the cause, and ends with changes to the system and an owner, not a vow.

For contrast, a weak answer to the same question sounds like this: "We had a model that stopped working well. The data was bad, so we retrained it and it was fine. I would be more careful next time." It gives no stake, no detection, no evidence and no change to the system, which is why it sits in the weak column of the rubric below.

The rubric

Three variants of this question

Tell me about a time an ML model you deployed started showing performance degradation

Lead with detection and drift: which metric fell, over what period, and what check you added. Candidates report this wording at large technology companies.

Describe a model that missed its business goal despite strong held-out metrics

Name the gap between the metric and the user outcome, such as a held-out score that ignored how the model is used, then say what you measured in production and what you changed permanently.

Tell me about a model that didn't work and what you did

The "didn't work" version allows a failure before launch too. Use the same four parts, and if it never reached production, say so and name the check that stopped it.

Common mistakes

• "The model was fine, the data was bad." (wrong) It blames a layer without evidence. (right) "A serving change altered one input; I showed it by comparing live and training distributions."
• "We retrained and it was fixed." (wrong) It names no cause and no prevention. (right) "I rolled back the change, retrained, then added an input check and a training-versus-serving test."
• "Nothing went wrong until users complained." (wrong) It hides the monitoring gap. (right) "Our alerts watched uptime, not quality, so I added a quality and input check."
• "I'd never make that mistake again." (wrong) It is a promise, not a mechanism. (right) "The check now runs on every deploy and has a named owner."

Follow-up questions

How do you detect a model that is failing silently?

Compare live input distributions and prediction outputs with a training baseline, and track a quality metric against delayed labels or a business outcome. Google's monitoring example compares serving data with a training baseline using a distance score and a threshold, with a default window of 24 hours.

What is the difference between data drift and training-serving skew?

Drift is a change in input data over time. Skew is a gap between training and serving, which drift can cause but a pipeline mismatch or a feedback loop can cause too. The fixes differ.

What did you change permanently so it could not happen again?

Name a check, a test or an owner, not an intention. More on how such stories are judged is in the behavioral interview guide.

What if you have never had a model fail in production?

Use a model that degraded, a pre-launch failure you caught, or a failure in a shared system, and say which it was. The same four-part shape works in a teamwork STAR story.

Should you say the failure was your fault?

Say what you owned and what you got wrong, without dramatizing it. The same honesty is tested in the greatest weakness question, and common interview questions shows where else it appears.

Sources

1. Rules of Machine Learning: Best Practices for ML Engineering (Martin Zinkevich) — Google for Developers, 26 Oct 2026
2. Monitor models for training-serving skew with Vertex AI (Sato and Iyer) — Google Cloud Blog, 31 Jul 2021
3. Hidden Technical Debt in Machine Learning Systems (Sculley et al.) — NeurIPS 2015 proceedings, 1 Dec 2015