How to find an MLOps engineer.

MLOps sits at the intersection of three established disciplines and has existed as a job title for only a few years. That means there is no standard background, and every candidate arrived from somewhere else: infrastructure, data engineering, or machine learning.

The origin determines the gaps. Platform people keep systems reliable without noticing a model has silently degraded. ML people understand model behaviour but struggle with production reliability and cost. Data people know that most production ML failures are actually data failures — which is the most useful instinct of the three, and the least often sought.

Job titles worth searching

Grouped by what the person actually does, because searching all40 at once produces a result set you cannot triage. Decide which group you need first — that decision does more for the search than any string below.

Where MLOps engineers actually are

The production ML toolchain is open source, which makes GitHub unusually informative here. Kubeflow, MLflow, Seldon, BentoML, KServe, and Ray Serve exist specifically to run models in production, and someone contributing to or configuring them is demonstrating the exact capability the role requires rather than claiming it.

Vocabulary is a reliable filter for this role. Engineers discussing drift detection, training-serving skew, or point-in-time correctness have operated models after deployment rather than only shipping them. Those discussing token throughput and inference cost are working with LLMs in production rather than calling an API.

The conference circuit is small and practitioner-led — MLOps World, Ray Summit, and MLSys attract people running real systems rather than describing reference architectures. Writing about production failures is the other strong signal: post-mortems about latency, drift, or runaway cost reveal operational judgement that no architecture diagram conveys.

Boolean search strings

Written to be pasted as-is. Each one is built around an intent rather than a platform, since the useful question is what you are trying to find, not which site you happen to be on.

site:linkedin.com/in/ ("MLOps" OR "ML platform" OR "ML infrastructure") (Kubeflow OR MLflow OR Kubernetes OR "feature store") "{city}"

site:github.com ("kubeflow" OR "mlflow" OR "seldon" OR "bentoml" OR "ray serve" OR "kserve") -awesome -tutorial

("model drift" OR "data drift" OR "model monitoring" OR "evidently" OR "whylabs") ("production" OR "detected") -jobs -vendor

("feature store" OR "feast" OR "tecton" OR "feature pipeline") ("training serving skew" OR "point in time") -jobs -vendor

("LLMOps" OR "prompt versioning" OR "eval harness" OR "inference cost" OR "vLLM" OR "token throughput") -jobs -course

("GPU cluster" OR "distributed training" OR "NCCL" OR "slurm" OR "multi-node") ("infrastructure" OR "platform") -jobs -course

("speaker" OR "talk") ("MLOps World" OR "Ray Summit" OR "KubeCon" OR "MLSys") 2024..2026 -jobs

("in production" OR "post-mortem" OR "what went wrong") ("machine learning" OR "model") ("latency" OR "drift" OR "cost") -course

Mistakes that cost the most time

1. Not asking which discipline they came from

   Almost nobody trained into MLOps directly, so every candidate arrived from platform engineering, data engineering, or machine learning. That origin determines their strengths and gaps: platform people know reliability but not model behaviour, ML people know models but not infrastructure, data people know pipelines but perhaps neither. Establish the origin and match it to what the team lacks.

2. Treating it as DevOps with a different label

   ML systems fail differently from conventional software. They degrade silently as data distributions shift, produce plausible wrong answers rather than errors, and depend on training-serving consistency that has no analogue in normal deployment. A strong DevOps engineer without ML understanding will keep the service up while the model quietly becomes useless.

3. Underestimating that most failures are data failures

   Production ML breaks because of upstream schema changes, distribution shift, and training-serving skew far more often than because of model architecture. This makes data engineering background unusually valuable in MLOps roles, and it means monitoring data quality matters more than monitoring model metrics alone.

4. Ignoring cost as a core competency

   GPU inference and training are expensive enough that cost engineering is part of the job rather than an afterthought. Engineers who understand batching, quantisation, autoscaling, and when to use smaller models are meaningfully more valuable, particularly as organisations move from pilots to production scale.

5. Assuming classical MLOps covers LLM operations

   LLMOps emerged rapidly and involves different concerns — prompt versioning, evaluation harnesses, token cost, and inference throughput rather than retraining pipelines and feature stores. The skills overlap partially, and a classical MLOps engineer needs genuine ramp time for LLM-specific production work.

6. Requiring every tool in the ecosystem

   The MLOps tooling landscape is large and turns over quickly, and adverts listing a dozen platforms attract people who have touched each briefly. What transfers is understanding the problems these tools solve — reproducibility, lineage, monitoring, serving — since a competent engineer learns a new orchestrator quickly.

Common questions

What job titles should I search for when hiring an MLOps engineer?

Search the adjacent disciplines as well as the title, because almost nobody trained into MLOps directly. Core terms include MLOps Engineer, ML Platform Engineer, and ML Infrastructure Engineer. Then search by origin: Platform Engineer and SRE for infrastructure-strong candidates, Data Engineer and Data Platform Engineer for pipeline-strong ones, and Machine Learning Engineer for model-strong ones. Emerging specialisations use LLMOps Engineer, Feature Store Engineer, and Model Monitoring Engineer.

What is the difference between MLOps and DevOps?

The failure modes. Conventional software fails visibly — it errors, crashes, or returns wrong results detectably. Machine learning systems degrade silently as the data they encounter drifts away from what they were trained on, continuing to return confident but increasingly wrong answers. They also depend on consistency between training and serving data that has no analogue in normal deployment. A strong DevOps engineer without ML understanding will keep the service running reliably while the model quietly becomes useless, which is why domain understanding matters here.

What background produces the best MLOps engineers?

It depends on what the team already has, which is why establishing the candidate's origin matters. Platform and DevOps backgrounds bring reliability, Kubernetes, and CI/CD strength but often lack understanding of model behaviour. Data engineering backgrounds bring pipeline and data quality expertise, which is arguably the most valuable since most production ML failures are data failures rather than model failures. ML backgrounds bring understanding of what to monitor and why models degrade, but usually less infrastructure depth. The best hire fills the gap the existing team has.

Does classical MLOps experience cover LLM operations?

Only partially. Classical MLOps centres on retraining pipelines, feature stores, and model versioning for models an organisation trains itself. LLM operations centres on different concerns: prompt and version management, evaluation harnesses for outputs that have no single correct answer, inference cost and token throughput, and latency under load for models that are expensive to run. The infrastructure instincts transfer, but the specific problems differ enough that a classical MLOps engineer needs genuine ramp time for LLM production work.

Where can I find MLOps engineers outside LinkedIn?

GitHub is the strongest source, because production ML tooling is largely open source — Kubeflow, MLflow, Seldon, BentoML, KServe, and Ray Serve all exist specifically for this work, and configuring or contributing to them demonstrates exactly the required capability. The conference circuit is small and practitioner-led: MLOps World, Ray Summit, and MLSys attract people operating real systems. Engineers who write about production ML failures — drift, latency, cost — reveal operational judgement that architecture descriptions do not.