MLOps Engineer Job Description Template 2026

Last updated: September 13, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

An MLOps engineer job description should name the models already in production, say whether they score in batch or answer in real time, identify the platform underneath them, and state who gets paged when one goes wrong. Base pay for mid-level and senior MLOps engineers runs about $145,000 to $210,000. The modeling frameworks most templates lead with belong near the bottom of the requirements, if they belong there at all.

An auto insurer in Woodland Hills hired the wrong MLOps engineer in February. The posting did it. The interviews were fine.

They had eleven models in production. Nine priced policies or scored claims overnight, in batch jobs Airflow started at 1 a.m., and two ran in real time, including a fraud score that had to come back inside 150 milliseconds while a claims adjuster sat looking at the intake screen waiting for it. The data science lead wrote the req on a Friday afternoon, stitched together from two templates he found online and the posting for a data scientist they had filled the year before. One responsibility was to build and train machine learning models, and the must-haves asked for proficiency with TensorFlow, PyTorch, or scikit-learn, plus experience with MLflow and Kubeflow and SageMaker. Nothing about the eleven models. Nothing about on-call.

It pulled 186 applicants in twelve days. Most were data scientists and ML engineers. I understand why. It described their job. The team hired a strong one, an engineer with a published recommender-systems paper and four years of PyTorch, at $185,000.

On her third day she learned she was in the on-call rotation for the fraud score. Nobody had mentioned it. She had never been on call for anything, and by week two she had written up a proposal to rebuild the claims model from scratch, which nobody had asked for either. By week seven she had accepted a research role at a company in Culver City. I never blamed her for leaving. She took the job that was written down.

The second posting opened with one sentence. “You will keep our eleven production models running, including a real-time fraud score with a 150-millisecond budget, and you will share on-call for it one week in four.” Applications fell to 41. The slate changed completely. Site reliability and platform engineers who had spent real time around ML systems made up most of it, and the insurer hired one at $192,000, five weeks after the repost.

Where I sit, before any advice. I manage recruiting at KORE1, and a machine learning search that has stalled tends to land on my desk somewhere around week six. Recruiting fees are how we get paid, so a company that writes a posting good enough to fill its own MLOps seat is, strictly speaking, a deal our MLOps engineer staffing desk never sees. I still want you to have the better posting. I mean that. Most of what follows costs an afternoon and one candid conversation with your data science lead.

MLOps Work Starts After a Model Is Trained

An MLOps engineer is responsible for the systems that carry a trained machine learning model into production and keep it trustworthy once it is there. That covers training and deployment pipelines, the model registry, serving infrastructure, monitoring for drift and bad input data, scheduled retraining, and a share of on-call when a model starts misbehaving.

What a posting usually leaves out is where the team is starting from. Google Cloud’s architecture guide on MLOps sorts teams into three levels. Level 0 is manual. Level 1 automates the ML pipeline itself, so models retrain on fresh data without somebody running a notebook by hand. Level 2 automates delivery of the pipeline too, with source control and a model registry and a feature store and an orchestrator all wired together. At level 0, the guide notes, a new model version gets deployed only a couple of times per year, and data scientists hand the trained model to engineers as an artifact.

That handoff describes most of the companies I talk to.

No shame in it. The trouble starts when the posting hides it. Put a greenfield builder inside a mature pipeline and she is restless by the end of the quarter. The reverse fails too. Someone who spent three years running a big retailer’s pipeline arrives to find no pipeline at all, only two data scientists deploying from their laptops who first have to be talked out of it, and that is a very different first month than the one they signed up for. One sentence sorts that out. “We are at level 0, deploying by hand about twice a year, and you are here to get us to level 1 by next summer.” Nobody reads that and applies by accident.

Our MLOps hiring guide covers the choice between the pipeline, serving, and full-stack versions of this seat. Settle that first. The posting only has to report the decision.

Batch Scoring and Real-Time Serving Are Different Hires

Most MLOps postings say “deploy models to production” and stop there. Production is a big word.

A model that scores forty million loan records overnight is a data pipeline with a model in the middle of it. The hard problems are scheduling, retries, backfills, and noticing on Tuesday that Monday’s input file arrived half empty. Those failures wait until morning. A model answering a checkout page in 80 milliseconds is a service, and its hard problems are latency, autoscaling, cold starts, and deciding at 2 a.m. whether to roll back or ride it out. They are different muscles. Then there is a third thing that has crept into a lot of MLOps reqs over the last eighteen months, serving large language models on GPUs, which turns out to be a capacity and cost problem at least as much as a reliability one, and which the posting almost never mentions until the final interview.

A marketplace company in Pasadena put real-time inference in its posting because the VP of engineering liked how it sounded. Every model they ran was a nightly batch job. The first two finalists asked about latency targets on the phone screen, heard there were none, and withdrew within a day of each other. They lost both. Nobody had lied to the finalists, exactly. The VP was still surprised. The posting described a more interesting job than the one on offer.

Operating SageMaker Is Not Building a Platform

Some MLOps engineers operate a managed platform. The company runs Amazon SageMaker, Google Vertex AI, Azure Machine Learning, or Databricks, the vendor carries most of the infrastructure, and the engineer’s work is wiring training jobs, endpoints, the registry, and monitoring into something repeatable. SageMaker shops are the ones I see most. Other MLOps engineers build the platform. Their company runs Kubernetes, and the team assembles Kubeflow Pipelines or Argo for orchestration, MLflow for tracking, KServe or Ray Serve for serving, and a great deal of Terraform to hold it all together. Both count as MLOps. People with real build experience are scarcer, though, and a good number of them have no wish to go back to a managed service where the vendor makes the decisions they enjoy making.

So write the sentence that says which kind of shop you are. “We train and serve on SageMaker, with MLflow as the registry, and we have no plans to self-host” is honest, and it scares off nobody who would have been happy there. That line costs nothing. If you are partway through a move between the two, name the direction and the date, because a migration is its own job with an end date and candidates weigh it that way.

One more check while the requirements are open. If your runbook still talks about promoting a model to the Production stage in the MLflow registry, the posting probably borrowed that wording. The MLflow documentation has marked model stages deprecated since version 2.9, with removal planned for a future major release, and it points teams toward aliases such as “champion” instead. I checked the docs myself. Anyone who has used MLflow recently will notice. It will not sink you. It does tell them how current your registry habits are.

Your Data Scientists Will Read This Posting Too

One requirement pulls the wrong applicants more reliably than any other, and it sits on most of the MLOps templates I come across, the line asking for proficiency with TensorFlow, PyTorch, or scikit-learn. I see it constantly.

Several of the templates ranking for this search put that line near the top of the must-haves, and a couple list building and training models as a core responsibility. Read it as an applicant. Model building is the job a data scientist or ML engineer already has, so those are the people who apply, and they are often excellent, and they are often gone within a year, because the seat turns out to be about keeping somebody else’s models alive. Modelers apply in droves.

What an MLOps engineer needs from those frameworks is narrower. Enough to package a PyTorch model with its dependencies pinned. Enough to estimate how much GPU memory it wants at inference time, and to read a training script well enough to tell whether last night’s failed retraining run was a data problem or a code problem. The list stops there. I would put exactly that in writing. “You will not be building models, but you will need to read our PyTorch training code comfortably and package what it produces” is a sentence a modeler skips and an operator applies to.

If the seat really is model building with some deployment attached, our ML engineer job description template is the better starting point.

The reporting line matters nearly as much as the requirements, and hardly anyone writes it down. An MLOps engineer who reports to the head of data science tends to spend the year unblocking data scientists, one request at a time. One who reports into platform or infrastructure engineering tends to spend it building shared systems and turning down one-off asks. Both setups work. Candidates hold strong views on which they want, though, and last spring I watched a finalist decline $200,000 on the last call once she learned she would report to a director of analytics. She took another offer that week. It belongs near the top of the posting, right beside the model count.

Loud Failures, Quiet Failures, and Who Owns Each

The insurer’s second posting worked because of a single sentence about on-call.

Machine learning systems break in two ways, and most postings only picture one of them. The loud way looks like any other outage. An endpoint starts throwing errors, a batch job dies at 3 a.m., and somebody gets paged. The quiet way looks like nothing at all. Every dashboard stays green while an upstream team renames a column, one feature fills with nulls, and a fraud model goes on scoring claims for a week on what amounts to a guess. No alert fires. Eventually a claims manager notices the approval rate has drifted, and the first honest answer anyone can give is a shrug.

So who owns the quiet kind? Some teams leave model quality with data science and keep the MLOps engineer on pipelines, endpoints, and infrastructure. Others want the MLOps engineer building the drift and data checks that catch a silent failure early, and making at least the first call on pulling a model. Those are different jobs. An engineer who spent three years keeping endpoints alive may never have been asked whether a model’s predictions still made sense, and plenty of them would rather not be. The posting should say which failures wake this person up and which go to the data scientist who built the model. That split matters. Candidates who have lived through a vague one ask about it early, and I would rather they read the answer before the first call.

Model Risk Rules Changed in April

This part is for banks, and for the lenders and insurers whose model validation teams borrowed the bank playbook.

For fifteen years the reference point in those postings was SR 11-7, the Federal Reserve’s 2011 guidance on model risk management, and plenty of the banking MLOps reqs I have read ask for SR 11-7 experience by name. That changed in April. On April 17, 2026, the Federal Reserve, the FDIC, and the OCC replaced it with revised interagency guidance on model risk management. The new version is more principles-based, describes itself as most relevant to banking organizations with more than $30 billion in total assets, and leaves generative and agentic AI models out of its scope. I read that line twice.

That last detail changes the posting more than the rest. It matters here. Picture a seat covering credit and fraud models plus a new LLM-based assistant for claims, where the validation framework your candidates know applies to the first group and says nothing at all about the second. Say what your team does for the LLM work, even if the honest answer is “our model risk group is still writing that policy, and you would help shape it.” Candidates from regulated shops read that as a sign somebody has actually opened the April guidance. And retire the old citation while you are in there, since “experience supporting independent model validation” will age better than any letter number.

Glassdoor and ZipRecruiter Are $45,547 Apart

Same title. Same country. Same year.

Glassdoor puts the average US MLOps engineer salary at $161,411, with the middle of its range running from $132,496 to $199,473. ZipRecruiter says $115,864 as of September 2, 2026, with most people earning between $83,000 and $151,500. Neither site is broken. Each one is averaging a different mix of jobs that happen to share a title, from a junior engineer watching batch jobs at a regional insurer to someone running GPU inference for a product with a million daily users, and whichever mix a site samples decides its number.

That gap is the argument of this whole page, in one statistic.

The bands we work from line up with our MLOps engineer salary guide, where the numbers are split by city, stack, and adjacent title in far more detail than a posting needs.

Publish the range. California has required a pay scale on job postings from employers with 15 or more employees since January 2023 under SB 1162, and that covers postings a third party publishes on your behalf, so any recruiter running the search needs the number as well. Recruiters ask for it now. Rules elsewhere vary. The practical case does not. Experienced MLOps engineers hear from recruiters constantly, and the messages without a salary figure are the ones they leave unread. To see how a figure holds up in your own city, try it in our salary benchmark assistant.

MLOps Engineer Job Description Template

Brackets hold the parts only your team can answer. Some take ten minutes. Fill them in, and remove my commentary as you go. A bracket still empty after a week usually marks the conversation with data science that has not happened yet.

Job Title

[MLOps Engineer, Real-Time Inference / Senior MLOps Engineer, Model Pipelines / MLOps Engineer, LLM Serving] [Keep “MLOps Engineer” in the title, since that is the phrase candidates search for. Then add whatever makes this seat different from the last three MLOps postings they read.]

About the Models and the Team

[Company] is hiring an MLOps engineer [based in city, state / working remotely across these US time zones]. We have [number] models in production, [number] scoring in batch and [number] serving in real time, and they decide [what they decide: policy prices / search ranking / which claims get a second look]. They run on [SageMaker / Vertex AI / Azure Machine Learning / Databricks / Kubernetes with Kubeflow and KServe], with [MLflow / the platform’s own registry] tracking versions. By Google’s MLOps maturity levels we are at [level 0 / level 1 / level 2], and in the first year we want [the change you are hiring for]. The role reports to [title], and the people you will work with most are [the data scientists or ML engineers whose models you will operate].

What You Will Run

• The pipelines that retrain and redeploy our [number] production models, including [the one everybody worries about]
• Real-time serving for [the model with a latency budget], held to a p99 of [number] milliseconds
• Monitoring that catches quiet failures as well as loud ones. Drift, a feature going null after an upstream change, a prediction mix that shifts while nobody touched the model
• Model promotion, meaning who approves a new version, what it has to pass first, and how quickly it can be rolled back
• Training and inference spend, reviewed with [finance / the platform lead] every [month / quarter]
• [On-call one week in [N], paged for [endpoint and pipeline failures only / model quality alerts as well].] [Say which failures go to this person and which go to the data scientist who built the model.]

Required

• [4+] years building or operating production software, with at least [2] of those spent close to machine learning in production
• Python strong enough to read and debug our training code, and to package what it produces for [batch jobs / real-time serving]
• Hands-on time with [the platform you actually run], rather than a list of every platform on the market
• CI/CD for models as well as for code, including checks a model version must pass before promotion
• Docker, and [Kubernetes / the managed service’s own deployment tooling]
• A model that misbehaved in production on your watch, and what you changed so it could not fail the same way twice

Worth Mentioning If You Have It

• Feature stores such as Feast or [the one you use]
• Serving large language models with vLLM or a comparable inference server, if [the LLM roadmap] is part of the seat
• Terraform or another infrastructure-as-code tool
• Supporting independent model validation, for anyone in [banking / insurance / lending]
• PyTorch or TensorFlow, deeply enough to talk through a model’s architecture with the people who built it

Interview Steps

[A 30-minute screen with the engineering manager. An hour on an ML system you have run in production, including a time it broke. Ninety minutes working together on a model that behaves differently in production than it did in training, figuring out why. No unpaid take-home.] [Describe the loop you will really run. MLOps candidates are usually employed, and a clear process is one of the few things that moves them.]

Compensation and Location

Base pay of [$175,000 to $210,000], a [bonus target], [equity grant and vesting schedule], and [benefits]. [Remote, overlapping [time zones] / in our [city] office [N] days each week / onsite full time in [city].] [If the band moves for LLM serving or platform-build work, say how far.]

Two neighbors worth knowing about. When the seat is mostly building product features on foundation models, the generative AI engineer job description template fits better than this one. When the posting is finished and the loop is not, our MLOps interview questions cover the promotion gate, the monitoring conversation, and the cost question most panels skip.

What ML Leads Ask Me While Drafting This Req

MLOps engineer, ML platform engineer, or ML engineer. Which title is right?

The title should follow the work. Keeping models reliable on their way to and through production is MLOps, building an internal platform other teams ship on is ML platform engineering, and building the models is ML engineering.

At smaller companies they blur, and one person often does two of the three. Most teams already know which one fills the week. Title the seat for that, and describe the rest in the body. If you are right on the line between the first two, our ML platform engineer staffing page shows where the second role starts.

Our data scientists deploy their own models right now. Should we wait?

Not once more than a handful of models are in production, or once anyone outside data science depends on what they output. Around that point, deploying by hand starts costing more than the hire would.

The tell I listen for is a data scientist spending Friday afternoon re-running a notebook because Thursday’s job failed. I have watched it happen. Three of those in a month and you are already paying for an MLOps engineer, just in the wrong currency. Our guide on when an MLOps hire starts to make sense walks through the other signals.

Can one MLOps engineer cover both batch and real-time models?

One engineer can cover both when the real-time side is small, a couple of endpoints with forgiving latency targets. Once a checkout page or a fraud decision waits on a strict p99 budget, the serving work needs its own owner.

Most teams I work with start with one person and split the seat around the third real-time model. That order works. Write the first posting so the serving half is visible, though, or the person you hire will not know it is coming.

We use SageMaker, but we might move to Vertex AI. Do we list both?

List the platform you run today, and mention the possible move in one sentence of the team description. A must-have naming both filters out the engineers who know one of them deeply, who are the people you want.

Good MLOps engineers switch managed platforms without much drama. The concepts carry over. The console does not, and nobody needs it to.

Should the posting say anything about cost?

If the engineer will own the training and inference bill, the posting should say so and give a rough monthly figure. That ownership changes who applies, and it tells candidates the job includes turning down expensive ideas.

GPU spend is where this bites. A $9,000 monthly bill and a $140,000 one describe different jobs under the same title, and an engineer who has already cut the second kind of bill in half is going to want that conversation on the very first call, well before anyone asks about Kubernetes.

Can we post one req and let candidates pick contract or full-time?

Pick one per posting. A req offering both reads as undecided, and contract MLOps engineers and permanent candidates scan the first paragraph for different things, end dates for one group and growth for the other.

When the work has a finish line and someone permanent already owns the result, bring in contract MLOps engineers against it. When the seat is the long-term owner of your models, run a direct hire search. I have seen the combined version fill exactly once. The contractor liked the team enough to stay.

Count the Models Before You List a Single Tool

The insurer did not need a better candidate pool in February. They needed the number eleven in the first line of the posting, plus a sentence about the fraud score and an honest word about on-call. The rest of their second draft was close to the first.

I would start with arithmetic. Count what is running. Split batch from real time. Then the platform, the reporting line, and the maturity level, even when level 0 is the truthful answer and somebody on the team would rather call it level 1. Tools come after that, then a salary range and the loop. By then the writing goes fast.

MLOps searches are among the slower ones we run. Plan for that. Our direct hire placements under this title have been taking closer to four weeks than the 17-day average we see across IT roles, mostly because the best candidates are already employed and the bands need a round of negotiation. The retention holds up better than the timeline does, at a 92 percent twelve-month rate on KORE1 placements, and we have been recruiting technology talent since 2005, now in more than 30 US metros. Our MLOps desk also sits beside the team handling AI and ML engineer staffing, so a req that turns out to be a modeling seat does not start over from zero. If you would like a draft read before it goes live, or an MLOps search has already stalled, send it to our MLOps recruiters.