The job market in AI has changed rapidly over the past decade, both in titles and in responsibilities. What used to be advertised as a machine learning engineer or an ordinary data scientist role is scarce now, and has largely given way to the title of Artificial Intelligence Engineer, or AI Engineer. Somewhere in between, LLM Engineer and GenAI Engineer had their moment. Titles aside, all of these roles have always demanded a thorough understanding of how the algorithms work, and enough mathematical rigour to reason about a black-box model.
More often than not, the job description on a job board for an AI Engineer is vague and extremely broad, and many students — and plenty of working professionals — conclude that the skill set is beyond them. That alone makes the path hard to see. Add AI agents in every tool handing out vague answers and the same generalised roadmap, and it becomes harder still. Most of those roadmaps are, in the end, somebody selling a course.
At Sahi Padhai we are making an honest attempt at a better answer, using our connections in the industry, a lot of research, and interview experience from both sides of the table. This cannot be a complete guide. It should be more than enough to get you through most interviews with flying colours, and to give you the confidence to build your own AI models.
What an AI engineer actually does
An AI engineer builds products on top of models rather than training them from scratch. The core skills are solid Python, a working understanding of how a transformer works, retrieval (RAG), prompting, evaluation and deployment. You do not need a PhD, you do not need to train a foundation model, and you do not need to pay for any of it. Six focused months is enough to be employable if you build things along the way.
It helps to separate three roles that get confused with each other.
A research scientist invents the methods: new architectures, new training objectives, new alignment techniques. This is where the PhD requirement is real. You will also find many Applied Scientist positions of this kind at companies such as Microsoft and Amazon.
A machine learning engineer, in the traditional sense, trains and deploys models on a company's own data: forecasting, recommendations, fraud detection, classification. Feature pipelines, model training, monitoring. In today's job market, an ML engineer is also expected to know Databricks, feature stores, MLflow, MLOps, Docker and a handful of other software engineering practices.
An AI engineer builds products on top of models that already exist. Retrieval over company documents, assistants and agents, structured extraction, evaluation harnesses, and keeping all of it fast and affordable enough to run. Agentic AI is an evolving requirement at many companies, but what you must have is an end-to-end understanding of deep learning, machine learning and transformer models, along with the Python skills to debug all of it — including the code the AI writes for you.
The skills that are actually tested
From interview reports and job descriptions, the list is shorter than the roadmaps suggest.
Python. The advanced, or rather the less common, corners of the language come up surprisingly often: dataclasses, decorators, dunder methods and object-oriented design. Code has become far more modular with the spread of agentic AI frameworks, and interviewers test accordingly.
How transformers work. Tokens, embeddings, attention, context windows, how generation actually happens. You will be asked to explain attention, and the follow-up questions go several levels deeper than a definition. One example: what would happen if you swapped the dropout and layer normalization layers in a transformer?
Prompting and in-context learning. Few-shot examples, chain-of-thought, structured outputs, and knowing why the model behaves differently when you change the format.
Retrieval (RAG). The single most employable skill on this list. Chunking, embeddings, vector search, reranking, and knowing how to tell whether retrieval is the part that broke.
Adapting models. When to fine-tune and when not to, what LoRA does and why it is cheap, and the honest answer that most problems that look like fine-tuning problems are prompt or retrieval problems.
Evaluation. How you know the thing works. Most candidates can build something and stall completely on this question, so it is a cheap way to stand out.
Cost and latency. What a request costs, where the time goes, and what you would do about it. Mentioning this unprompted marks you as someone who has shipped.
Failure modes. Hallucination, jailbreaks, and what you would do about them in production.
Notice what is not on the list: training a large model from scratch, CUDA kernels, distributed training, most of classical machine learning theory. They are good to know, and they are rarely what gets tested for this role.
A six-month plan
This roadmap assumes you can give it around eight to ten hours a week, with programming already in your repertoire. If you cannot program yet, spend two months on Python first and then start here.
Month 1 — Foundations
You need enough mathematics to follow the ideas: vectors, matrices, derivatives, probability. Then neural networks from first principles — a neuron, gradient descent, backpropagation, why deep networks are hard to train and what fixed it. Having the foundations in place is also what makes a research paper readable later.
Our Deep Learning course covers exactly this, from the first artificial neuron through to optimizers and regularisation, and the Deep Learning simulator lets you watch each idea run instead of taking it on trust.
Month 2 — How language models work
This is the month that separates people who use AI from people who can build with it. Tokens and embeddings, attention from first principles, positional encodings, and how a model turns a vector into the next word.
Work through our Large Language Models course, modules 1 to 5. Do not rush attention — everything later depends on it, and it is the topic every interview probes hardest. The Transformer Lab is worth an hour or two here; watching attention weights move as you edit a sentence does more for intuition than another pass through the text.
Month 3 — Retrieval
The most directly employable month. Why retrieval is needed, chunking, embeddings, vector databases, hybrid search, reranking, and how to evaluate the whole pipeline.
Our Advanced RAG Masterclass is built for this, and the RAG Lab lets you take a pipeline apart and see which stage is losing the answer.
Month 4 — Adapting and running models
Fine-tuning and when it is the wrong answer, LoRA and QLoRA, quantization, the KV cache, why inference costs what it does. Modules 6 to 10 of the LLM course cover the efficiency and post-training material, including fine-tuning and LoRA and alignment.
Month 5 — Evaluation, agents and failure modes
How to measure a model (perplexity, BLEU and ROUGE, preference ranking), how agents work and the four ways they get stuck, and why models hallucinate and can be jailbroken.
Month 6 — Ship something, then prepare
Put one project in front of real users, even a handful. Deployment, cost, latency, what breaks, what people actually ask it.
Then prepare deliberately. Our How to Crack the AI Engineer Interview course maps what each round tests onto the lessons that cover it, so you can find your gaps rather than re-reading what you already know. We have also included sample questions that an interviewer could genuinely ask, to test your knowledge from a few different angles.
Which resources to use
We also maintain a separate, longer list of courses, in case Sahi Padhai is not to your taste for some reason — although we do take feedback seriously. It covers free university courses from Stanford, MIT and the IITs, NPTEL, practical courses, GitHub repositories and the paid platforms worth considering, and it is in How to Learn AI in 2026: The Courses Worth Your Time. If you want the full catalogue rather than one path through it, start there.
What actually gets you hired
Projects beat certificates. Two or three things you built, understand completely and can discuss honestly will do more than a stack of course completions. Interviewers probe depth, and a small project understood thoroughly beats a large one described vaguely.
Numbers beat adjectives. If you have deployed anything, know its latency, its cost per request and where the bottleneck was. Almost nobody brings these to an interview.
Be able to say what you do not know. Confident guessing is the single most damaging habit in these interviews — and, as it happens, the failure mode of the models you will be discussing.
Practise speaking. This is the one everybody skips. Practise answering out loud, as much as you can: with a friend, on a mock interview platform, or with an AI assistant's voice mode. What you want is the back-and-forth, not a rehearsed monologue.
Frequently asked questions
Do I need a degree in computer science? No. The authors at Sahi Padhai come from core engineering backgrounds such as electrical engineering, and have cleared plenty of data science and AI interviews. A computer science degree helps you get past the filters at large companies, but a great many working AI engineers came from physics, mathematics, electronics or self-study.
Do I need to know how to train a model from scratch? No, and almost nobody does it. You need to understand what training does well enough to reason about a trained model's behaviour, which is a different and much smaller requirement. That said, getting your hands dirty and actually training a few models will only deepen what you know — and Google Colab offers a decent free GPU tier to experiment on.
Is it too late to start in 2026? The field is three years into a shift that will take a decade. What has changed is that the easy roles have gone: "can use ChatGPT" is not a skill any more. Building and evaluating reliable systems on top of models is, and there are not enough people who can do it. Besides, at the rate AI is moving, trained AI engineers are exactly what the world will need if it ever goes rogue — only half in jest.
Do I need a GPU? Not for most of this. API calls, retrieval and evaluation need nothing special, and a free Colab tier is enough for a small LoRA fine-tune. Buy hardware when a specific project demands it, not before.