You have a month, a long list of topics, and no way to know which ones will come up. The workable answer is to stop trying to cover everything: pick one project, learn the handful of mechanisms that every AI engineer loop leans on, and practise saying it out loud. This is a 30-day AI engineer interview prep plan built that way, with a day-1 diagnostic, daily tasks, a total of 59 hours, and a cut list for when you only have two weeks.
I designed this plan for this site. It has not been tested on candidates, and I make no claim about hiring outcomes. The question patterns it points you at are ones I wrote for practice; none are from a real company's interview. Treat the first week as a calibration of the plan, not a promise.
How much time does a 30-day AI engineer interview plan need?
The plan assumes three kinds of day: a weekday (2 hours), a weekend day (3 hours) and a 1-hour day (five of them: the four weekly reviews and the light day 30). I wrote a small script that lays the plan on a calendar so the hours add up. I ran it with Python 3 on 2026-10-09 for a Monday start and for a Wednesday start:
$ python3 plan.py 2026-10-12
Days 1-7 2026-10-12 (Mon) to 2026-10-18 (Sun): 14 hours
Days 8-14 2026-10-19 (Mon) to 2026-10-25 (Sun): 14 hours
Days 15-21 2026-10-26 (Mon) to 2026-11-01 (Sun): 14 hours
Days 22-28 2026-11-02 (Mon) to 2026-11-08 (Sun): 14 hours
Days 29-30 2026-11-09 (Mon) to 2026-11-10 (Tue): 3 hours
Total: 59 hours over 30 days
Weekend days in the window: 8
$ python3 plan.py 2026-10-14
Total: 63 hours over 30 days
A Wednesday start gives 63 hours because the review days land on weekdays (2 hours become 1) and the weekend days are used for work (3 hours). The script isn't doing anything clever: it assigns 2 hours, 3 hours or 1 hour to each of the 30 tasks depending on the weekday and whether the task is marked as a review. If your calendar differs, change the three constants at the top and rerun it. The hours are my assumption, not a measured requirement for any role.
Who is this plan for, and who should skip it?
It fits you if you can already write Python and call an LLM API, and you're aiming at an applied AI engineer role: building RAG apps, agents and evals on top of models rather than training them. If the job post says "research scientist" or lists model training from scratch, this plan is the wrong shape. If it's a service-company loop, read GenAI interview questions for service companies vs product companies first, because the emphasis differs.
Skip the plan, or shrink it, if you have no Python or API experience. In that case spend the month on the build-a-RAG-chatbot tutorial and the career roadmap for SDET and backend engineers, then plan interviews for next month.
Week 1: model internals and a baseline
| Day | Task |
|---|---|
| 1 | Cold diagnostic: answer 10 questions from the RAG, agents and evals list out loud, score each 0 to 2 |
| 2 | Tokenization and embeddings, using the tokenization and embeddings questions |
| 3 | Attention and the KV cache: derive the cache formula and plug in one real model config (attention and KV cache post; to see it run, the NumPy transformer walkthrough) |
| 4 | LoRA and QLoRA: what is trained, what is frozen, memory arithmetic (LoRA interview questions) |
| 5 | Python async: write a concurrent API caller with a semaphore, timeout and retry (async concurrency for AI engineers) |
| 6 | Pick the one project you will prepare (a RAG app is the safest) and get it running end to end |
| 7 | Review: redo the day-1 questions you scored 0 or 1 |
Done when: you can write the KV cache formula from memory, and your project answers a question over your own documents.
The day-1 scoring rule matters, because it decides how you spend the next three weeks. Score 0 if you couldn't start, 1 if you answered but missed the key mechanism or a number, and 2 if a colleague would accept the answer as given. Then use this table:
| Day-1 average | What to do |
|---|---|
| Under 0.8 | Keep the plan as written; add 30 minutes on weekdays for the weakest week |
| 0.8 to 1.4 | Keep the plan as written |
| Above 1.4 | Compress weeks 1 and 2 into one week and spend the saved time on mock interviews |
Those thresholds are my judgment, not calibrated cut-offs. Their only job is to stop you from spending equal time on things you know and things you don't.
Week 2: retrieval and evaluation
| Day | Task |
|---|---|
| 8 | Chunking, hybrid search and reranking: change one thing in your project and note the effect (chunking compared) |
| 9 | Vector databases: HNSW vs IVF, recall vs latency, when a flat index is enough (vector database questions) |
| 10 | Write a 20-question eval set for your project with expected answers and source chunks (how to build one) |
| 11 | Compute hit rate and MRR on those 20 questions |
| 12 | RAG metrics: faithfulness, context precision, context recall on five questions by hand (RAG evaluation metrics explained) |
| 13 | Fix your biggest failure and record before and after numbers |
| 14 | Review: re-explain the eval numbers without notes |
Done when: you can say "my hit rate at 5 was X, it dropped on question type Y, I changed Z and it became W" about your own project, with real numbers.
This week is where the plan earns its keep. Interviewers asking about evaluation can tell quickly whether you have ever labelled a question set. Twenty questions is small, and I'm not claiming it's statistically strong. It is enough to see a retrieval failure, and enough to give you a true story.
Week 3: agents, tools, cost and a timed design
| Day | Task |
|---|---|
| 15 | Tool use: design two tool schemas and list how each can fail (designing tools for agents) |
| 16 | MCP: tools, transports, authorization and the main risks (MCP interview questions) |
| 17 | Agent design: memory, loop limits, failure handling (agent design walkthrough) |
| 18 | Cost math: cost per 1,000 requests for your project, with stated assumptions (worked examples) |
| 19 | Latency budget: time to first token, caching, where the seconds go |
| 20 | Timed 45-minute system design on a RAG chatbot, spoken aloud and recorded (walkthrough) |
| 21 | Review: listen to the recording and write down three things you skipped |
Done when: you have a cost number for your project with every assumption listed, and a recording you could bear to replay.
Listen to the recording once, without pausing. You are hunting for three specific things: a question you should have asked before designing, a number you stated without multiplying it out, and a failure mode you never named.
Week 4: your story, then mocks
| Day | Task |
|---|---|
| 22 | Project README: problem, architecture, numbers, failures, what you would change (README template) |
| 23 | Explain the project aloud in 5 minutes, then in 90 seconds (explaining a RAG project) |
| 24 | Write four behavioural stories (conflict, failure, ownership, learning) using real details |
| 25 | Mock interview 1, 60 minutes, then fill the score sheet |
| 26 | Drill the two lowest rows on your own project |
| 27 | Mock interview 2 with a human; ask them to mark where they lost you |
| 28 | Review: compare the two score sheets and pick the last drills |
| 29 | Prepare questions for the interviewer; read the actual job post line by line |
| 30 | Light day: logistics, sleep, a 20-minute skim of your own numbers |
The run order, the score sheet and a mock interviewer prompt are in the mock interview script post. Use it unchanged on days 25 and 27 so the two sheets are comparable. For behavioural rounds specifically, the mock interviewer prompt post has prompts that tailor questions to your CV.
Why one project, and what makes it a good one?
Almost every question in the plan can be answered from the same project: retrieval choices (week 2), the eval set (week 2), cost and latency (week 3), failure modes (week 3), ownership (week 4). Two projects mean half the depth on each, and depth is what interviewers probe with follow-ups.
A good prep project has four properties, and you can check each in a minute:
- It has a number. At least one evaluation result you computed yourself.
- It has a failure. One thing that broke and what you did.
- It has a cost. A per-request or per-month figure with assumptions.
- It's yours. You can say what you decided, not what "we" did.
If your project has none of these, the fix is days 10, 11 and 18. For ideas on what to build, see AI portfolio projects that get interviews.
What does a 2-hour session look like?
A shape that works for most of the plan:
- 10 minutes: recall. Close everything and write down yesterday's topic from memory.
- 60 to 75 minutes: learn or build. One topic, one concrete artifact (a script, a table, an answer).
- 20 to 30 minutes: say it. Answer two questions aloud, recorded. Typed answers hide pacing and filler problems.
- 5 to 10 minutes: log. Write one line in the tracker below.
| Date | Day | What I produced | Weakest point | Fix tomorrow |
|---|---|---|---|---|
The tracker is for you, not for anyone else. The "weakest point" column is the one that earns attention: if the same word appears there three days running, move it into tomorrow's task.
What if you only have 14 days?
Cut by evidence, not by feel. Use the day-1 diagnostic: keep topics you scored 0 or 1, drop topics you scored 2.
| Keep (non-negotiable) | Cut or shrink first |
|---|---|
| Project running end to end | LoRA and QLoRA, unless the job post mentions fine-tuning |
| 20-question eval set and hit rate | Vector database internals beyond HNSW vs flat |
| One cost estimate | Python async, if you can already explain a semaphore |
| Timed system design, once | Separate latency day; fold it into the cost day |
| Two mock interviews and score sheets | Behavioural writing: do two stories instead of four |
If you can only keep two things, keep the eval numbers and the mock interviews. They are the two activities that turn reading into spoken answers.
What this plan does not cover
- Coding rounds and data structures. Add time for them separately.
- Take-home assignments. They reward a different habit (scoping and writing up), so practise one on its own with how to approach an AI take-home.
- Security questions. If the role touches agents with tools, add an evening on LLM security interview questions.
- Company-specific research. Day 29 covers reading the job post; it doesn't replace knowing the product.
- Salary and negotiation. I include no figures because I haven't read any primary source for them here.
- Your health. Day 30 is deliberately light. A tired candidate answers worse than an unprepared one who slept, so don't turn day 30 into a cram.
What I verified and what I didn't
I ran the plan script and pasted its output. The hour totals follow from my assumptions (2, 3 and 1 hours), so they say nothing about what any employer expects. I did not test the plan on candidates, I did not check any job post against it, and the day-1 thresholds are judgment calls. The linked posts are other pages on this site and were checked to exist on 2026-10-09; the MCP and RAG evaluation posts linked on days 12 and 16 are written to the same date.
