AI Data Scientist vs ML Engineer: Job Descriptions That Actually Work (2026)

Most AI job descriptions fail before anyone reads them, and they fail the same way: the company hasn't decided which role it's hiring.

You've seen the result. A posting titled "Machine Learning Engineer" that asks for A/B testing, stakeholder communication, dashboarding, Kubernetes, distributed training, causal inference, and a publication record. Nobody has that combination. What you get is a pipeline of people who each have a third of it, an interview loop where three panelists are evaluating three different jobs, and a hire who turns out to be wrong for the work that actually needed doing.

The fix is upstream of the posting. This guide covers the diagnostic — which role you actually need — then gives you two job descriptions you can adapt, plus the requirements language that helps and the language that quietly destroys your pipeline.

---

First: which role do you actually need?

The cleanest test I know is a single question.

When the model produces an output, what happens next?

A human looks at it and makes a decision. → You need a data scientist. The deliverable is understanding: a forecast someone acts on, an experiment result that settles a debate, a segmentation that changes how the product is built.

Software acts on it, thousands of times an hour, unattended. → You need an ML engineer. The deliverable is a system: something that trains, serves, monitors, and retrains, with an on-call rotation attached.

A foundation model does the work and the hard part is the surrounding system. → You need an AI engineer. The deliverable is a product feature: retrieval, agents, tool use, evaluation harnesses, cost and latency management.

If your honest answer is "both," you have two roles, not one hybrid. Write two postings. A single hybrid posting doesn't get you a unicorn; it gets you a diluted pipeline and a hire who's mediocre at the half you care about most.

The asymmetries worth knowing before you write

On-call. ML engineers own serving, pipelines, and uptime. That means pages, incidents, and immediate fixes. Data scientists generally don't. If your posting doesn't mention the on-call reality, you'll lose the hire in week three of onboarding instead of week one of interviewing.

Compensation. ML engineers command roughly 15–40% more than data scientists at median — Levels.fyi puts ML engineer median total comp near $261K–$272K versus about $175K for data scientists. That premium is paid for the software engineering, not the modeling. If you post an ML engineering role at data science comp, you will not fill it.

Communication. This is the one most engineering managers underweight: 73.9% of data scientist postings emphasize communication skills — more than any technical tool. For a data scientist, the ability to change a VP's mind is not a nice-to-have. It's the job. Write it as a requirement, and screen for it.

Market heat. AI engineer is currently the fastest-growing job title in the US, per LinkedIn's Jobs on the Rise 2026. It's also the least standardized — "AI engineer" means genuinely different things at different companies, so your posting has to define it rather than assume it.

What changes between the three postings

	Data Scientist	ML Engineer	AI Engineer
Owns	Analyses, experiments, metrics	Training + serving systems	AI product features
Success in year one	A decision that changed because of their work	A system running reliably in production	A shipped feature with a defensible eval
Must-have	Statistics, experiment design, communication	Software engineering, infra, distributed systems	Retrieval, evals, product engineering
Nice-to-have	Deep learning, production deployment	Statistical depth, causal inference	Model training, fine-tuning
On-call	Rarely	Yes, and say so	Sometimes
Comp band	Lower	Highest of the three	High, wide variance
Screen for	Judgment under ambiguity	Production ownership history	Evaluation rigor

Note the "nice-to-have" row. Those items are what most companies wrongly put in "requirements," and each one you promote to required cuts your qualified pool substantially while adding almost nothing to hire quality.

---

Template 1: AI Data Scientist

Adapt the bracketed parts. Keep the structure.

AI Data Scientist

[Team] · [Location / Remote policy] · [$X–$Y base + equity]

The work

We're building [product], and we make decisions about it too slowly and too often on instinct. You'd be the person who changes that. Concretely, in your first year you would own the measurement and experimentation behind [specific surface — e.g. our recommendation feed / our onboarding funnel / our LLM assistant's answer quality], and your work would settle questions we currently argue about.

This role sits with [team] and works most closely with [PM / ML engineering / the founding team].

What you'd do

• Design and analyze experiments on [specific surface], including deciding what we should be measuring and telling us when a metric is lying to us
• Build the evaluation framework for our [AI feature] — eval sets, rubrics, and validation that our judges are actually trustworthy
• Model [specific problem: churn / demand / pricing / answer quality] well enough that a team can act on the output
• Investigate why numbers moved, and distinguish real behavior change from instrumentation change
• Present findings to [audience] and be the person who says the uncomfortable thing when the data doesn't support the plan

What we need

• Strong applied statistics: experiment design, power, confounding, selection bias. You should be able to explain why a result is or isn't trustworthy without reaching for a library.
• Fluency in Python and SQL. SQL properly — window functions, CTEs, and the judgment to know when a number is wrong.
• Demonstrated ability to communicate with non-technical stakeholders. In the interview we'll ask you to explain a past analysis to someone who doesn't share your background.
• Evidence that an analysis you ran changed a decision.

Nice to have, genuinely not required

• Experience evaluating generative AI systems
• Deep learning or model training background
• [Your domain: fintech / healthcare / marketplaces]
• Production deployment experience

What this role is not

You would not own production model serving or carry an infrastructure on-call rotation — that sits with [ML engineering / platform]. If owning deployed systems end to end is what you want, our [ML Engineer posting] is the better fit.

Compensation and process

[$X–$Y] base, [equity range], [benefits]. Process: [30-min intro → technical screen → take-home or structured analysis discussion → team conversations]. We aim to go from first conversation to decision in [N] days.

---

Template 2: Machine Learning Engineer

Machine Learning Engineer

[Team] · [Location / Remote policy] · [$X–$Y base + equity]

The work

We have [N] models in production and [honest description of the current state — e.g. "no monitoring, manual retraining, and a deploy process that takes two days"]. You'd own fixing that and then own the platform it becomes. In your first year you would [specific, verifiable outcome: get inference latency under Xms / build the training pipeline for our ranking model / take our retraining loop from manual to automated].

What you'd do

• Own [specific system] end to end: training, serving, monitoring, retraining
• Build and maintain training pipelines in [your stack]
• Optimize inference for latency and cost — [batching / quantization / caching / GPU scheduling]
• Instrument drift and quality monitoring, and act on what it shows
• Participate in an on-call rotation for model serving [frequency: e.g. one week in five]
• Work with [data science / research] to take models from experiment to production

What we need

• Strong software engineering. Not "can write Python" — testing, code review, system design, and the ability to debug something in production at an awkward hour.
• Experience owning a deployed ML system, including what broke and how you found out.
• [PyTorch / TensorFlow] and one cloud platform to deployment depth ([AWS SageMaker / GCP Vertex / Azure ML]).
• Containers and orchestration: Docker, and Kubernetes if you have it.
• Comfort with the operational half of the job. This role carries a pager.

Nice to have, genuinely not required

• Distributed training at scale
• Statistical or research background
• LLM inference optimization
• [Your domain]

What this role is not

This is not primarily a modeling or research role. You'd be improving and productionizing models more often than inventing them. If designing novel architectures is the part you want, this isn't the right posting.

Compensation and process

[$X–$Y] base, [equity range], [benefits]. On-call: [honest description, including compensation or time-off policy for it]. Process: [30-min intro → systems/coding screen → system design → team conversations].

---

The requirements section is where postings go to die

Six specific fixes, in order of how much pipeline they recover.

1. Publish the salary band. Not "competitive." A range. Strong candidates in this market filter out unbanded postings, and in a growing number of jurisdictions you're required to post one anyway. This single change does more for pipeline quality than anything else on this list.

2. Cut the years-of-experience number, or halve it. "5+ years of ML experience" is a proxy for capability that excludes career-changers with two years of exceptional production work and admits people with five years of notebooks. Describe the capability instead: you've owned a deployed ML system through at least one serious failure.

3. Move most of your requirements to "nice to have." Go through your must-have list and ask, for each item: would we genuinely reject an otherwise excellent candidate over this? For most items the answer is no. Every false must-have shrinks your pool and disproportionately deters candidates who self-select out — which skews your pipeline in ways you didn't intend.

4. Drop the PhD requirement unless it's a research role. For applied work it filters on credential rather than capability, and it removes a large share of the strongest infrastructure and product engineers in the field.

5. Name the stack, and don't list twenty things. Candidates match on specifics — PyTorch, SageMaker, Airflow, Kubernetes. But a list of thirty technologies reads as either confusion about the role or an expectation of impossible breadth. Name the six that matter.

6. Say what the role is not. The single most underused section in tech hiring. It costs you two sentences, and it filters out mismatches before they consume four interview slots. Candidates consistently report it as a signal of a well-run team.

Say something about AI tool use

One line, and it's increasingly conspicuous by its absence. Roughly 71% of candidates are using AI to help write applications, and most postings are silent on it — so candidates guess, and the guess makes everyone worse off.

We assume you'll use AI tools in your work and in your application. We care that what you tell us is accurate and specific about your own contributions.

That's it. It's honest, it removes a guessing game, and it signals more thought than your competitors have put in. (The reasoning behind it, including why AI detection tools are a bad idea in screening, is a longer argument — the short version is that they misfire badly on non-native English speakers.)

Audit your own posting

• I can state in one sentence what happens to the model's output — and it matches the title
• The title matches what the person will actually do, not our internal levelling
• There's a salary range
• First-year success is described concretely enough to verify
• Must-haves are things we'd genuinely reject an excellent candidate over — nothing more
• On-call expectations are stated if they exist
• There's a "what this role is not" section
• Named specific technologies, and fewer than ten
• No PhD requirement unless this is genuinely a research role
• One honest line about AI tool use
• Someone outside the team read it and correctly guessed which of the three roles it is

That last item is the real test. If your own colleagues can't tell, candidates can't either.

For candidates: how to read these postings

The same structure works in reverse.

Find the role behind the title. Ignore what it's called and look at the responsibilities. Does the work end at an insight or at a deployed system? That tells you which of your résumés to send — and yes, you should have more than one.

A hybrid posting is a warning. If it asks for causal inference and Kubernetes and distributed training and stakeholder communication, the team hasn't decided what it needs. That ambiguity doesn't disappear when you're hired; it becomes your performance review.

Read the must-haves as negotiable and the first three bullets as real. Responsibility bullets are usually written by the hiring manager and describe actual work. Requirements are often copy-pasted from a template. Weight them accordingly.

No salary range plus vague responsibilities plus a long requirements list is a reasonable signal to deprioritize. Not disqualifying — but there are better postings.

Absence of "what this role is not" tells you something too. Teams that have thought hard about scope usually say so.

FAQ

What's the difference between an AI data scientist and an ML engineer?
Data scientists produce insight a human acts on; ML engineers produce systems that act automatically. The dividing line is what happens after the model runs. ML engineers own deployment, monitoring and on-call; data scientists own analysis, experimentation and measurement.

Should one job description cover both?
No. Hybrid postings produce diluted pipelines and interview loops where panelists evaluate different jobs. If you need both, write two postings.

Which should we hire first?
If you have no models in production, hire a data scientist to establish what's worth building and how you'll measure it. If you have models that work but can't be maintained, hire an ML engineer. Companies that hire ML engineering first often end up with excellent infrastructure serving models nobody validated.

How much more do ML engineers cost?
Roughly 15–40% more at median — about $261K–$272K versus $175K total comp per Levels.fyi, skewed toward large US tech employers. Budget accordingly, because the premium is for the software engineering and it isn't optional.

Do we need a PhD requirement?
Only for research scientist roles. For applied data science, ML engineering, and AI engineering it filters on credential rather than capability and costs you strong candidates.

What's the single highest-impact change to an AI job posting?
Publish the salary range. Second: add a "what this role is not" section.

---

The short version

A good AI job description is an act of decision-making, not description. Decide what happens to the model's output, write the posting for that one role, publish the band, cut the fake requirements, and say what the job isn't.

Every hour spent on that is an hour you don't spend interviewing people for a job you hadn't defined.

---

DevFound is an AI-first job platform for AI and ML talent — post a role and reach a curated audience of AI engineers, or browse open positions if you're on the other side of the table.

---

Sources

• Levels.fyi — reported total compensation medians: ML engineer ~$261K–$272K, data scientist ~$175K (US, skewed toward large tech employers)
• Bureau of Labor Statistics — data scientist employment projected to grow 33.5% 2024–2034
• LinkedIn Jobs on the Rise 2026 — AI engineer as fastest-growing US job title
• Job-posting skill analysis, 2026 — 73.9% of data scientist postings emphasize communication skills; ML engineers carry the highest on-call burden of the three roles
• AI recruiting surveys, 2026 — ~71% of candidates use AI tools when applying

Compensation figures are self-reported and directional. Job-posting analyses come from industry trackers with varying methodology.