In 2015, a group of Google engineers published a paper with a diagram that every ML team should tape to the wall. A tiny black box in the middle is the model code. Around it sit big boxes for data collection, feature extraction, serving, monitoring, and configuration. The caption reads: "Only a small fraction of real-world ML systems is composed of the ML code" (Sculley et al., NIPS 2015). An MLOps engineer owns those big boxes. If your data scientists keep producing models that never reach production, or reach it and quietly degrade, that's the hire you are missing.
Key Takeaways
- MLOps engineers build the pipelines that train, deploy, and monitor models. Data scientists build the models.
- Use Google's three maturity levels to scope the role and to test candidates.
- Screen for software engineering and infrastructure depth first, ML knowledge second.
- Hire one when you have models in production, or models stuck just short of it.
What the Role Actually Is
Google Cloud defines MLOps as "an ML engineering culture and practice that aims at unifying ML system development (Dev) and ML system operation (Ops)" (Google Cloud). The same guide describes three maturity levels, and they are the most useful hiring tool I know for this role:
| Level | What it looks like | What you need |
|---|---|---|
| 0: Manual | "Every step is manual," from data prep to training to validation | Someone to automate the first pipeline |
| 1: Pipeline automation | Training is automated, so models retrain continuously on new data | Someone to add testing, monitoring, and a feature store if needed |
| 2: CI/CD automation | New pipeline code is tested and deployed automatically | Someone to run and scale a mature platform |
Most startups are at level 0. The engineer who can take you from 0 to 1 is not always the same person who runs a level-2 platform at a large company. Ask candidates which level their last team was at when they joined, which level it reached, and what they built to get there.
The Sculley paper also names the cost of skipping this work: "it is common to incur massive ongoing maintenance costs in real-world ML systems." It even suggests a mature system "might end up being (at most) 5% machine learning code." That hedge is the paper's own. The point stands anyway: most of the work is plumbing.
What to Screen For
Good MLOps engineers are strong software and infrastructure engineers who understand ML well enough to operate it.
Pipelines. Have they built training pipelines with an orchestrator? Can they explain how they version data, code, and models together so a result can be reproduced?
Serving. Batch vs real-time inference, latency budgets, and rolling back a bad model without a code deploy.
Monitoring. Data drift, prediction drift, and the business metric the model is supposed to move. A model can return 200s all day while getting worse.
Infrastructure. Containers, a major cloud, infrastructure as code, and GPU cost control. See how to hire a platform engineer for the overlap.
A strong interview question: "A fraud model's precision dropped 15% over two months, and no code changed. Walk me through it." A good answer starts with the data (a new merchant category, a changed upstream field), moves to monitoring gaps, and ends with an automated retraining and alerting plan.
A Concrete Version
A Series A lending startup has two data scientists and one credit-risk model. Retraining happens when one of them remembers, on a laptop, with a notebook. Deployment means emailing a model file to a backend engineer. That's level 0.
A senior MLOps hire spends the first quarter on three things. First, a scheduled training pipeline that pulls versioned data, trains, evaluates against the current production model, and registers the result. Second, a deployment path where a model only goes live after it beats the incumbent on a held-out set, with one-click rollback and a sign-off step, because in lending a new credit model also needs fair-lending and model-risk review before it touches real applicants. Third, monitoring on input distributions and approval rates, with alerts to the data team.
By the end of the quarter, retraining runs monthly without anyone remembering, and the data scientists spend their time on the next model. That's the move from level 0 to level 1, and it's the right first goal for most startups.
The Honest Counterpoint
Many startups hire an MLOps engineer too early. If you have no model in production and no clear plan for one, you need a machine learning engineer or a data engineer first. An MLOps engineer with nothing to operate will build a platform nobody uses.
Also, if your AI features call hosted LLM APIs instead of training your own models, classic MLOps may be the wrong frame. You need evaluation, prompt versioning, and cost monitoring, which sits closer to AI engineering. Some MLOps engineers have made that shift; test for it specifically.
Frequently Asked Questions
What's the difference between an MLOps engineer and an ML engineer?
ML engineers build and improve models. MLOps engineers build the systems that train, deploy, and monitor those models reliably. In small teams one person often does both, but the skills differ.
What tools should an MLOps engineer know?
Tool names change fast. Look for experience with at least one orchestrator, one model registry, containers, a major cloud, and monitoring. Depth in one stack beats a list of logos.
When should a startup hire its first MLOps engineer?
When a model is in production and retraining or deployment is manual, or when models keep stalling just before production. Before that, hire people who build models and data pipelines.
The Bottom Line
Hire MLOps engineers to own the big boxes around the model: pipelines, deployment, and monitoring. Scope the role with Google's maturity levels and test candidates on real drift and deployment scenarios. For senior engineers who have built this in production, see senior AI engineers in LATAM or see available engineers.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
