Machine Learning Engineer Interview Questions: From Model to Reliable Service

Machine learning engineer interview questions should give you room to explain more than model selection. A model can score well offline and still fail because its inputs, timing, or serving behavior do not match the intended product.

Google's Rules of Machine Learning emphasizes simple baselines, dependable infrastructure, and checking differences between training and serving. The scenarios below are original exercises, not questions reported from a particular employer.

A useful feature is unavailable at prediction time. What do you do?

Consider a fictional support system that predicts whether a newly opened ticket needs specialist handling. Someone proposes using the ticket's final resolution category as a feature because it strongly predicts the label.

Ask when each field becomes available. A value entered after resolution cannot be treated as an input to a prediction made when the ticket opens. The model would be answering an easier retrospective question than the product actually asks.

Field	Available when the ticket opens?	Use in the proposed prediction
Initial customer message	Yes, under this scenario	Candidate input
Product selected in the form	Yes, under this scenario	Candidate input
Final resolution category	No	Exclude from opening-time inputs

Explain how you would reconstruct what was known at the decision point. A field having a value in today's export does not prove it had that value then. Also check whether processing delays make an otherwise legitimate feature unavailable in practice.

Offline results are strong, but live performance falls. Where do you look?

Start by checking that the compared populations, labels, and metrics match. Then inspect input transformations, missing values, feature freshness, model versions, and differences in the requests reaching the service.

An illustrative answer:

I would compare a permitted sample of serving inputs with the corresponding training representation, checking when each value was produced. I would verify the model and preprocessing versions together. If those agree, I would investigate population changes and evaluation delay rather than immediately retraining a larger model.

This is a diagnostic sequence, not proof of a particular cause. Describe the evidence that would confirm or weaken each hypothesis.

How would you choose a first baseline?

Clarify the decision being supported and the cost of a wrong recommendation. Compare a simple model or an appropriate non-ML rule with the proposed system using a relevant evaluation setup. A baseline should reveal whether the added complexity earns its place.

Do not choose a metric solely because it is familiar. A system that routes work to a small specialist team may need to account for that team's capacity, not just rank all tickets accurately on average.

A more accurate model is slower. Would you ship it?

Ask how much latency the user journey can tolerate and how the improvement was measured. Compare end-to-end response behavior, not only model inference in isolation. Include feature retrieval, serialization, and the response path in the discussion where relevant.

State a bounded evaluation plan with acceptance criteria. If the workload is asynchronous, the useful deadline may differ from an interactive request. There is no universal latency number that makes a model deployable.

Labels arrive days later. How do you monitor the release?

Separate immediately observable service health from model-quality evidence that needs mature outcomes. A functioning endpoint does not establish useful predictions. Early proxy measures may help detect problems, but label them as proxies.

Explain how you would preserve the link between a prediction, its version, and its eventual outcome without retaining unnecessary personal data. Ask who reviews drift signals and who can pause a rollout.

Prepare a project story with technical interview guidance. Practice acknowledging an unknown with this technical-answer guide; clear assumptions are stronger than claiming that one architecture fits every model.