ML Engineer Job Description Template 2026

ML Engineer Job Description Template 2026

Last updated: May 1, 2026

A machine learning engineer designs, trains, and deploys ML systems in production, with U.S. base salaries running $145,000 to $190,000 for mid-level and $200,000 to $275,000 for senior roles in 2026, plus a 15 to 25 percent premium for LLM and domain-specialist hires. Below is a ready-to-adapt job description, a salary table sourced from five independent benchmarks, and the specific JD mistakes that screen out the strongest ML candidates before the first interview.

Tom Kenaley here, KORE1 senior recruiter. I run a fair share of the AI and ML searches that come through our practice, and the gap between a JD that closes in five weeks and one that runs ninety days almost always shows up in the first paragraph. The hiring manager wrote a posting for “machine learning engineer” the way they would have in 2022, and the candidates who actually fit the work in 2026 read it, file it under generic, and move on without applying.

Two patterns. The first is treating ML engineer as one job. It isn’t. The work, the comp, and the candidate pool split four ways now, and a JD that doesn’t commit to a lane attracts everybody and excites nobody. The second is the salary ranges. Posted bands lag the actual market by twelve to eighteen months, particularly for LLM-adjacent work, where the market reset twice in the last three years.

One disclosure up front. KORE1 places ML engineers across our AI/ML engineer staffing practice, and we collect a fee when a hire goes through us. The framework below is the same one we use internally on intake calls, whether you call us or not.

What Does a Machine Learning Engineer Actually Do?

An ML engineer takes models from “this works on a notebook” to “this serves traffic at scale and doesn’t break when the data drifts.” That sentence covers more ground than most JDs admit. Data pipeline work. Feature engineering. Model training and evaluation. Deployment to a serving layer. Monitoring for drift, performance regressions, and the failure modes that only show up at production traffic levels. The MLOps stack underneath all of it.

The role lives at the intersection of three disciplines that used to be separate jobs. Software engineering for the systems part. Applied statistics or applied math for the modeling part. Data engineering for the pipeline part. A strong ML engineer is at least solid at all three. Most candidates are stronger in one and weaker in another. Pretending the role only requires one of them is how you end up with a hire who can’t ship. Common pattern.

Three things shape what the role actually looks like inside a given company:

• Whether the work is mostly building new models, mostly improving existing ones, or mostly keeping production systems alive
• Whether the company has a separate platform team, an MLOps function, or expects the ML engineer to own infrastructure end-to-end
• What the deployment target is. Batch jobs feeding a dashboard, real-time inference behind an API, on-device, or LLM application backends are four different jobs sharing one title

Most JDs leave all three ambiguous. Senior candidates read between the lines anyway. They’ve been burned before — usually by a posting that listed PyTorch and Spark in the same sentence and then turned out to be a Snowflake-and-dashboards role with one feature flag for “applies a model” buried at the bottom of a Jira backlog. So they treat the cues as signal now. Vague usually means skip.

The Four ML Hiring Lanes Most JDs Conflate

“Machine learning engineer” used to mean one thing. In 2026, it covers four lanes, each with a different talent pool, a different comp band, and a different intake conversation. A posting that doesn’t pick a lane gets the worst of all four pools. Predictable result.

Applied ML / Production engineer. The largest pool. Lives in PyTorch or TensorFlow, comfortable with feature stores, model registries, and deployment to SageMaker, Vertex AI, or a custom inference layer. Owns the path from a trained model to a serving endpoint that meets a latency budget. Comp band $145K to $190K mid-level, $200K to $260K senior in most U.S. metros. Sourcing is straightforward in tech-heavy markets. Most net-new ML hires in 2026 should be in this lane, but most JDs describe a lane-3 LLM engineer and budget for a lane-1 applied engineer.

Research / modeling engineer. Smaller pool. Master’s or PhD in stats, CS, applied math, or a quant-heavy science. The work skews toward novel modeling, evaluation methodology, and the experiments that decide whether the next model architecture is worth the compute spend. Less production responsibility, more whiteboard time. The candidates who fit this lane often don’t want lane-1 work and will not stay if you hand them a deployment ticket queue. Comp tracks parallel to applied at mid-level and pulls ahead at senior, where research-track engineers in the right shop clear $230K to $300K base.

LLM and GenAI engineer. Newest lane. Genuinely thin supply. Strong on prompt engineering as a discipline, RAG architecture, evaluation harnesses for hallucination and refusal, fine-tuning workflows on Llama or Mistral, and the cost-vs-quality tradeoffs across foundation model providers. The candidates who can do this work end-to-end and have actually shipped something to customers, rather than built a side-project chatbot, are scarce. Comp runs 15 to 25 percent above applied ML. Senior LLM engineers in major metros clear $260K to $340K base, with total comp into the $500K range at well-funded shops. Read the full breakdown of LLM engineer vs. ML engineer if you’re trying to decide which one you actually need.

Domain-specialist ML engineer. The lane almost no JD names. Healthcare, oncology, fraud, claims, manufacturing process control, climate modeling. The work requires the ML toolkit plus enough domain fluency to know which features matter, what label noise looks like in this field, and which performance metrics actually map to value. The talent pool is small to begin with, and the overlap of “real ML production experience” and “real domain experience” inside the same person is what creates the scarcity. We covered this in the 2026 AI/ML talent map in more detail.

The collision pattern. A growth-stage Series B company in Austin or San Diego posts “Senior ML Engineer” hoping to attract LLM talent, with a comp band of $190K to $230K base and equity, which lands well within applied ML range and well below the LLM market in the same metro. The applicants who clear screen are mostly applied production engineers, because that’s the largest pool and the JD reads close enough to their work. The LLM candidates pass, since the JD doesn’t mention a single GenAI signal. Six weeks of interviews later, the company hires a competent applied engineer and assigns them LLM work. Six months later, the engineer is unhappy and looking, and the LLM project hasn’t shipped. Two hires lost to one ambiguous JD.

Machine Learning Engineer Job Description Template

This template is structured for a mid-level to senior applied ML engineer role with production responsibility. Adapt the framework language and comp band for the lane you’re actually hiring. The annotations in brackets are decisions the intake conversation should resolve before the post goes live.

Core Responsibilities, in Plain English

The bullet list is the cover sheet. The interview is where the gap between the JD and the actual work shows up.

Production model serving is the part candidates either over-claim or under-claim. A senior applied candidate will walk you through a real deployment. Latency budget — maybe under 80ms p99 at 5,000 rps on a recommendation model behind a checkout flow. Why they ended up at real-time instead of batch, or vice versa. What they’d build differently now. Weaker ones describe a Jupyter notebook they handed off to a platform team. The interview question is not “explain SageMaker.” It is “the last time a model you owned hit a production problem, what was the problem, how did you find out, and what did you do about it.” Most senior ML engineers have a real answer. The ones who don’t are usually researchers in production engineer titles.

Feature stores and training pipelines sound like a checkbox skill until you ask how the candidate handles training-serving skew. The strongest engineers know it’s the source of more silent ML failures than any other category and can describe a specific time they caught one. The weaker ones describe their feature pipeline at a high level and skip the part where the offline features and the online features drift apart over time. The candidate who has been burned by training-serving skew once will design their next system to prevent it. The candidate who hasn’t, won’t. Painful lesson.

Evaluation discipline is where applied ML and research ML diverge most clearly. Applied engineers care about whether the model is good enough to ship and whether the metrics that drive product value are improving. Research engineers care about whether the experiment design is sound and whether the gain is real or noise. Both perspectives matter. A strong applied ML engineer can articulate why a 1.5 percent AUC improvement is or isn’t worth the deployment cost, and what additional evaluation would settle the question. The candidate who answers “we’d run an A/B test” without describing the experiment design is reading the playbook back to you. Easy filter.

MLOps is where the JD says “experience with MLflow” and the actual work is debugging why the model in staging produces different outputs than the model in production six weeks after launch. Production ML systems decay. The decay shows up as data drift, label drift, infrastructure drift, dependency drift, and the slow pile-up of small assumptions that were correct at training time and aren’t anymore. The candidate who has lived through a model decay incident in production, ran the postmortem, and changed something durable as a result is worth the premium. The candidate who has only worked on net-new model launches has not yet seen the part of the job that takes the most time. Net-new is glamorous. Decay work is roughly half to two-thirds of the total engineering hours a model consumes from launch to eventual deprecation, and almost none of it shows up on a resume.

ML Engineer Salary in 2026

ML engineer compensation has the widest spread of any role we track in IT. The 75th percentile at a top-tier AI lab can be more than double the 50th percentile at a mid-market enterprise. Five sources, real variance, methodology called out for each.

The variance is the content. A 60K spread between Salary.com and Glassdoor on the same role is normal. The Levels.fyi data is real but not representative of where most U.S. companies hire. Posting your range against Levels.fyi means competing with OpenAI for a budget you don’t have, while posting against BLS means losing every senior candidate to the next recruiter who calls them with a serious offer that lands inside the actual market band for the work the candidate already does. Aim for the middle of where your peer companies are paying, not the extremes.

By lane, the 2026 numbers we actually see at offer stage:

• Applied ML / production engineers run ten to fifteen percent above the BLS median, with senior offers landing $200K to $260K base in major U.S. metros
• Research-track ML engineers in well-funded labs add another fifteen percent on top of applied bands at senior level, and significantly more at staff and principal
• LLM and GenAI specialists clear $260K to $340K base for senior, with total comp into the $500K range at frontier labs and well-funded GenAI startups
• Domain-specialist hires (healthcare ML, oncology, fraud, claims) trend slightly above applied bands when the domain experience is verifiable, and significantly above when the domain is in genuinely short supply

For a current breakdown by metro, lane, and total compensation, see the KORE1 machine learning engineer salary guide. If MLOps is the actual specialty you’re hiring for, the MLOps engineer salary guide covers that lane in more detail.

What Most ML Engineer JDs Get Wrong

Specific patterns we see week after week in postings that then run ninety days without a hire.

Treating ML engineer as one role. The JD lists PyTorch, TensorFlow, scikit-learn, Spark, RAG, fine-tuning, MLOps, evaluation, statistical modeling, and a PhD preferred. Translation to a candidate: you don’t know which lane you’re hiring, or you do and the role is going to be a context-switching mess. Strong candidates from any one lane skip it. The applicants who clear are generalists at every layer and specialists at none.

Asking for a PhD on an applied production role. Real applied ML production work in 2026 rarely requires a PhD. The strongest applied engineers are often master’s holders or self-taught with a heavy software engineering background. Listing PhD as a hard requirement on a role that’s actually 70 percent systems work, 30 percent modeling, screens out the candidates you actually want and attracts research-track engineers who will leave inside a year when they realize the work is deployment tickets, not novel modeling.

Listing every framework and tool ever mentioned in an AI conference talk. “PyTorch, TensorFlow, JAX, scikit-learn, XGBoost, LightGBM, Hugging Face, LangChain, LlamaIndex, Vector DB experience, RAG, fine-tuning, RLHF, DPO, MLflow, Kubeflow, SageMaker, Vertex AI, Spark, Airflow, Dagster, dbt, Snowflake, BigQuery, Databricks.” No engineer has used all of those in production at depth. The ones who claim to have are the ones you do not want. The right list is four to six tools the role actually uses, plus “experience with comparable tooling” for the rest.

No mention of model serving infrastructure. If the role includes production deployment, the JD has to name the serving stack or at least the deployment target. Senior applied ML engineers ask about it in the first conversation. Hiding it loses candidates at the offer stage when they discover the company has no serving infrastructure and expects them to build it from zero on top of a managed service that wasn’t designed for the workload.

Conflating ML engineer with data scientist. Two different roles. Different output, different evaluation criteria, different daily work. A data scientist is closer to the analyst end of the spectrum, building models that inform decisions and writing reports. An ML engineer ships systems. JDs that blur the line attract applicants from both pools and disappoint everybody once the actual work starts. The data scientist hiring guide covers that side of the spectrum if that’s what you actually need.

Vague seniority paired with a specific years-of-experience requirement. “Senior Machine Learning Engineer, 3+ years required.” Or “Machine Learning Engineer, 8+ years required.” The internal calibration is off. So is the comp band. Strong ML engineers read both numbers and the responsibility list, decide one of the three is wrong, and either skip the posting or apply with mismatched expectations that surface again at the offer stage when the title and the salary stop lining up. Mid-level and senior in this market are different jobs, not the same job with two more years on it.

No mention of the data, the product, or the user. The strongest senior ML candidates want to know what they would be modeling. “We use machine learning to improve customer experiences” appears in roughly half the JDs we see and tells the candidate exactly nothing. What’s the data? What’s the prediction target? Who uses the output? An ML engineer who chooses your role over the next one usually does so because the problem space is interesting. A JD that hides the problem gets generic candidate flow.

How Many Years of Experience Do You Actually Need?

The years-of-experience requirement is one of the most miscalibrated parts of ML engineer postings. A rough framework that holds up across most of our searches:

• Junior ML engineer: 1–3 years total experience, often coming from a software engineering background with self-driven ML coursework or a recent grad with strong project portfolio. Comfortable with PyTorch or scikit-learn at a working level. Can train and evaluate a model with supervision but not yet design a production pipeline from scratch.
• Mid-level ML engineer: 3–6 years total, with at least 2 years specifically owning production ML systems. Can take a model from notebook to serving endpoint without hand-holding, debug a training-serving skew incident, and pick up a new framework without losing a sprint to ramp.
• Senior ML engineer: 6–10 years total, 4+ years specifically in ML production work. Has owned a meaningful model launch end-to-end, run incident response on a production ML failure, and mentored mid-level engineers through model decay or a serving migration.
• Staff or principal: 10+ years with ML as a core part of the last 5+. Sets the ML platform direction across multiple teams. Often has a specialty: serving infrastructure, evaluation methodology, LLM systems, or a domain area.

Most JDs ask for a year or two more than the role actually needs and lose strong candidates who are exactly right for the work. Three years of focused production ML experience is often more useful than six years of intermittent modeling work in a research context. The on-call test is the cleanest version of this. Has the candidate been paged at 2 a.m. because a model started returning predictions that nobody could explain, and then walked the team through the fix, the rollback, and the postmortem? If yes, they are senior. If no, they are not yet, regardless of years on the resume. Focus beats tenure.

The Domain-Overlap Problem Most JDs Ignore

Almost nobody writes about this part. It’s the part we get the most calls on right now.

The scarcity in ML hiring in 2026 is rarely “ML talent” in the abstract. It’s the overlap of ML talent with a specific domain. The clearest example we’re working through right now: a biotech client building an oncology AI platform needs an ML engineer who can think clearly about tumor biology and treatment-response data. The pure-ML candidates can train any model. They can’t tell you why a feature derived from RECIST measurements is or isn’t a clean signal for the question being asked. The pure-oncology candidates can read the literature. They can’t ship a model behind an API at the latency a clinical decision support workflow requires. The candidates who can do both, in the same week, in the same head, are unicorns. Genuinely scarce. So the intake conversation is mostly about which side of the overlap matters more for the actual work. Then about the team structure if the unicorn doesn’t appear. A senior applied ML engineer plus a clinically-fluent staff scientist, say, paired tightly for the first six months. Often that gets you there. Sometimes faster than the unicorn would have.

This pattern shows up across regulated and data-sensitive verticals. Healthcare ML. Fraud and AML. Insurance claims modeling. Process control in manufacturing. Climate and earth-systems modeling. The 2024 McKinsey State of AI report documented that AI talent gaps remain the most cited barrier to scaled AI adoption across industries, and the survey breakdown lines up with what we see on intake calls. The companies most successful at scaled AI adoption hire for the overlap, not for either side alone.

For us specifically, the proof behind the framework is the searches we’ve closed in this overlap. Across the last decade we’ve placed 1,000+ IT and engineering professionals at City of Hope — ML, data engineering, applied research — supporting their oncology research, clinical trial pipelines, and the analytics platform that backs the day-to-day work. We also built and ran the data warehouse engagement at CHOC Children’s, the one underneath their pediatric analytics and AI initiatives, and the work taught our recruiters what real production-grade clinical data actually looks like before it touches a model. Not the cleaned-up version that shows up in research papers. KORE1’s overall 12-month retention rate of 92 percent across IT placements is largely a function of getting this overlap right at intake. Domain-fit hires stay. Generic ML hires placed into domain-specific roles leave inside eighteen months. They thought the work would be modeling. It turns out to be data plumbing inside a regulatory framework, with the actual modeling work being maybe ten percent of the calendar. Different job. Different person. The hiring conversation should reflect that, and our intake notes call this out explicitly when the role has any clinical, financial-controls, or compliance overlay that’s going to dominate the day-to-day.

If your ML role lives in a domain that requires fluency beyond the toolkit, name it in the JD. “Experience with healthcare data” is not enough. Try this instead: “Experience with EHR data, claims data, or clinical trial data, including HIPAA-aware ML pipelines and the data quality realities that real clinical datasets bring versus the clean benchmark versions on Kaggle.” That language attracts the candidates who actually fit, and the specificity is the filter. Counterintuitive. Correct.

Things Hiring Managers Ask Us About ML Engineer Searches

What’s the Difference Between an ML Engineer and a Data Scientist?

An ML engineer ships systems. A data scientist ships analyses, recommendations, and sometimes models that get handed off to engineering. The dividing line is production responsibility, not modeling skill.

Strong ML engineers can do data science work and often have a foundation in statistics. Strong data scientists can train models and often have software fluency. The difference shows up in how each role is evaluated. ML engineers are evaluated on whether the system runs in production, meets its latency budget, and improves a product metric. Data scientists are evaluated on whether their analysis changes a decision and on the quality of the modeling work itself. JDs that ask for both in equal weight usually end up with a hire who’s strong at one and uncomfortable doing the other half of the job.

Should the JD Specify a Framework Like PyTorch or TensorFlow?

Pick the one your team uses and name it. Strong applied ML engineers can ramp on the other framework in a week, but they want to know what they’ll actually be writing on day one.

The exception is if you’re committed to JAX, Polars, or another less-common stack. Name it explicitly, because the candidate pool with real production experience there is smaller and the candidates who care will self-select in. A JD that says “experience with PyTorch, TensorFlow, JAX, or similar” reads as “we don’t actually have a stack yet” and the strong candidates will read it that way.

How Long Does It Take to Fill an ML Engineer Role?

Five to eight weeks for a clean applied ML search. Eight to twelve for senior LLM or domain-specialist roles. Senior research-track searches can run twelve weeks or longer, especially when the candidate has multiple competing offers.

The variable that shifts timeline more than anything else is intake clarity. A role with a defined lane, a clear seniority target, and a specific problem space closes faster than a role with three lanes blurred together and a comp band that doesn’t match the experience requirement. KORE1’s average time-to-hire across IT roles is 17 days when the intake is clean. ML searches with ambiguous intake can run six times that. The intake call is the highest-leverage hour of the search.

Do I Need a Candidate with a PhD?

For applied production work, almost never. For research-track roles where the work is novel modeling and experimentation, often yes. For LLM application work, the answer is changing as the field matures.

The PhD signal matters most when the role requires the candidate to evaluate research papers, design experiments that produce publishable results, or contribute to model architecture work. For applied ML engineering, what matters is production track record. We’ve placed senior applied ML engineers without PhDs who outperform candidates with three. The credential is a tiebreaker, not a requirement, on the production side of the spectrum.

How Should the JD Handle the LLM and GenAI Side of the Role?

If LLM work is more than a quarter of the actual responsibility, write the JD for an LLM engineer specifically and budget the higher comp band. If it’s a small slice of an applied role, name it as a preferred qualification and don’t anchor the comp on it.

The mistake we see most often is a hiring manager wanting LLM expertise as part of an applied ML role at applied ML comp. The candidates who can do production LLM work end-to-end have other offers. They will not take a 20 percent pay cut to be the LLM person on a team where the rest of the work is feature pipelines. Decide whether you’re hiring an LLM engineer or an applied engineer, and budget accordingly.

What Should the Interview Process Look Like?

Four rounds is the working norm: technical screen, ML system design, hands-on coding (production-style, not LeetCode), and an applied scientist or domain expert deep dive on the work itself.

The mistake we see most often is overweighting LeetCode-style algorithmic problems. Strong ML engineers are software engineers, but the part of the job that decides whether they ship is usually system design and applied judgment, not whether they can invert a binary tree on a whiteboard. The hands-on round should be a realistic ML problem with messy data, not a perfectly clean toy dataset. For more on this, see the 2026 AI/ML engineer interview questions guide.

If you’re working through an ML engineer search and want a second opinion on the JD, the comp band, or the intake plan before posting, reach out to our team. KORE1’s IT staffing practice places ML engineers across applied, research, LLM, and domain-specialist lanes in 30-plus U.S. markets, with a 92 percent 12-month retention rate that we credit largely to getting intake right before the first candidate ever sees the post.