AI Engineer Interview Questions with the follow-ups and how to answer them.

Seventeen questions from the 2026 AI engineer loop, in seven clusters: RAG, agents, evals, production and inference, the fine-tuning decision, prompt engineering, and LLM fundamentals. Each one comes with what it really tests, the follow-up probes you will get, and a framework for the answer.

Predict my AI engineer questions →Run an AI engineer mock →

Interviewing for an AI engineer role? Paste the posting and Calibrd predicts the questions for that exact role and level. Your first mock is free.

01

Why AI engineer interviews look different

The loop in 2026

AI engineers sit at #1 on LinkedIn's list of fastest-growing tech jobs for 2026, and the interview looks nothing like a classic software loop. There is less whiteboard coding and more conversation: interviewers want to hear how you think about systems that behave well in production. Retrieval that finds the right context. Agents that stop instead of looping. Evals that catch regressions before users do. Inference that stays cheap at scale.

The two designs that come up in most loops: inference at scale, and an agent or RAG system under a cost cap. Everything below is organized around the clusters interviewers actually probe: RAG, agents, evals, production, the fine-tuning decision, prompt engineering, and LLM fundamentals. Each question comes with what it really tests, the follow-ups you'll get, and a framework for answering.

02

The questions

The full bank, with what each one tests

RAG

01Documents change daily. How do you keep the index fresh without re-embedding everything?

What they're really asking

Incremental indexing, versioning, and invalidation in a production pipeline.

Follow-ups you'll get

  • How do you handle deleted documents?
  • A chunk's source changed; how do you know which answers are now stale?

Answer framework

  1. Change detection at ingest (hashes, timestamps).
  2. Versioned chunks with source lineage.
  3. Tombstones for deletes.
  4. Re-embed only what changed, and flag answers built on superseded chunks.

02Your RAG system answers confidently and wrong. Debug it out loud.

What they're really asking

Structured debugging, and whether you separate retrieval failure from generation failure.

Follow-ups you'll get

  • What do you log to tell the two apart?
  • The retrieved chunks look right but the answer is still wrong, now what?
  • How do you stop this regressing next month?

Answer framework

  1. Check what was retrieved first: citations or it didn't happen.
  2. If retrieval is right, the problem is grounding, so tighten the prompt, require quotes, lower the temperature.
  3. If retrieval is wrong, fix chunking or the query, add query rewriting.
  4. Add the failing case to a golden eval set so it can't come back.

03How do you keep p99 latency under two seconds on a RAG pipeline?

What they're really asking

Production trade-offs under a latency budget.

Follow-ups you'll get

  • What do you cut first when the budget is blown?
  • How do you stream partial results without misleading the user?

Answer framework

  1. Budget the pipeline stage by stage (retrieval, rerank, generation).
  2. Shrink the expensive stage first (smaller reranker, fewer chunks, cached embeddings).
  3. Stream tokens early so perceived latency drops.
  4. Precompute and cache for repeated queries.

Agents

01Design a research agent that reads the web and writes a report with sources.

What they're really asking

Planning decomposition, source trust, and cost bounding on an open-ended task.

Follow-ups you'll get

  • How do you stop it citing garbage sources?
  • The report costs $4 in tokens; how do you get it under $1?
  • How do you run five searches in parallel safely?

Answer framework

  1. Decompose into search, read, and synthesize with a planner.
  2. Source scoring with an allowlist; every claim needs a cited source.
  3. Budget per report: max steps, model routing (cheap model for skimming, strong model for synthesis).
  4. Parallel tool calls with a join step.

02How do you evaluate an agent?

What they're really asking

Whether you know task success is not a vibe, and how you measure multi-step behavior.

Follow-ups you'll get

  • What's wrong with grading agents with another LLM?
  • How do you test the failure paths, not just the happy path?

Answer framework

  1. Task success rate in a sandbox with scripted tools.
  2. Trajectory checks: steps taken, tool calls made, cost per task.
  3. LLM-as-judge only with human calibration and known blind spots.
  4. Red-team the tools: timeouts, bad data, adversarial users.

03Traces show your agent takes 40 tool calls for a task that should take 5. What do you do?

What they're really asking

Efficiency debugging from observability data.

Follow-ups you'll get

  • How do you tell a planning failure from a tool failure in the trace?
  • What guardrail would have caught this before the user noticed?

Answer framework

  1. Read the trace: repeated calls mean the planner is stuck; failing calls mean a tool problem.
  2. Fix the loop: better tool descriptions, stop conditions, max steps.
  3. Add the trajectory to your evals.
  4. Alert on steps-per-task like a latency metric.

89% of teams now run some agent observability, 94% among those with agents in production (1,340 respondents). LangChain, State of Agent Engineering

04When do you use MCP, and when do you build custom tools?

What they're really asking

Whether you follow the ecosystem or reason about integration trade-offs.

Follow-ups you'll get

  • What does MCP buy you that a REST wrapper doesn't?
  • When is it the wrong choice?

Answer framework

  1. MCP for standard interop: one server, many clients, less glue code.
  2. Custom tools when you need tight control over auth, latency, or side effects.
  3. The real question is always who owns the failure when the tool breaks.

Evals

01Design the LLM-as-judge for your eval pipeline. How do you know the judge is any good?

What they're really asking

Judge design and calibration, not just "we use an LLM to grade".

Follow-ups you'll get

  • What biases do LLM judges have?
  • How much human labeling is enough to trust it?
  • The judge disagrees with humans on 20% of cases, now what?

Answer framework

  1. Rubric-based judging with examples, not vibes.
  2. Measure agreement with humans and study where it diverges.
  3. Known biases (verbosity, position, self-preference) and their mitigations.
  4. The judge is a tool with its own eval, re-calibrated on every prompt or model change.

02How do you measure hallucinations?

What they're really asking

Whether you can make "makes things up" measurable.

Follow-ups you'll get

  • Faithfulness vs factuality, what's the difference?
  • How do you evaluate when there's no single right answer?

Answer framework

  1. Separate faithfulness to sources from factuality against the world.
  2. Citation checks: every claim traceable to retrieved context.
  3. Adversarial inputs designed to tempt invention.
  4. Human eval on a sample, because some failures only a reader catches.

Production and inference

01Design inference serving for 1,000 requests per second.

What they're really asking

Whether you understand what actually costs money and time at scale. One of the two designs that come up in most loops.

Follow-ups you'll get

  • Where does the KV cache bite you?
  • When do you quantize, and what do you lose?
  • How do you estimate cost per 1,000 requests?

Answer framework

  1. Continuous batching first; it beats naive batching on real traffic.
  2. KV cache math: context length times users is your memory bill.
  3. Quantization (FP8/INT8) for throughput, measured against your evals for the quality hit.
  4. Route by difficulty: small model for easy, large for hard.

02How do you roll out a new model version without breaking production?

What they're really asking

Deployment discipline for a component whose behavior you can't fully specify.

Follow-ups you'll get

  • The new model scores higher offline but users complain. What happened?
  • How do you roll back a model?

Answer framework

  1. Eval gate: the new version must beat the old on your golden set before it sees traffic.
  2. Shadow, then canary: compare live outputs before users depend on them.
  3. Version pinning and instant rollback, because "the model changed" is a real incident cause.
  4. Monitor behavior drift, not just latency and errors.

03Your token bill tripled overnight. What do you check?

What they're really asking

Cost governance, the unglamorous half of AI engineering.

Follow-ups you'll get

  • How do you attribute cost per feature?
  • What stops a runaway agent from spending $10k?

Answer framework

  1. Per-request logging with feature and user attribution, so you know who spent it.
  2. The usual suspects: max tokens raised, caching disabled, a looped agent.
  3. Structural fixes: prompt caching, smaller models for easy calls, budgets and kill switches per agent.
  4. Alert on cost like you alert on latency.

Fine-tuning vs prompting vs RAG

01A task needs better quality. Do you fine-tune, improve the prompt, or add RAG?

What they're really asking

The central decision framework of applied AI work.

Follow-ups you'll get

  • How much data do you need before fine-tuning beats prompting?
  • How do you know the fine-tune didn't break something else?

Answer framework

  1. Prompt first: the cheapest experiment, and it fixes instruction-following.
  2. RAG when the model lacks the knowledge.
  3. Fine-tune for style, format, and domain behavior, with enough data to beat the prompt baseline.
  4. Regression evals on everything the model already did, because fine-tuning moves the whole surface.

Prompt engineering

01How do you approach prompt engineering for a production feature?

What they're really asking

Whether you treat prompts as code or as vibes.

Follow-ups you'll get

  • How do you test a prompt change?
  • How do you handle prompt injection in a user-facing product?

Answer framework

  1. Prompts are code: versioned, reviewed, tested.
  2. A prompt eval set that runs on every edit.
  3. Structure: system instructions, context, task, format, separated and labeled.
  4. Treat user input as untrusted; injection is a security question, not a prompt question.

LLM fundamentals

01What breaks as context windows get longer?

What they're really asking

Whether you understand attention costs or just quote the context size on the box.

Follow-ups you'll get

  • How does the KV cache grow with context?
  • What does "needle in a haystack" actually test?

Answer framework

  1. Attention is roughly quadratic in practice and memory is the wall.
  2. Long context dilutes: retrieval quality inside the window degrades.
  3. Test with needle-in-haystack at your real context lengths.
  4. Often the fix is better retrieval, not a bigger window.

02The model must pick one of 200 categories and explain why. How do you make that reliable?

What they're really asking

Constrained output at scale.

Follow-ups you'll get

  • What breaks when the category list grows to 2,000?
  • How do you evaluate the explanations, not just the labels?

Answer framework

  1. Constrain decoding to the category set, or retrieve candidate categories first, then classify.
  2. Validate the output is in-set and retry with the error.
  3. Keep explanations short and checkable.
  4. Eval on the rare categories, not just the common ones.

03How do you reduce hallucinations in production?

What they're really asking

The layered defense, not a single trick.

Follow-ups you'll get

  • When do you let the model say "I don't know"?

Answer framework

  1. Ground it: RAG with citations, so claims are checkable.
  2. Constrain it: structured output, narrow task scope.
  3. Verify it: second-pass checks on high-stakes answers.
  4. Abstention is a feature. "I don't know" beats a confident lie, and you should eval for it.

These are the generic ones. Paste the actual posting and Calibrd predicts the questions that posting will ask for this exact role and level.

03

How to drill this bank

How to use this page
  1. 01Answer out loud, not in your head. Every question here is asked spoken; reading the framework is not the same as saying it.
  2. 02Take the probes seriously. The follow-ups are where interviews are won and lost. Practice the question, then the probe.
  3. 03Rotate clusters. Don't drill RAG five times in a row; real loops jump between clusters.
  4. 04Time the two designs. Inference at scale and the agent/RAG under a cost cap are whiteboard questions; practice them in 15 minutes with the trade-offs stated.
  5. 05Then make it about you: paste the posting and get the questions that posting will ask. Predict my AI engineer questions →
  6. 06Run a mock before the real one. Spoken answers, follow-up probes, coached on the spot. Your first mock is free. Run an AI engineer mock →

The loop itself, the levels, the pay bands and how candidates get rejected are in the AI engineer interview prep guide. For research and training roles, see the research engineer and machine learning engineer guides.

04

FAQ & sources

The short answers
What is an AI engineer interview like?

Mostly conversation, not coding. Expect scenario questions ("design a RAG system", "your agent loops in production, why") with follow-up probes on trade-offs, cost, latency, and evals. Some loops add a coding round, but the core signal is system judgment.

How is this different from a machine learning interview?

ML interviews test modeling fundamentals (training, regularization, metrics). AI engineer interviews test building with models: retrieval, agents, evals, inference, cost. Applied judgment over theory.

Do I need ML fundamentals, or is LLM experience enough?

For most applied AI engineer roles, shipped LLM work (RAG, agents, evals) matters more than theory. Research and training-focused roles are the exception and will say so in the posting.

What should I build before interviewing?

One RAG pipeline or one agent, with tracing and a small eval set. It gives you real answers to the debugging and eval questions, which are the ones candidates most often fake.

Should I use the resume review or the free job scan?

This page covers the general bank. The free scan reads your specific posting and returns the questions for that exact role and level, a pay benchmark matched to the role and, with your CV, a read on the gaps an interviewer will probe. No posting yet? The free resume review reads the CV on its own.

Walk in ready

Walk into your AI engineer interview ready.

Paste your actual posting and Calibrd predicts what that company asks for this role, where your CV is thin, and what it should pay. Then rehearse the round out loud with honest feedback until you're confident. Free to start.

Free to start · No card · Encrypted at rest, never used to train AI, remove anytime

AI Engineer Interview Questions (2026) — Calibrd