Most guides to AI careers list job titles. That is the least useful part, because the titles are the thing changing fastest. A role advertised as “AI Engineer” at one company is a backend job with an API key; at the next it is applied research. The title tells you almost nothing.
So this guide is organised around the work instead. Five paths, what each one actually involves on a Tuesday afternoon, what the interviews test, and who each suits. If you are trying to decide where to aim, the shape of the work is a far better signal than the words in the job ad.
Why job titles are a poor guide right now
Three things are happening at once. Established companies are renaming existing data roles to attract AI candidates. Startups are inventing titles that describe a stack rather than a discipline. And a genuinely new category of work — building reliable systems on top of models nobody fully understands — has appeared without settling on a name.
The practical consequence is that you should read the responsibilities section and ignore the heading. If a posting mentions retrieval, evaluation, latency budgets and cost per request, it is an engineering job regardless of what it is called. If it mentions experiment design, causal inference and stakeholder reporting, it is an analytics job even if the title says AI.
The five paths
1. AI / LLM Engineer
You build products on top of models you did not train. The day-to-day is retrieval pipelines, prompt and context design, tool calling, evaluation harnesses, caching, and the unglamorous work of making a system behave the same way twice.
This is the role with the widest gap between how it sounds and what it is. Very little of the time goes on model cleverness. Most of it goes on the plumbing around the model: chunking documents sensibly, deciding what belongs in context, catching the cases where the system answers confidently and wrongly, and keeping the bill under control. Our write-up on why RAG returns wrong answers is essentially a description of this job.
Interviews test: system design under real constraints, debugging a pipeline that returns plausible nonsense, and whether you can reason about cost and latency out loud. Expect to be asked how you would evaluate something before you are asked how you would build it.
Suits you if: you are already a competent backend or full-stack engineer and you like systems that fail in interesting ways. This is the most accessible entry point for working software engineers, because the transferable skill is engineering judgement rather than mathematics.
2. Machine Learning Engineer
You train, fine-tune and ship models, and you own them in production. Feature pipelines, training infrastructure, deployment, monitoring for drift, retraining schedules. Where the AI engineer treats the model as a component, you treat it as the artefact.
This role has existed long enough to have real conventions, which makes it easier to prepare for and harder to bluff. You need the mathematics — not research-level, but enough to know why your loss curve looks like that and why your validation split is lying to you.
Interviews test: classical ML fundamentals, coding, and a production scenario — how you would detect that a deployed model has quietly degraded, and what you would do about it. Deep learning specifics vary enormously by team.
Suits you if: you enjoy the empirical loop — hypothesis, experiment, measurement — and you are comfortable owning something that can break silently at three in the morning.
3. Data Scientist
You answer questions with data and change what the business does. Experiment design, causal reasoning, analysis, and communicating a result to people who will act on it without reading your notebook.
The role split hard over the past few years. At some companies it is a product-analytics job with SQL and experimentation at its centre; at others it is closer to applied statistics or research. Both are legitimate, and they want different people, so read the posting carefully before you prepare.
Interviews test: SQL, statistics, experiment design, and a case study where the honest answer is often “this test cannot tell us that”. Being able to say so is usually the thing being assessed.
Suits you if: you like ambiguous questions and you are a genuinely good explainer. The communication component is not a soft add-on here; it is most of the seniority ladder.
4. AI Infrastructure / Platform Engineer
You make it possible for everyone else to work. Serving infrastructure, GPU scheduling and utilisation, inference optimisation, quantisation, observability, and the internal tooling that turns a research artefact into something a product team can call.
This path is underrated and consistently in demand, largely because it is unglamorous and requires real systems depth. If you have fought with CUDA memory, batching strategies or throughput tuning, you already have the instincts — our guide to CUDA out of memory errors covers the kind of problem that lands on this desk weekly.
Interviews test: distributed systems, performance reasoning, and hardware awareness. You will be asked to work through a throughput or memory problem rather than to recall an algorithm.
Suits you if: you came from infrastructure, systems or DevOps and you would rather optimise the machine than tune the model. The transition from platform engineering is the shortest of any path on this list.
5. AI Product Manager
You decide what gets built and, more importantly, what “good enough” means. Scoping problems that suit probabilistic systems, defining quality bars, designing what happens when the model is wrong, and managing expectations in both directions.
The distinguishing skill is calibration. AI features fail differently from ordinary software: they degrade rather than break, they are wrong confidently, and their failure modes are hard to enumerate in advance. A product manager who does not understand that ships a demo and then discovers it in front of customers.
Interviews test: product sense applied to uncertainty. Typical prompt: here is a feature that works 85% of the time — do we ship it, and what does the interface look like for the other 15%?
Suits you if: you are already a product manager or a strong technical generalist, and you can hold a conversation with engineers without pretending to be one.
The skills that actually transfer
Across all five, the same three things keep separating people who get offers from people who do not.
- Evaluation. Being able to say how you would know whether the thing works. Most candidates can describe a build; far fewer can describe a measurement. This is the single highest-leverage skill to develop, and it is teachable.
- Failure reasoning. Knowing the specific ways these systems go wrong and being able to diagnose from a symptom. Anyone can say “hallucination”; the useful answer names a mechanism.
- One project you can defend in depth. Not a tutorial reproduction. Something where you made choices, measured the result, and can explain what you would do differently. Interviewers dig, and depth on one project beats breadth across six.
How to choose
Start from what you already are, because lateral moves are far easier than standing starts. Backend engineers should look at AI engineering. Infrastructure and DevOps people should look at platform work. Analysts and statisticians should look at data science. Anyone with a strong mathematics background and patience for experiments should look at machine learning engineering.
The mistake I see most often is people from a software background deciding they must first complete a deep learning curriculum before they are allowed to apply. For AI engineering roles specifically, that is backwards. The bottleneck is rarely mathematics; it is that most candidates have never built something that had to be reliable.
Getting the first role
Build one thing that has a measurable claim attached to it, and write up the measurement honestly, including what it does not prove. That artefact does more than any certificate, because it demonstrates exactly the judgement the interview is trying to assess.
For the interviews themselves, our AI and machine learning interview questions covers the fundamentals methodically, and the LLM system design interview framework gives you a structure for the open-ended rounds, which is where most technically capable candidates come unstuck. Current openings across AI, data and cloud are on our jobs board.
A note on salaries
You will find plenty of articles quoting precise figures for these roles. Treat them carefully. Compensation in this field varies so widely by country, city, company stage and whether equity is meaningful that a single national average is close to useless for planning. Two people with the same title in the same city can be a factor of three apart.
The more reliable approach is to gather live figures for your specific market and level from levels.fyi, Glassdoor and recent postings that disclose ranges, then discount the headline numbers, which skew toward the people who enjoy reporting them. What is broadly true is that infrastructure and machine learning engineering tend to pay above general software engineering in the same market, and that the premium narrows as these skills become common.
Frequently asked questions
Do I need a master’s degree or a PhD?
For research positions, usually yes. For the other four paths on this list, no — a demonstrable project and solid engineering fundamentals carry more weight. A PhD helps most where the work involves training models from scratch.
Which path has the lowest barrier for a working software engineer?
AI engineering, followed by platform work. Both build directly on skills you already have, and neither requires you to become a statistician first.
Are these roles at risk from AI itself?
The routine parts, yes — boilerplate, first-draft code, standard analyses. What is not automating is judgement about whether a system is actually working, which is precisely the skill this whole article keeps pointing at. Build toward the judgement, not the syntax.
How long does a transition realistically take?
For an experienced engineer moving into AI engineering, a few months of focused project work alongside a job is a reasonable expectation. Career changes from outside software take considerably longer, and anyone promising otherwise is selling something.
The short version
Pick the path closest to what you already do. Build one project you can defend under questioning. Learn to evaluate systems, not just build them. That combination is what actually converts into offers, and none of it depends on which title happens to be fashionable when you apply.
More on this topic in AI Career & Interviews. Last reviewed September 2026.
