In this article
What an ML platform is and what it costs
Platform roles often include design conversations, so practise saying these answers aloud; for the coding half of the loop, use the coding interview guide.
What does an ML platform engineer do?
An ML platform engineer builds the shared systems that take models from training to deployment and monitoring, so each team does not rebuild them. Google Cloud's guidance frames the work as automating three loops: continuous integration (CI), continuous delivery (CD) and continuous training (CT) (Google Cloud, machine learning operations (MLOps) pipelines, reviewed August 2024). Expect questions on pipelines, registries, features, serving and monitoring.
Why it is asked: it shows whether you treat the platform as a product with users, not a notebook server. Read the full explanation: Google Cloud, MLOps pipelines.
Why is technical debt in ML systems different from ordinary code debt?
Sculley et al. argue that ML systems have "all of the maintenance problems of traditional code plus an additional set of ML-specific issues" (Sculley et al., 2015). They name boundary erosion, entanglement, hidden feedback loops, undeclared consumers and data dependencies. The debt sits at the system level, so refactoring code alone does not pay it down.
Why it is asked: it separates people who have run models in production from people who have only trained them. Read the full explanation: Sculley et al., 2015.
How is CI/CD for ML different from CI/CD for software?
In ML, CI is not only about testing code. Google Cloud's guide says CI also covers "testing and validating data, data schemas, and models" (Google Cloud, MLOps pipelines). Delivery usually ships a training pipeline, which in turn produces and releases the model. Add continuous training, because models decay in more ways than conventional software.
Why it is asked: it checks that you do not copy a web-service pipeline onto models. Read the full explanation: Google Cloud, MLOps pipelines.
Pipelines and data
What is a Kubeflow pipeline?
Kubeflow Pipelines (KFP) is "a platform for building and deploying portable and scalable machine learning (ML) workflows using containers on Kubernetes-based systems" (KFP documentation). A component is a remote function definition with inputs, logic and outputs; instantiated with parameters it becomes a task. A pipeline is a directed acyclic graph (DAG) of those tasks, and each step runs as containers on the cluster.
Why it is asked: orchestration vocabulary is basic for the role. Read the full explanation: KFP overview.
How do you make a training pipeline reproducible?
Record everything that determines the output: the code version, the exact data snapshot, the configuration, the random seeds and the container image. Store them with the resulting model so any run can be repeated or audited. A pipeline that reads "the latest table" cannot be reproduced, and a configuration changed by hand is one of the system-level risks the technical-debt paper lists.
Why it is asked: it tests engineering discipline over modelling skill. Read the full explanation: Sculley et al., 2015.
How would you design the data platform under ML?
Describe layers in order: ingestion, durable storage, transformation, a feature layer, then training and serving readers. Add schema checks and ownership at each boundary, because the debt paper names data dependencies and undeclared consumers as risks. Say who owns each dataset, how a change is announced, and how training and serving read the same definitions.
Why it is asked: the data layer decides whether models stay trustworthy. Read the full explanation: Sculley et al., 2015.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Models, registries and releases
What is a model registry, and why not just use file storage?
A model registry is a central store with a programming interface and a user interface that manages the lifecycle of models. MLflow's registry adds lineage (which experiment and run produced the model), versioning, aliases, tags and annotations (MLflow Model Registry docs, as of October 2026). Plain files give you none of that history or control over what serves traffic.
Why it is asked: it checks whether you know what a release needs beyond bytes. Read the full explanation: MLflow Model Registry docs.
How do you promote a model without changing consumer code?
Use a mutable alias. A registry alias points serving at one model version, and MLflow documents reassigning an alias such as champion to update what serves production traffic (MLflow Model Registry docs, as of October 2026). Consumers load the model through a uniform resource identifier (URI) that ends in the alias, so moving the alias from one version to the next changes nothing in their code. Older docs used fixed stages instead.
Why it is asked: it tests release mechanics and rollback. Read the full explanation: MLflow Model Registry docs.
How do you roll out a new model safely?
Use a canary release. A canary release is a method of sending a small share of traffic to a new version while the rest stays on the current one, so problems appear on little traffic. In an illustrative 90/10 split of 1,000 requests, 900 go to the current model and 100 to the candidate.1 As one example, MLflow's gateway documents traffic splitting for A/B tests and gradual rollouts (MLflow AI Gateway docs). Compare metrics, then widen or roll back.
Why it is asked: it checks risk control, not just deployment. Read the full explanation: MLflow AI Gateway traffic routing.
Text description of the diagram
- A registry alias points serving at one model version.
- Monitoring alerts or rolls back when values deviate from expectations.
Features and governance
What is a feature store?
A feature store is a system that defines features once and serves them both for training from historical data and for live requests from a low-latency store. Feast describes a single interface for defining, storing and serving features, used both to build training data and to serve live requests (PyTorch Foundation blog, Feast). One definition avoids two code paths that drift apart.
Why it is asked: it tests whether you can keep training and serving consistent. Read the full explanation: Feast on the PyTorch blog.
What is point-in-time correctness?
Point-in-time correctness is the rule that each training example sees only the feature values that existed at its label's timestamp. Feast lists it as preventing data leakage by managing historical feature states (PyTorch Foundation blog). Illustrative case: a feature is 3 at time 1 and 4 at time 5; a label at time 4 must see 3, while a "latest value" join leaks 4.1
Why it is asked: leakage makes scores on held-out data look better than production. Read the full explanation: Feast on the PyTorch blog.
What is training-serving skew and how do you prevent it?
Training-serving skew is a gap between the feature values a model saw in training and those it receives in production, usually because two code paths compute them differently. Prevent it by sharing one feature definition for both paths, as a feature store does, by logging served features for later training, and by comparing summary statistics of live and training data.
Why it is asked: a model can look healthy in training and degrade in production when the two paths differ, so it tests data discipline. Read the full explanation: Google Cloud, MLOps pipelines.
What should ML platform data governance cover?
Cover lineage, schemas, ownership and access. Lineage means being able to say which run and data produced a model; MLflow's registry records exactly that for experiments and runs (MLflow Model Registry docs, as of October 2026). Add schema validation in pipelines, since CI for ML tests data schemas, and clear owners and access rules for each dataset and model.
Why it is asked: regulated teams must explain where a model came from. Read the full explanation: MLflow Model Registry docs.
Monitoring and GenAI platforms: LLM gateways
How do you monitor a model in production, and when do you roll back?
Monitoring alerts or rolls back when values deviate from expectations. Google Cloud advises tracking summary statistics of your data and the online performance of the model, then sending notifications or rolling back (Google Cloud, MLOps pipelines). Set thresholds before launch, keep the previous version one alias change away, and retrain on a schedule, on new data, or when monitoring shows decay, saying which trigger fits the use case, as the same guide lists.
Why it is asked: shipping is the start of the work, not the end. Read the full explanation: Google Cloud, MLOps pipelines.
What is an LLM gateway, and how is it different from an API gateway?
An LLM gateway is a service in front of model providers that centralises keys, routing and fallbacks. MLflow's gateway page describes one interface to many providers, central application programming interface (API) key management, and traffic routing with fallbacks (MLflow AI Gateway overview). Features such as limits or caching differ by product, so name the feature you need and check the vendor's documentation.
Why it is asked: generative platforms add this layer, and interviewers want your design reasons. Read the full explanation: MLflow AI Gateway overview.
How would you design fallbacks and rate limits for an LLM gateway?
List ordered backups: MLflow documents that fallback models give automatic recovery on errors or rate limits, and the gateway tries them sequentially until one succeeds (MLflow AI Gateway docs). Illustrative: if three providers each fail one request in five, independently, the chain fails 0.8% of the time against 20% for one.1 Real failures correlate, so cap retries and total latency.
Why it is asked: it tests reliability reasoning with numbers. Read the full explanation: MLflow AI Gateway traffic routing.
Follow-up questions
What are common ML platform engineer interview questions?
The sixteen above cover the recurring areas: what the platform automates, pipelines, registries and releases, features, governance, monitoring and gateways. Design prompts are often part of the loop, and a coding round may follow. Practise that part with the coding interview guide, and test your pipeline code the way the pytest questions describe.
Are data platform engineer interview questions the same?
They overlap on ingestion, storage, schemas, ownership and governance, but a data platform role weights these more and models less. No public source here defines either role's format, so read the job description and prepare the layers it names. For the design side, see the solution architect questions.
What are AI platform engineer interview questions?
They usually add generative topics to the list above: gateways, routing and fallbacks, usage tracking, evaluation and serving cost. The gateway entries cover the part this page can source. Be ready to say where a vendor's claim ends and your own measurement begins.
Do Google Cloud Platform data engineer interview questions differ?
A cloud-specific role adds that provider's services on top of the concepts here. This page does not cover any provider's service catalogue, so use the provider's documentation for those, and use the concepts above to justify design choices in any cloud.
How do I practise design-style platform questions?
Pick one entry, say the answer in under a minute, then add one trade-off and one failure mode. Draw the release path from training to monitoring from memory. For neighbouring skills, see the full stack developer questions and the quality assurance (QA) interview questions for testing habits.
- An ML platform automates the path from training to deployment and monitoring, not just notebooks.
- ML debt lives at the system and data level, and CI also tests data, schemas and models.
- A registry adds lineage and aliases, so promotion is an alias change and rollback is another.
- A feature store shares one definition between training and serving; point-in-time joins stop leakage.
- An LLM gateway centralises keys, routing and fallbacks; check vendor claims against your needs.
Sources
- Hidden Technical Debt in Machine Learning Systems (Sculley et al., NIPS 2015) — NeurIPS Proceedings, 7 Dec 2015
- MLOps: Continuous delivery and automation pipelines in machine learning — Google Cloud Architecture Center, 28 Aug 2024
- MLflow Model Registry (current documentation) — MLflow project, 26 Oct 2026
- Kubeflow Pipelines: Overview — Kubeflow Pipelines documentation, 26 Oct 2026
- Feast joins the PyTorch ecosystem — PyTorch Foundation blog, 23 Jan 2026
- MLflow AI Gateway: Traffic Routing and Fallbacks — MLflow project, 26 Oct 2026
- MLflow AI Gateway overview — MLflow project, 26 Oct 2026
