Last updated: July 9, 2026
By Tom Kenaley, Senior Partner and President, KORE1
A data scientist finds what your data can tell you. An ML engineer makes that finding run in production at scale. One hands back insight and a prototype model, the other ships a system that stays accurate under real traffic. Both write Python. Same language, sure. Only one gets paged at 3am when the model drifts. Pick the wrong one for the problem in front of you and the work stalls. A quarter, sometimes two.
I get a version of this call almost every month. A company decides it is finally going to do something real with its data. Someone drafts a job posting. The posting asks for a PhD in statistics and deep Kubernetes experience and the ability to present to the board and to keep a model serving at single-digit millisecond latency. That is not a hire. That is four people wearing one lanyard, and the search for that unicorn runs until the req quietly dies. It always does.
Here is my bias, out loud. KORE1 places both of these roles for a living through our AI and ML engineer staffing practice, so we make money when you hire one of them through us. I will still tell you, a little further down, about the times you should not hire either. That advice costs us a fee. I would rather you spend the money once, on the right person, than twice.

What You’re Actually Hiring For
A data scientist turns data into a decision. They frame the question, pull and clean the data, run the experiment, build a model to test the idea, and then explain what it means to people who do not care about p-values. The thing they hand back is an answer, usually with a recommendation attached and often a working prototype in a notebook.
Statistics is the spine of the job. So is communication. A data scientist who cannot get a skeptical VP to act on the finding is only doing half the work. Maybe less.
An ML engineer takes a model and makes it live in the real world. They build the pipelines that feed it, the service that serves it, the monitoring that catches it when it goes wrong, and the retraining loop that keeps it honest as the data shifts. The thing they hand back is a running system, not a slide.
Software engineering is the spine here. That prototype the data scientist built at 0.9 AUC on a laptop? Someone has to make it survive a million requests a day without falling over. Every day. Forever. That someone is an ML engineer.
So one asks a question and answers it. The other takes an answer and makes it hold up in production. Two jobs. Not one. They share Python, they share a whiteboard now and then, and honestly that is about where the overlap ends. Different day, different tools, different person grilling them in the interview. We wrote a companion piece on the nearby confusion, data engineer vs data scientist, because the data-engineer role gets tangled into this same knot more often than any other.
The Comparison, One Row at a Time
Here is the split laid out flat. Read the last row twice. The one about where each hire goes sideways is the row that shows up on almost every intake call we take.
| Dimension | Data Scientist | ML Engineer |
|---|---|---|
| What they hand back | An answer, a recommendation, and often a prototype model in a notebook | A trained model running in production, versioned, monitored, and retrainable |
| The core question | What is happening, why, and what should we do about it? | How do we make this model run reliably at scale, forever? |
| What it leans on | Statistics, experiment design, and communication | Software engineering, distributed systems, and operations |
| Core tools | Python or R, pandas, scikit-learn, statsmodels, SQL, Jupyter, Tableau or Looker | PyTorch, TensorFlow, MLflow, Kubernetes, SageMaker or Vertex AI, Spark, feature stores, CI/CD |
| Data it needs | Whatever answers the question, messy is fine, exploration is the point | Clean, versioned, pipeline-fed, and flowing at production volume |
| A normal day | Framing a problem, cleaning data, running an A/B test, presenting to stakeholders | Building serving infrastructure, cutting latency, chasing drift, on call when it breaks |
| Usual background | Statistics, economics, physics, or a quantitative graduate degree | Computer science and years of shipping production software |
| Senior US base, 2026 | $165K to $215K | $180K to $240K |
| How the hire goes sideways | Handed a production system to build and own alone, with no engineers behind them | Asked to define the business question and design the experiment from scratch |
The Handoff Where Models Go to Die
One part of this page matters more than the rest. This is it. The most expensive mistake we get called to fix is not hiring the wrong title. It is hiring one of these two and assuming they cover the other one’s job.
A model has two lives. First it gets born in a notebook, where a data scientist proves it works on historical data. Then, if it is lucky, it gets a second life in production, where it makes real predictions on live data every day. The gap between those two lives is where most machine learning projects quietly go to die. We see it constantly.
Here is the version I watched play out. A logistics company in the Newport Beach area hired a genuinely strong data scientist. Stanford stats background, sharp, likable. She built a churn model that scored beautifully on the last two years of customer data. Everyone was thrilled. Then it sat. For eight months it lived in a notebook on her laptop because there was no pipeline to feed it live data, no service to call it from the app, no monitoring to tell anyone when it started drifting. She was not the wrong hire. She was the only hire, when the job actually needed two. They called us to find the person who could take her model and make it run. We placed a machine learning engineer, and the churn scores were live in the product inside seven weeks. Seven weeks. Not eight months.
It runs the other direction too, and that one is quieter. A team hires a brilliant ML engineer, hands them the org’s data, and waits for insight. Months pass. The engineer builds gorgeous infrastructure, a feature store, a clean serving layer, a retraining schedule that would make a platform team weep with joy. But nobody framed the business question. Nobody designed the experiment. There is a perfect machine with nothing worth running through it. Wrong problem for the person. Same root cause as the first story, flipped.
The lesson is not complicated. Insight and deployment are two skills, and they live in two people far more often than in one. The rare engineer who is genuinely excellent at both exists. You should not build a hiring plan around finding them, any more than you would staff a restaurant assuming you will hire a chef who is also a plumber.

What Each One Costs in 2026
Numbers are where the distinction turns into a budget line, so here is what we actually see on signed offers, checked against public data. These are US base ranges. Base only, no equity. Funded startups and the big labs stack grant value on top, sometimes another 30 to 60 percent, and finance and the frontier labs pay past everything in this table.
| Level | Data Scientist (base) | ML Engineer (base) |
|---|---|---|
| Junior (0-2 yrs) | $95K to $130K | $115K to $145K |
| Mid (3-5 yrs) | $130K to $170K | $145K to $185K |
| Senior (6+ yrs) | $165K to $215K | $180K to $240K |
| Staff / principal | $230K to $320K+ | $260K to $360K+ |
Notice the ML engineer column runs a touch higher at every level. That gap is not random. It is supply. The pool of people who can build a solid model is larger than the pool who can build a solid model and also keep it serving reliably at scale, and scarcity sets the price. The software-engineering half of the ML engineer job is simply harder to find bundled with the modeling half.
The aggregators tell the same story with wider numbers, mostly because they mix base and total compensation. Levels.fyi puts the median machine learning engineer at roughly $272K in total compensation and the median data scientist closer to $175K, with equity doing most of the lifting at the big names. Built In lands in a similar place. When you compare offers, compare like with like. Apples to apples. A $185K base is not smaller than a $250K total-comp figure that includes $70K of stock that vests over four years.
For the wider market, the government data lags a fast-moving field but points in one clear direction. The Bureau of Labor Statistics projects data scientist employment to grow 34 percent between 2024 and 2034, the fourth-fastest of any job it tracks, on a 2024 median wage of $112,590 and about 23,400 openings a year. Software developers, the closest official bucket for the ML engineer’s systems work, are projected to grow 15 percent with a 2024 median of $133,080. Python sits at or near the top of the 2025 Stack Overflow Developer Survey either way, which tells you the base of talent is broad even where the true specialists are thin.
Want to pressure-test a band against your city and stack before an offer goes out? Our salary benchmark assistant is built for exactly that, and we keep the deep breakdowns in the data scientist salary guide and the machine learning engineer salary guide.
Which One Your Problem Actually Needs
Forget the title on the JD for a second. What is the actual problem? The fastest sorting question I know, do you need to learn something, or do you need to ship something that runs on its own every day?
Hire a data scientist first if your questions are still open. Why are customers churning. Which pricing change actually moved revenue and which one just looked like it did. What the experiment says once you control for the obvious confounders. You are drowning in data and starving for decisions. Most companies at the start of their analytics journey live here, and a good data scientist earns their salary in the first quarter by killing one bad assumption the leadership team was about to bet on.
Hire an ML engineer first if you already know the model works and you need it to run. Maybe a data scientist or a consultant already proved the concept. Maybe you are past the experiment and the thing that is missing is reliability, latency, monitoring, and a retraining loop that does not depend on one person remembering to run a notebook on Fridays. Recommendation engines, fraud scoring, real-time pricing, anything where the model has to answer in milliseconds and never sleep. Milliseconds. Every time. That is deployment territory, and deployment is an engineering job.
Hire both once machine learning is load-bearing for the business rather than a side experiment. At that stage the two roles feed each other. The data scientist finds the next thing worth building, the ML engineer makes the last thing durable, and the handoff between them becomes a real workflow instead of a prayer. What you should not do is hire one and hope they quietly become the other. They usually just burn out trying. We have watched it happen.
Hold off on both if your data is a swamp and your only real project so far is a dashboard nobody trusts. Fix the plumbing first. Bring in a data engineer, get a warehouse the numbers agree on, earn back some trust in the basic reports. Modeling on top of broken data is a fast way to spend six figures generating confident, wrong answers. We will say that on the first call rather than sell you a search you are not ready to run.

How to Screen Each Without Burning a Loop
A generic coding screen will not separate these two, and it will waste a week of everyone’s calendars proving it. Different roles, different failure modes. The tests have to match.
For a data scientist, hand them a messy, real dataset and a fuzzy business question, then watch how they think. Do they interrogate the question before they touch the data? Do they worry about selection bias, about what the data is not telling them, about whether the metric even measures the thing leadership cares about? Then, and this is the part most technical interviews skip, make them explain a finding to a smart non-expert. The best data scientist in the world is worthless to you if the room cannot follow the recommendation. Communication is not a soft skill for this role. It is the deliverable.
For an ML engineer, give them a model and a scaling problem. How would they serve it. How do they think about latency, about rollback when a bad version ships, about the difference between a model that passes a test set and a model that holds up six weeks into production. Then ask the question that sorts the seniors from the rest: tell me about a model that was quietly wrong in production and how you caught it. Anyone can train something that looks good on held-out data. That part is easy. What you are paying a senior ML engineer for is the instinct for what happens after the model meets the messy, drifting real world, and the discipline to build the alarms before it does.
Where a Recruiter Earns the Fee, and Where We Don’t
Straight version first. If you already have a data or ML leader who knows this distinction cold, a healthy inbound pipeline, and the time to run a careful loop, you may not need us. Some teams are set up to run these searches themselves. They should.
You feel the value of a partner when the role is specialized and the calendar is unforgiving. We have spent more than 20 years placing technical talent, our average time-to-hire across IT sits around 17 days, and 92 percent of the people we place are still in the seat a year later. On data and ML searches the biggest thing we do is upstream of any resume: we pull apart the role on the first call and tell you whether you wrote a data scientist req that is secretly an ML engineer job, or the reverse. We staff the analytical side through data scientist staffing and the deployment side through machine learning engineer staffing, across direct hire, contract, and contract-to-hire, in more than 30 US metros.
Sound like your situation? Talk to a recruiter and tell us what the work actually looks like, not what the title says. We sort the role before we source a single candidate.
What Hiring Managers Ask Us First
So is a data scientist just an ML engineer who’s bad at engineering?
No, and framing it that way will cost you good candidates. They are different jobs, not different skill levels of the same job. A data scientist is an expert in statistics, experiment design, and turning ambiguity into a decision. An ML engineer is an expert in building and operating production systems. Ranking one above the other is like asking whether a cardiologist outranks a surgeon.
We only have budget for one hire this year. Which one?
One hire? Start with the problem, not the person. If your questions are still open, why customers leave, what is really driving cost, hire the data scientist. If the model already works and just needs to run reliably in your product, hire the ML engineer. When you genuinely cannot tell which, it is usually a sign you need the data scientist first to define what is even worth building.
Can one strong person really do both jobs?
A few can, early on. At a ten-person startup a single sharp generalist often covers both, and that is fine until it isn’t. The trouble comes when companies scale that expectation into a senior req and go looking for a unicorn who ships research-grade models and runs production infrastructure and presents to the board. That person is rare and expensive, and the search for them stalls more reqs than almost anything else we see.
How long does it take to fill one of these in 2026?
Three to six weeks is realistic for a well-scoped senior role, against our broader IT average near 17 days. ML engineers with real production-deployment experience trend toward the longer end, because that specific bundle of modeling plus systems skill is thin at the senior level and the strong ones usually have two other offers on the table.
Where does an AI engineer fit next to these two?
Different lane again. An AI engineer builds products on top of foundation models from OpenAI or Anthropic rather than training models from your own data. If you are weighing that role, we untangled it in AI engineer vs ML engineer. Short version: data scientists ask questions, ML engineers ship trained models, AI engineers wire up someone else’s model into a feature.
What happens if we get the choice wrong?
Usually a lost quarter. And a frustrated hire. The data scientist handed a production mandate ships nothing because the plumbing was never theirs to build. The ML engineer handed an open research question builds beautiful infrastructure around a problem nobody framed. Neither one is failing at their actual craft. They were pointed at the wrong work, and good people leave roles like that faster than you can backfill them.
Do these roles report to the same person?
Sometimes. Not always. And it matters more than most orgs think. Data scientists frequently sit closer to the business or product, sometimes under analytics. ML engineers usually sit in engineering, near the platform and infrastructure teams. When machine learning becomes core, the smartest setup we see puts them on one team with a shared roadmap so the handoff from insight to production stops being a game of telephone.
The whole thing collapses to one move most teams skip. Scope the actual work first, then pick the title that fits it. That is it. Decide whether you need someone to find the answer or someone to make the answer run, then write the posting for that one job and hire for it. Get that right and the search gets short. If you would rather hand the sorting to someone who does it every week, reach out to our team and we will scope it with you before we send a single resume.
