MLOps Engineer interview questions

MLOps is the discipline of reliably building, deploying, and operating machine learning systems.

• It combines machine learning practices with software engineering and operations.
• It turns experiments into repeatable pipelines and deployable model artifacts.
• It adds versioning, automation, testing, monitoring, and ownership across the model lifecycle.

The ML lifecycle moves from defining a problem and preparing data to training, deployment, and ongoing operation.

• Data is collected, validated, transformed, and split for training and evaluation.
• Candidate models are trained, evaluated against acceptance criteria, and packaged.
• An approved model is deployed for batch or online inference.
• Production performance and data are monitored to decide when investigation or retraining is needed.

MLOps applies DevOps principles while accounting for data, experiments, and models as additional changing parts.

• DevOps usually centers on source code, application builds, releases, and infrastructure.
• MLOps must also version datasets, features, parameters, metrics, and model artifacts.
• ML behavior depends on both code and data, so tests must cover data quality and model quality.
• MLOps often includes continuous training in addition to continuous integration and delivery.

Source code alone cannot identify an ML result because data, configuration, dependencies, and training inputs also affect it.

• The same code can produce a different model when the dataset or feature definitions change.
• Hyperparameters and random seeds can alter training outcomes without a code change.
• Library and runtime versions can change preprocessing or numerical behavior.
• A reproducible model version should link all of these inputs to its output artifact.

Continuous integration for ML automatically validates each proposed change before it is merged.

• It runs code checks such as formatting, unit tests, and integration tests.
• It can validate schemas, missing values, ranges, and other data contracts.
• It may execute a small training test to confirm that the pipeline completes and produces expected outputs.
• It gives the team fast feedback without requiring a full production training run.

Continuous delivery prepares a validated model release so it can be deployed through a controlled, repeatable process.

• The pipeline packages the model with the required serving code and dependencies.
• Automated checks confirm model quality, compatibility, and required metadata.
• An approved artifact is promoted between environments rather than rebuilt differently each time.
• Production release may remain a manual approval even when every preceding step is automated.

Continuous training is an automated process that retrains and evaluates a model when a defined trigger occurs.

• A trigger can be a schedule, newly available labeled data, or a monitored quality signal.
• The pipeline repeats data preparation, training, evaluation, and model registration.
• A new candidate must pass acceptance checks before it can replace the current model.
• Continuous training creates candidates automatically but does not require automatic production promotion.

CI validates changes, CT produces qualified model candidates, and CD packages and promotes approved releases.

• CI protects the shared codebase and pipeline definitions before changes are merged.
• CT reruns the training workflow against a defined data and configuration version.
• CD moves the exact validated artifact through staging and production controls.
• Together they provide traceability from a change or data trigger to a deployed model version.

Source control should contain the text-based definitions needed to review and rebuild the ML workflow.

• Store training, evaluation, preprocessing, and serving code.
• Store pipeline definitions, tests, environment manifests, and small configuration files.
• Store schema definitions and references or manifests that identify external datasets and artifacts.
• Keep large datasets, model binaries, credentials, and generated outputs in dedicated systems rather than Git.

Versioned configuration makes changes to training behavior explicit without hiding them inside source code.

• Configurations can record hyperparameters, feature selections, data locations, and resource settings.
• A run should retain the resolved values actually used, including defaults and overrides.
• Reviewing configuration diffs makes experimental changes easier to understand.
• Linking a configuration version to each run helps recreate and compare results.

Reproducibility means being able to rerun a recorded process under the same defined conditions and obtain a consistent result.

• The run must identify code, data, configuration, dependencies, and execution environment.
• Random seeds and deterministic options should be recorded where the framework supports them.
• The resulting metrics may match within an accepted tolerance rather than bit for bit.
• Reproducibility supports verification, comparison, auditing, and reliable model updates.

A random seed controls some randomness but cannot by itself make every part of training deterministic.

• Data loader workers and parallel execution can consume random operations in different orders.
• Some GPU kernels and numerical libraries use nondeterministic algorithms.
• Hardware, drivers, and library versions can change floating-point results.
• Reproducibility also requires pinned inputs, environment details, and deterministic settings where available.

Experiment tracking records the inputs, outputs, and context of model development runs in a searchable system.

• Inputs include code revision, dataset version, parameters, and environment information.
• Outputs include metrics, plots, logs, checkpoints, and final model artifacts.
• Runs can be grouped and compared to understand which changes affected results.
• Tools such as MLflow and Weights & Biases provide tracking interfaces and APIs.

MLflow Tracking organizes related work into experiments whose individual executions are runs.

• Parameters are input settings such as learning rate or batch size and are normally fixed for a run.
• Metrics are numeric results such as loss or accuracy and may be logged repeatedly over steps.
• Artifacts are output files such as plots, reports, checkpoints, and serialized models.
• Each run receives an identifier that links these records and its execution metadata.

Weights & Biases is used to track, compare, and visualize machine learning experiments and related artifacts.

• Its SDK logs parameters, metrics, system measurements, tables, and media from training code.
• Dashboards help compare runs and inspect learning curves or resource use.
• Artifacts can version datasets and models while recording links between them.
• Shared projects and reports make experiment results visible to the team.

A training run should log enough information to compare the result and trace how it was produced.

• Record the code revision, dataset version, feature or preprocessing version, and resolved configuration.
• Record hyperparameters, random seeds, dependency versions, hardware, and runtime details.
• Record training and validation metrics over time, plus final evaluation metrics.
• Save relevant logs, plots, checkpoints, and the final model artifact with a run identifier.

A model registry is a catalog that versions trained models and manages information needed for their controlled use.

• It links each model version to its artifact, source run, metrics, and metadata.
• Teams can record validation status, ownership, intended use, and deployment references.
• Aliases or stages can identify versions approved for testing or production.
• Registries such as MLflow Model Registry separate model promotion from model training.

An alias or stage gives deployment systems a controlled logical reference to an approved model version.

• A name such as champion or production can point to one immutable version at a time.
• Promotion changes the reference without editing and rebuilding serving code.
• The registry records which version held the reference and when it changed.
• Rollback can repoint the alias to a previously approved version.

Metadata is structured information that describes ML assets, executions, and the relationships among them.

• Run metadata can include timestamps, owner, code revision, parameters, and environment.
• Dataset and model metadata can include versions, schemas, evaluation results, and intended use.
• Relationships form lineage from source data through a training run to a registered model and deployment.
• Metadata makes assets searchable, comparable, auditable, and reproducible.

Artifact management stores, versions, and retrieves files produced or consumed by ML workflows.

• Artifacts can include datasets, feature snapshots, checkpoints, models, evaluation reports, and plots.
• Large files usually live in object storage while tracking systems keep their identifiers and metadata.
• Immutable versions and checksums help prove that a retrieved artifact is the expected one.
• Access controls, retention rules, and links to runs support secure and traceable reuse.