How to find a machine learning engineer.

The costliest mistake in ML hiring happens before anyone is sourced. A team writes a job description that reads like research, hires someone who publishes well, and then needs them to keep an inference service up at reasonable cost. Both parties did their jobs. Neither wanted the arrangement.

A second problem arrived more recently. Generative AI produced a large population titling themselves AI or LLM engineers, whose actual work ranges from calling a hosted API to training foundation models. The title spans the entire range, so it cannot be used to filter — but the public artefacts can, which is what makes this role unusually searchable if you know what to look for.

Job titles worth searching

Grouped by what the person actually does, because searching all46 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 ML engineers actually are

GitHub answers the question titles cannot. Repositories touching Kubeflow, MLflow, Ray Serve, Triton, or vLLM indicate someone who has served models under real load, while notebook-only histories indicate the modelling end. That single distinction resolves most production-role mismatches before the first conversation, and almost nobody searches for it.

Hugging Face is the underused equivalent for applied work. Published models, fine-tunes, and datasets carry download counts, which is public evidence of work other people found useful. For research roles, arXiv and Papers with Code index by area with affiliations attached, and recency matters more here than in any other field — a publication record from four years ago may predate the architectures the role depends on.

The conference circuit splits usefully. Acceptances at NeurIPS, ICML, ICLR, CVPR, and ACL signal genuine research standing and are highly competitive. Workshop tracks are a broader net that catches applied practitioners who publish occasionally without pursuing full papers — often exactly the people who can bridge research and production.

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/ ("machine learning engineer" OR "ML engineer" OR "AI engineer") ("PyTorch" OR "LLM" OR "MLOps") "{city}"

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

site:arxiv.org ("{research area}") ("we propose" OR "state of the art") 2024..2026

site:huggingface.co ("models" OR "datasets" OR "spaces") "{technique}" -tutorial

("fine-tuning" OR "LoRA" OR "quantization" OR "distillation" OR "eval harness") ("production" OR "latency" OR "throughput") -course -tutorial

(site:kaggle.com OR site:paperswithcode.com) ("competition" OR "leaderboard" OR "benchmark") "{domain}"

("accepted" OR "poster" OR "workshop") ("NeurIPS" OR "ICML" OR "ICLR" OR "CVPR" OR "ACL") 2024..2026 -jobs

("how we" OR "lessons from" OR "in production") ("machine learning" OR "LLM" OR "model serving") ("scale" OR "cost" OR "latency") -course

Mistakes that cost the most time

1. Not separating research from production

   This is the costliest mis-hire in the field. Research roles reward novel methods, publication, and comfort with uncertainty; production roles reward reliability, latency, cost control, and software engineering discipline. A strong researcher placed on a serving infrastructure team will be unhappy and underperform, and the reverse fails just as reliably. Establish which the role is before sourcing.

2. Taking 'AI engineer' at face value

   The generative AI wave produced a large population using this title, with wildly varying underlying skill. Calling a hosted model API and building a retrieval pipeline is real work, but it is not the same as training, fine-tuning, or serving models under load. Ask what happens below the API layer — the answer separates the crowded end of this market from the scarce one.

3. Requiring a PhD reflexively

   A PhD is genuinely necessary for research roles working on novel methods. For the large majority of ML engineering work — pipelines, serving, evaluation, integration — it is not, and requiring it removes many of the strongest production engineers while attracting researchers who will find the work unsatisfying.

4. Advertising a data engineering role as ML

   A great many advertised ML engineering roles involve a first year of building reliable data pipelines, because the feature infrastructure does not exist yet. Candidates hired expecting modelling work discover this quickly and leave. If the pipelines are not there, the honest advert is for a data or platform engineer, and it will attract someone who actually wants that job.

5. Screening on framework names

   PyTorch versus TensorFlow is a weekend of adjustment for a competent engineer, and the tooling in this field turns over fast enough that today's requirement is next year's legacy. Screening on named frameworks selects for CV keyword matching rather than ability. What discriminates is whether someone has solved a comparable class of problem end to end.

6. Ignoring how quickly experience dates

   Few fields move this fast. A publication record or production experience from four years ago may predate the architectures and tooling the role depends on. This cuts both ways — it means recent hands-on work matters more than seniority, and it means genuinely current practitioners are worth moving quickly for.

Common questions

What job titles should I search for when hiring a machine learning engineer?

Search by what the role actually does, since the core titles hide the important distinction. For production work, look for MLOps Engineer, ML Platform Engineer, ML Infrastructure Engineer, and Inference Engineer — these people ship and operate systems. For research, Research Scientist, Research Engineer, and Applied Scientist. For generative AI work, LLM Engineer, GenAI Engineer, RAG Engineer, and Applied AI Engineer, though title inflation is severe in this group. Domain specialisations such as Computer Vision Engineer and NLP Engineer are more discriminating still where the role needs that depth.

What is the difference between an ML engineer, a data scientist, and an MLOps engineer?

A data scientist analyses data and builds models to answer questions, often working in notebooks and handing results to others. An ML engineer takes models and makes them work as software — integrating, serving, and maintaining them in production. An MLOps engineer builds and operates the platform that makes this repeatable: pipelines, deployment, monitoring, and retraining infrastructure. The boundaries blur by company size, and at a small organisation one person may do all three, but confusing them when hiring produces candidates who cannot do the actual job.

How do I tell a genuine LLM engineer from someone who calls an API?

Ask what happens below the API layer. Building a retrieval pipeline against a hosted model is legitimate and useful work, but it is a different skill from fine-tuning, quantisation, evaluation harness design, or serving models under latency and cost constraints. Practitioners with real depth will discuss trade-offs — throughput against cost, quantisation against quality, evaluation methodology — because those are the daily problems. Public artefacts help here: published fine-tunes on Hugging Face, contributions to serving frameworks, or writing about production deployment all evidence work the crowded end of this market has not done.

Does a machine learning engineer need a PhD?

For genuine research roles developing novel methods, usually yes — the work requires reading and extending current literature. For the majority of ML engineering, which involves pipelines, deployment, serving, evaluation, and integration, no. Requiring a PhD by default removes many of the strongest production engineers, who came through software engineering routes, while attracting researchers who will find infrastructure work unsatisfying and leave. The useful question is whether the role advances the state of the art or applies it well.

Where can I find machine learning engineers outside LinkedIn?

The public artefacts in this field are unusually informative about which kind of ML engineer someone is. GitHub reveals production experience through serving and orchestration tooling such as Kubeflow, MLflow, Ray Serve, Triton, and vLLM. Hugging Face profiles show published models, fine-tunes, and datasets with download counts. arXiv and Papers with Code identify researchers by area with author affiliations. Conference acceptances at NeurIPS, ICML, ICLR, CVPR, and ACL signal research standing, and workshop participation catches applied practitioners who publish without pursuing full papers.