How interviews test this subject

Why it matters

By 2026 the AI engineer loop has settled into a shape, and practitioner guides describe the same five rounds from company to company. Knowing the shape means preparing for what is asked instead of for everything. It also exposes the one thread that runs through every round: the interviewer wants to know whether you can tell if the thing works. Candidates who can build a demo are common; candidates who end every answer with a measurement get offers.

The idea

Five rounds, in roughly this order, with the system design round carrying the most weight for mid and senior candidates.

Coding with practical LLM tasks

Not a puzzle round. The tasks are the plumbing of an LLM product: wrap a flaky API call in retry with exponential backoff and jitter, and know which status codes to retry; split a document into chunks of a target token size with overlap; compute top-k cosine similarity between a query vector and a few thousand stored vectors; parse a streaming response; validate a tool call against its schema. Each tells the interviewer whether you have touched the pieces or only read about them.

ML fundamentals

Lighter than for a machine learning engineer, but present. Bias and variance, overfitting and the train, validation and test split, precision and recall and why accuracy misleads on imbalanced data, what an embedding is and how one is trained, what fine-tuning changes in the weights and what it cannot change. The purpose is to check that "the model is 94 percent accurate" means something to you.

LLM and GenAI depth

The round that decides whether you are an AI engineer or a developer who has called an API. The questions repeat across guides: RAG versus fine-tuning and when each is right; the failure points of a RAG pipeline from ingestion to answer; chunking strategies and what chunk size trades off; why models hallucinate and the first mitigations; evaluation metrics such as faithfulness, context precision and context recall; how agents and tool calling work and when to stop a loop; long context versus retrieval; and the cost and latency levers of caching, routing and output caps. Every one of these has a lesson in this track.

System design for AI applications

Forty-five minutes, one prompt, and the same handful of prompts recur: document Q&A over a corpus; a meeting-booking agent with calendar tools; a support assistant that must never leak PII; a code-review assistant; and the diagnostic variant, a RAG system users rate badly, find out why. The shape is requirements first, then the pipeline, then the failure modes, then measurement and cost. The AI interview playbook module has a blueprint for each.

Behavioural

Ownership of a shipped AI feature and what went wrong with it, a time an eval disagreed with users and which you trusted, a disagreement about whether a model was the right tool at all. The strongest stories carry a number and a decision.

The thread

Evaluation runs through all five. The coding round asks how you would test the chunker. The depth round asks which metric would show a retrieval regression. The design round ends, if you let it, with "how would you know it got better?" The behavioural round asks what you measured. A strong answer in any round finishes with how you would measure, before the interviewer asks.

	Junior	Mid	Senior
Coding round	Backoff, chunking and top-k from memory, with tests	The same, plus streaming and schema validation under a time limit	The same, plus the cost and latency of what you wrote
Depth round	Define RAG, hallucination, tool calling, one metric each	Failure points of a pipeline and the fix for each	Trade long context against retrieval and fine-tuning with numbers
Design round	A working naive pipeline with its boxes named	Failure modes, guardrails and an eval plan	Eval-first framing, cost per request, cross-layer trade-offs, rollout
The measure question	Name a golden set and one metric	Pick the metric that matches the failure	Design the eval before the system and gate release on it

Using this track for the loop

Each lesson ends with an In an interview section: the quotable sentence, how deep to go at each Fit level, and the follow-ups to expect. The drills at the end of every module are the design round in miniature: a scenario with numbers, answered out loud before the model answer is revealed, then graded on mechanism, numbers and measurement. For the design round itself, take the playbook blueprints with a timer and a blank page; the point is to produce the drawing and the measurement in forty-five minutes, not to recognise them.

Trade-offs

Loops vary. A small company may compress everything into a coding round and a design round; a lab may add a paper discussion. Preparing round by round risks rehearsing scripts, and interviewers push off-script on purpose; the only defence is understanding the mechanism well enough to improvise. The other trap is claiming measurements you have not made. An interviewer who hears "our faithfulness score was 0.9" will ask how it was computed, on how many examples, and what changed it.

In an interview

The sentence that works in every round: "Before I change chunk size I want a golden set of fifty real questions and a recall number, because every other decision moves that number." At junior depth, know the five rounds, be able to write the three coding tasks, and define the depth-round terms. At mid depth, carry the failure points and their fixes, and bring an eval plan to the design round unasked. At senior depth, open the design round with requirements and the eval, give a cost per request, and trade across layers. Expect "how would you know it got better?", "what does a request cost?" and "what happens when the tool call fails?" in every loop.