The Ultimate AI Engineer Interview Playbook

AI engineering interviews have changed faster than the advice about them. A lot of preparation material still assumes you'll be asked to derive backpropagation by hand or explain the bias-variance tradeoff for twenty minutes. Some teams still do that. Most have moved on, because the job has moved on: companies are hiring people who can ship systems that use models, not people who can recite how models work.

Here is what the loop actually looks like now, and what each round is really measuring.

Round 1: The screen — can you explain your own work?

A recruiter or hiring manager walks through your resume. This round is almost entirely about whether your projects are real. Interviewers have read hundreds of resumes claiming "built an LLM-powered chatbot," and they have learned to find the bottom of that claim in about four minutes.

The tell is always specificity. Candidates who actually built the thing know why they chose a 800-token chunk size, what broke when they didn't, and what the latency was. Candidates who followed a tutorial know that they "used LangChain." Prepare by writing down, for every project on your resume: what the hardest decision was, what you tried first that failed, and what you'd do differently now.

Round 2: Coding — Python, data manipulation, and one algorithm

This is less brutal than a pure software-engineering loop. You will rarely be asked to invert a binary tree. You will very often be asked to manipulate data competently under mild time pressure: parse a messy file, reshape a dataframe, deduplicate records, compute a metric grouped by a key.

• Be genuinely fluent in Python — comprehensions, generators, dictionaries, and the standard library.
• Know pandas well enough that you don't fight it: groupby, merge, pivot, and handling missing values.
• Expect one classic algorithm question, usually easy-to-medium. Arrays, hashmaps, and strings dominate.
• Write code that runs. A working brute-force solution beats an elegant broken one, every single time.

Round 3: ML fundamentals — narrower than you fear, deeper than you hope

You do not need to derive the transformer attention equation from scratch. You do need to reason about models the way an engineer reasons about a system: what breaks, why, and how you'd know. The questions that separate candidates are almost always diagnostic rather than definitional.

Weak questions ask "what is overfitting?" Strong questions ask "your model gets 99% training accuracy and 60% test accuracy — walk me through what you check, in order." Prepare for the second kind.

• Your model performs well offline and badly in production. What are the candidate explanations, and how do you distinguish them?
• Your dataset is 98% one class. What does accuracy tell you, and what would you measure instead?
• Why might a model that was fine last quarter be degrading now, with no code change?
• When would you not use a deep learning model for a problem?

Round 4: LLM and GenAI depth — the round that's new

This is the round that didn't exist three years ago and now often decides the offer. It tests whether you have built with language models or only used them.

Questions you should be able to answer cold

• When do you choose RAG over fine-tuning, and when is neither the right answer?
• The model is hallucinating in production. Give me four distinct causes and how you'd rule each one out.
• How do you evaluate a system whose output is free-form text and has no single correct answer?
• What is the context window actually costing you — in latency, in money, and in accuracy?
• How would you stop a customer-facing agent from taking a destructive action?

That last question increasingly matters. As agentic systems move into production, teams are acutely aware that a model with tool access can do real damage. Candidates who have thought about guardrails, human-in-the-loop approval, and blast-radius limits stand out sharply from those who have only chained prompts together.

Round 5: System design — the highest-leverage round

"Design a system that answers customer questions from our documentation." "Design a recommendation service for 10 million users." This round has the widest scoring spread of any, which means it's where preparation pays the most.

The mistake nearly every candidate makes is starting with the model. Strong candidates start with the problem and spend the first several minutes refusing to design anything:

1. Clarify the requirement. Who uses this? How many? How fast must it respond? What is the cost of a wrong answer?
2. Define success before architecture. What metric tells you this works? How will you measure it in production, not just offline?
3. Sketch the data path first — where does data come from, how does it get processed, where does it live.
4. Only now, choose the model. And justify why a simpler approach wouldn't do.
5. Design for failure. What happens when the model is down, slow, or wrong? What's the fallback?
6. Close the loop. How do you monitor, retrain, and roll back?

How to talk about your projects

Every project story should carry four things, in this order: the problem, the constraint, the decision, and the number. "We needed to answer support questions from our docs. The docs changed weekly, so fine-tuning was out. I built a RAG pipeline with a nightly re-index. It cut escalations to a human by about a third."

That is thirty seconds and it demonstrates problem framing, tradeoff reasoning, technical execution, and business impact. Compare it to "I built a chatbot using LangChain and OpenAI," which demonstrates that you have heard of LangChain.

The uncomfortable truth about preparation

You cannot cram your way through the LLM depth round or the system design round. Both test judgment, and judgment only comes from having built things and watched them break. The candidates who clear these loops are, almost without exception, the ones with a portfolio of real systems they can speak about honestly — including the parts that went wrong.

Which means the most effective interview preparation isn't interview preparation. It's shipping something real, breaking it, and fixing it.