The AI engineer interview
An AI engineer interview is usually a software engineering loop with the model treated as one unreliable dependency. The common shape is four to five rounds: a practical coding session, an AI system design round, a project deep dive on something you shipped, a behavioral round, and sometimes a separate evaluation and reliability conversation. The distinguishing skill being tested is production judgment about probabilistic components, not model theory.
This guide covers product-facing and backend-oriented AI engineering roles. If the posting emphasises serving, retrieval internals, or agent orchestration, the LLM engineer and agentic AI guides are closer fits.
What companies mean by AI engineer
In most postings, AI engineer describes a software engineer who builds product features on top of models they did not train. The day job is integration, data plumbing, prompt and retrieval design, evaluation, latency and cost work, and the operational side of shipping something non-deterministic to users.
That shapes the loop. Interviewers are generally not checking whether you can derive attention or explain gradient descent. They are checking whether you can build a system that stays correct, affordable, and debuggable when one of its components is occasionally and confidently wrong.
The practical consequence is that ordinary engineering rigour carries most of the weight. Candidates who are strong on API design, data flow, caching, timeouts, observability, and testing tend to do well, provided they can also talk credibly about evaluation.
What to expect: the usual loop
A representative loop for a mid-to-senior AI engineer role. Yours may be shorter. The ordering varies more than the content.
| Round | Typical length | What it tests |
|---|---|---|
| Recruiter screen | 25 min | Level fit and logistics. Ask here for the names and formats of every subsequent round. |
| Practical coding | 45–60 min | Working in unfamiliar code, adding a test, debugging out loud. Sometimes with an AI assistant permitted. |
| AI system design | 45–60 min | End-to-end design of a model-backed feature: data in, retrieval, serving, evaluation, failure handling, cost. |
| Project deep dive | 45–60 min | One thing you actually built, pushed until the interviewer finds the edge of your involvement. |
| Behavioral | 45 min | Ownership, disagreement, and how you made a call under ambiguity at the claimed level. |
| Evals & reliability | 45 min, often folded into design | How you would know the feature works, and what you would gate a release on. |
What to ask your recruiter
Before you prepare anything, send one short email: how many rounds, what each one is called, how long each runs, whether any of them is a take-home, and whether an AI assistant is allowed in the coding round. Recruiters answer this routinely. Anything they confirm outranks every pattern on this page, because it is first-party evidence about your loop rather than a general tendency across companies.
What interviewers are testing
Named signals rather than topics. Most feedback forms in this kind of loop reduce to some version of these.
- Production judgment about a probabilistic component
- Knowing that a model call is a network dependency with a variable-quality response, and designing timeouts, fallbacks, and degraded modes accordingly.
- Evaluation instinct
- Reaching for an eval set and a metric unprompted, rather than waiting to be asked how you would measure quality.
- Data flow clarity
- Being precise about where user data goes, what is logged, what is sent to a third-party provider, and what must not be.
- Cost and latency literacy
- Token budgets, caching layers, model sizing, streaming, and being able to name what dominates your p95.
- Knowing when not to use a model
- Rules, lookups, and deterministic logic are often the correct answer. Reaching for a model every time reads as inexperience.
- Ordinary engineering rigour
- Interfaces, idempotency, retries, backpressure, observability. These still decide the design round.
Question themes that recur
These are categories of question, not a list of questions anyone is guaranteed to ask. Prepare the reasoning, not a script.
- Design a feature that answers questions over company documents
- A retrieval question in disguise. The interesting part is what happens when the top results are irrelevant, and how you would detect that in production.
- This feature is too slow and too expensive. What do you change first?
- Tests whether you profile before optimising, and whether you know which of prompt size, model choice, retrieval, or round trips dominates.
- How would you know a change to the prompt made things better?
- An evaluation question. A named eval set, a task metric, and a regression gate is the answer; "we tried it and it looked better" is not.
- Walk me through an AI feature you shipped
- The deep dive opener. Interviewers follow the thread to whatever you are least comfortable with, usually measurement or failure handling.
- What breaks when the provider has an outage?
- Availability design: fallbacks, cached responses, queueing, and what the user is told.
- Where should this not use a model at all?
- Scoping judgment. Strong candidates volunteer this before being prompted.
Study now, review, skip
For a generalist AI engineer loop with no confirmed round names. Confirmed information from your recruiter beats this allocation.
- One shipped system you can draw end to end in five minutes.
- One evaluation story with baseline, metric, failure found, change, result.
- Failure handling: timeouts, fallbacks, partial results, user-visible degradation.
- Your p95 latency and cost per request for one real system.
- Retrieval basics: chunking, embeddings, hybrid search, reranking.
- Caching strategies and where they are safe with non-deterministic output.
- Standard system design: queues, idempotency, rate limits, backpressure.
- Transformer internals and attention derivations.
- Fine-tuning recipes, unless the posting names training work.
- Benchmark leaderboards and model release trivia.
Common failure modes
- Spending the design round on the prompt. Prompt text is a detail inside the design, not the design.
- No answer to "how would you know it works?" beyond manual spot checks.
- Treating the model call as infallible: no timeout, no fallback, no degraded path.
- Claiming numbers that collapse under one follow-up question. Say you do not remember instead.
- Describing a team's system in the first person during the deep dive. Interviewers detect this almost immediately.
- Ignoring the data boundary: what gets logged, and what is sent to a third-party provider.
A three-day plan
For the common case: the loop is this week and you cannot prepare everything.
Day 1 — Your evidence
- Write and draw one shipped AI system end to end. Rehearse it to five minutes.
- Reconstruct your real numbers, or decide honestly which ones you do not have.
- List two production failures you personally debugged, and how they were detected.
Day 2 — Design and evaluation
- Run two design prompts out loud, finishing each with evaluation and failure handling rather than stopping at the architecture.
- Write your default metric ladder: offline eval set, shadow traffic, small online test, guardrail metric.
- Prepare the trade-off you would make first under a hard latency budget, and why.
Day 3 — Coding and pressure
- One 45-minute session on an unfamiliar repository: reproduce an issue, write a test, fix it.
- Have someone push on your deep dive until they find the edge. Practise saying "I do not know" cleanly.
- Prepare your questions for them, including how they evaluate model changes today.
Common questions
- Do AI engineer interviews include LeetCode-style questions?
- Some do and some do not, and the split varies by company rather than by title. Many teams have moved to a practical session in a real repository. Your recruiter can confirm the format, and that answer should decide how you spend your coding preparation.
- How much machine learning theory do I need?
- For most AI engineer postings, enough to reason about what a model can and cannot be relied on to do, and enough to design an evaluation. Deriving architectures is rarely the signal in this loop, though it is in research roles.
- What is the difference between the AI system design round and a normal system design round?
- The fundamentals are identical. What is added is a component with variable output quality, a token-based cost model, and a measurement problem that has no single correct answer. The distributed systems content does not go away.
- I have not shipped an AI feature. Can I still pass?
- Often yes, if you can transfer credible production judgment from other systems and are honest about the gap. Inventing an AI project is the worse option — deep dives are specifically designed to find the edge of real involvement.
Related interview guides
- LLM engineer interview: rounds and prep
Serving, retrieval, agents, evaluation, and the latency and cost judgment this title is screened on.
- AI system design interview: framework and prep
A reusable framework for designing systems where a model is one dependency among many.
- The AI-assisted coding interview, decoded
Allowed, required, or banned — and what each variant is scored on.
- AI interview prep: the 2026 guide
The hub. Every role guide and round guide on this site, and how to decide which ones apply to your loop.
How every ranking on this site is reasoned about, including what counts as evidence: read the methodology.
Map your actual interview.
This page is the general pattern. Paste the job you are actually interviewing for and the wording your recruiter used, and the map ranks the rounds you are likely to face, explains why each is ranked where it is, and tells you what to skip.
See a complete Full Interview Map example