Why version data and model artifacts, not just code
reproducibility discipline.
code alone cannot reproduce a model; data and artifact versioning enable rollback, debugging, audit.
thinking Git on code suffices, or ignoring rollback and regulatory traceability.
What's really being asked
This checks whether you understand that a trained model is the joint product of code, data, and configuration, so reproducibility and recovery require versioning all of them. It rewards a concrete failure scenario.
The full answer
Unlike traditional software, where the same code reliably produces the same binary, an ML model depends on the training data and hyperparameters as much as the code. If you version only the code, you cannot reconstruct exactly which model was running when something broke, nor reproduce it for debugging. Versioning the training data, the trained model artifact, and the config gives you several capabilities: exact reproducibility of any past model, fast and safe rollback to a previous known-good version when a new release misbehaves, the ability to diagnose a regression by comparing what changed across versions, and audit or regulatory traceability proving which data and model produced a given decision. It also enables A/B comparison and lineage tracking from a prediction back to its inputs.
The mistakes people make
Claiming Git on the code is enough. Ignoring rollback, so you have no way to revert when a deploy degrades performance. Forgetting compliance and audit needs in regulated domains. Assuming the data is static and never changes.
What usually comes next
What tools enable data versioning at scale? How do you link a prediction back to the exact model and data that produced it? How do you store large artifacts efficiently?
A concrete example
An upstream ETL job silently changes how a key feature is computed. The next scheduled retraining ingests the altered data and the new model's quality quietly drops in production. Because only code was versioned, the team cannot reproduce or roll back to the previous model and spends days reconstructing what changed. With data and artifact versioning, they would have immediately rolled back to the last good model and diffed the data versions to find the ETL change in minutes.
Interview question
Why is versioning only your training code insufficient for reproducing a deployed ML model?
- a.Data is always identical across training runs
- b.Code versioning systems cannot store Python files
- c.Models never change once the code is fixed
- d.The model also depends on the specific data and config used to train itCorrect
Why? this is the answer
A trained model is a function of code, data, and hyperparameters, so the same code on different data yields a different model. The other options are false: VCS handles code fine, models change with data, and training data is not guaranteed stable.
Just read this? Test yourself on what you have been reading.
Read the original → atlan.com
- #model-versioning
- #data-versioning
- #reproducibility
- #rollback
- #mlops
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles