The 6-Week AI Engineer Interview Prep Plan
A week-by-week AI engineer interview prep plan: LLM fundamentals, retrieval, agents and tool use, the eval harness that actually decides the loop, ML system design, MLOps and inference, practical coding, and behavioral stories.
BY MEI LIN · AIINTERVIEWTRAINING EDITORIAL · UPDATED JULY 12, 2026 · 9 MIN READ
A realistic AI engineer interview prep plan fits in six weeks if you spend them on what the loop actually grades: LLM fundamentals, retrieval, agents and tool use, evaluation, ML system design, MLOps and inference economics, practical coding, and a project you can defend. Weight it toward evaluation, because that is the round where the field thins out. Anyone can sketch a RAG pipeline on a whiteboard. Very few candidates can say how they would prove it works, and interviewers know it. Below is the week-by-week version with what to practice and where.
| Week | Focus |
|---|---|
| 1 | LLM and GenAI fundamentals |
| 2 | Retrieval and RAG |
| 3 | Agents, tool use, and the eval harness |
| 4 | ML system design |
| 5 | MLOps, inference, and cost |
| 6 | Coding sprint, behavioral, mock loops |
Run a coding rep alongside all of it: 30 to 45 minutes a day from week one, so the week-six sprint is a sharpening pass rather than a panic.
Before week one: baseline yourself honestly
Take one timed pass through the must-know question set before you plan anything. The goal is not a high score. It is to find which of the domains is weakest so you can tilt the six weeks toward it instead of dividing effort evenly. Most software engineers moving into AI find the gap sits in evaluation and inference economics, not in coding. Most ML researchers find it sits in production engineering. Read the interview process overview once so you know which rounds you are training for.
Week 1: LLM and GenAI fundamentals
You cannot bluff this layer and every later round rests on it. Get precise about tokens and tokenization, the context window and what actually fills it, attention and the KV cache, temperature and top-p, why the same prompt gives different answers, and what a hallucination is mechanically rather than metaphorically.
Then the decision that comes up in nearly every loop: prompting versus retrieval versus fine-tuning. Have a position. Mine is that retrieval is the default when the problem is missing knowledge, fine-tuning is for format and behavior rather than facts, and prompting solves more than people admit before they reach for either. Be ready to say what would change your mind.
Work the LLM and GenAI fundamentals set until the follow-up questions stop surprising you. Finish the week able to do the token cost math for a feature on the back of a napkin.
Week 2: Retrieval and RAG
Retrieval is the load-bearing skill of the whole job. Go past the tutorial version. Chunking strategy and why fixed-size chunks lose meaning at boundaries. Embeddings and where they fail (acronyms, rare product names, negation). Hybrid search: why BM25 still rescues queries your vector index quietly gets wrong. Reranking and what it costs you in latency. Keeping the index fresh when the source documents change under you.
Build a small retrieval system this week over a corpus you actually care about. Not a notebook demo. Something with an ingestion path, a query path, and a way to look at what got retrieved when the answer was wrong. Drill the design and tradeoff questions in RAG and agent system design, and be ready to defend one specific chunking and retrieval choice rather than listing the menu.
Week 3: Agents, tool use, and the eval harness
Two halves, and the second one matters more.
Agents first: tool calling and schema design, multi-step planning, when a loop earns its keep against a single well-prompted call, and how you bound it so it cannot spiral in cost or take an unsafe action. Interviewers are skeptical here on purpose. Reaching for an agent when one call would do reads as a red flag, so know the conditions under which you would refuse to build one.
Then the eval harness, which is the real bottleneck in this field and in the interview. Take the retrieval system you built in week two and put a real evaluation around it: define what correct means, hand-label 50 examples, measure retrieval quality (recall at k) separately from answer quality, and run it as a gate. Then break something on purpose and watch whether the eval catches it. That single exercise gives you an answer to the follow-up almost nobody survives: the demo looks great and the eval score is mediocre, so what do you do next?
Week 4: ML system design
Now the architecture level. The design round expects a lifecycle, not a diagram: frame the problem (what are you predicting, what does one training example look like, where does the label come from), pick the model and defend it against the constraints you were given, plan offline and online evaluation, deploy, and detect drift.
Practice both flavors, because which one you get depends on the team. The classical version is recommendation, fraud detection, or ranking. The GenAI version is grounding a model in a private corpus or automating a multi-step workflow with tools. Study the ML system design set and the broader system design questions for the scale and reliability patterns underneath both.
State constraints before solutions. Latency budget, cost ceiling, freshness requirement, privacy boundary. Then say which one you are trading away.
Week 5: MLOps, inference, and cost
This is the week that makes your designs believable. Serving and inference: batching, KV caching, quantization at a conceptual level, why p95 latency and not the average is what your users feel, where a semantic cache buys you real money. Pipelines: training and serving skew, feature freshness, retraining cadence, and what your rollback looks like when a bad model reaches production traffic.
Do the cost math on a feature you have shipped or want to. Tokens per request times requests per day times price per million tokens, then ask what happens when usage grows 100x. Candidates who can do that arithmetic out loud sound like engineers who have owned a budget. Work the MLOps and ML engineering set for the production side.
Week 6: Coding sprint, behavioral, and full mock loops
Front-load the coding. Three days of concentrated practice: data structures at the software engineering bar if you are targeting big tech, and practical builds if you are targeting the labs. The build pattern to rehearse is get it correct, then extend it as the interviewer adds a requirement, without breaking what already worked. Use coding and DSA.
Then the stories. Prepare four or five from the behavioral and project deep-dive prompts: a system you owned end to end, a technical call you got wrong and how you found out, a time you cut scope under a deadline, a disagreement you lost and what changed your mind. Your headline project needs to survive rapid follow-up on why you chose that database, that model, that chunk size. If your honest answer is "it was already there when I joined," pick a different project.
Close with two full mock loops back to back: coding, design, deep dive, behavioral. Fatigue and context-switching are part of the real test. Learn nothing new in the last three days. Refine what you have.
The one-line version
Six weeks does the job if you allocate them by what the loop actually grades. Fundamentals so nothing catches you out, retrieval because it is the modal design round, an evaluation harness you genuinely ran because it is the follow-up that thins the field, ML system design as a lifecycle rather than a diagram, honest inference and cost math, and a project you can defend under pressure.
Turn it into offers. Work the real questions and concepts this maps to:
FAQ
If you already write software or ML code for a living, yes. Six weeks of concentrated work across LLM fundamentals, retrieval, agents, evaluation, ML system design, and practical coding puts you in competitive shape. If you have never shipped anything model-backed, budget eight to ten weeks and spend the extra time building one retrieval or agent system end to end with a real eval harness.
Discussion (5)
The most valuable habit in this plan is the one people skip in week three: whenever you design or build anything, write down how you would know it is working before you write the code. Interviewers ask for the eval last, and by then it is obvious who bolted it on.
Agreed. My rule for candidates is that no design answer is finished until you have named the metric, the labeled set, and the regression gate. Say those three things unprompted and you separate yourself from most of the field.
One thing to add to the eval week: write down what you would do if the eval score comes back mediocre while the demo looks great. That tension is a favorite follow-up, and most candidates walk in with no answer. The real answer usually involves splitting the eval by slice until you find the failing one.
If your time is tight, don't attempt all six weeks at half effort. Trim the scope instead. A candidate who has genuinely mastered retrieval, evaluation, and one shipped project beats one who skimmed ten topics.
This. Going deep on the retrieval and eval rounds plus one real project will carry a loop further than thin coverage spread across everything.
