Loading...
Loading...
Browse 6 real-world technical and behavioral interview questions about Drift. Review scenarios, edge cases, and architectural best practices.
Data drift is a change in the distribution of the inputs; concept drift is a change in the relationship between inputs and the outcome. You can detect data drift from inputs alone, concept drift needs labels or a performance signal, and only concept drift necessarily invalidates what the model learned.
Retrain when there is evidence the learned relationship no longer holds and you have data that reflects the new one. A fixed schedule is a fallback for when you cannot measure that, not a decision, and a drift alert is as likely to mean an upstream pipeline broke as it is to mean the world moved.
Monitor what is available immediately: input distributions and data quality, the prediction distribution, and proxy outcomes that correlate with the label but arrive sooner. Do all of it per segment, because a small segment failing badly is invisible in an aggregate.
Check whether training and serving compute the same features from the same definitions, because the usual cause is two implementations that disagree slightly. Nothing raises an error when they diverge - the model receives plausible numbers that mean something different from the ones it learned on.
Features must be computable at decision time, training and serving must share one transformation implementation, the model and dataset version must be pinned together, drift and realised performance monitored separately because labels arrive late, and rollback must move model and features as one unit.
State is the mapping from a config address to a real resource ID, so it is the only thing that tells Terraform whether to create or update. Drift, imports, refactors and concurrent applies are all consequences of that mapping being separate from both the code and the infrastructure.