Move the logic out of cells into tested modules, with feature engineering shared between training and serving so the two cannot diverge. Wrap training as a parameterized job, serialize the whole pipeline including preprocessing rather than just the estimator, and expose scoring behind an interface with input validation. Add monitoring on inputs and predictions before launch, not after.
Why interviewers ask this
The interviewer is checking whether you can hand something to engineers without them rewriting it. The critical point is one shared feature transformation path, because reimplementing features in the serving language is the classic source of training serving skew. Serializing the full pipeline and adding monitoring up front are the other markers of someone who has actually operated a model rather than just trained one.
How to structure your answer
- Describe pulling logic out of cells into importable, tested functions.
- Insist on one shared feature path for training and serving.
- Serialize the whole pipeline, not the bare estimator.
- Add input validation and monitoring before it goes live.
Example answer
The notebook is where I figure out what the model is, not what ships. First move is pulling the logic into a module with functions I can import and test, plus a couple of unit tests on the feature transforms using a tiny fixture, because that is where the subtle bugs live. The rule I am strictest about is that training and serving call the same feature code. The moment someone reimplements the features in the service, they drift, and you get a model scoring differently in production for reasons nobody can find for a week. Then I serialize the whole pipeline, imputer, encoder, scaler, model, as one object, so serving cannot forget a preprocessing step. Training becomes a job that takes a config and a date range and writes a versioned artifact. On the serving side I validate inputs and reject or default anything out of range rather than silently scoring garbage. And monitoring goes in before launch: input distributions, prediction distribution, null rates, latency. If I only get one of those, I take input drift, because that is what changes first.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you handle features that need real time aggregation at serving time?
- What does a good rollback plan for a model look like?
- How do you test a model pipeline in continuous integration?
Related data scientist questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions