Career Transitions

    AI Engineer Interview Questions (2026): A Practitioner's Guide + 30-Question Bank

    Published August 7, 2026·14 min read

    TL;DR

    Across **390 live AI-engineer JDs** on **69 US company boards** (Dexity, July 2026), five clusters cover ~90% of loops: LLM/transformer basics, RAG, agents, prompt engineering & evals, and LLM system design. Evals now appear in **56%** of JDs and agents in **50%** — so most interviews are GenAI, not classical ML. This guide answers what the loop tests, then gives 30 real questions with concise model answers by topic and experience level, including the most-reported opener: "Design a RAG system for a customer support chatbot."

    Summarize with AIChatGPTClaude

    What do AI engineer interviews test in 2026?

    AI-engineer interviews in 2026 are mostly a GenAI test, not a classical-ML one. In Dexity's analysis of 390 live AI-engineer job descriptions across 69 US company boards (July 2026), LLMs appear in 63% of postings, Python in 59%, evals in 56%, and agents in 50% — and 60%+ of interview content is now GenAI (RAG, LLMs, prompt engineering, evals, agents). The loop runs screen → technical → system design → behavioral, and five topic clusters cover roughly 90% of what you'll be asked: LLM/transformer fundamentals, RAG architecture, agentic systems, prompt engineering & evals, and system design for LLM-backed products. If you can hold a real conversation across those five, you're prepared for most loops.

    💡The single biggest shift versus 2023-era loops: evaluation is now table stakes. With **evals in 56%** of JDs, "how do you know your LLM feature works?" is asked more often than "explain backpropagation." Interviewers want to hear about datasets, judges, and error analysis — not vibes.

    The data

    The interview-relevant skill frequencies, from Dexity's 390-JD analysis:

    Skill / topic % of JDs Maps to cluster
    LLMs 63% LLM/transformer fundamentals
    Python 59% Coding screen (all clusters)
    Evals 56% Prompt engineering & evals
    Agents 50% Agentic systems
    PyTorch 33% LLM fundamentals / fine-tuning
    RAG 26% RAG architecture
    Fine-tuning 26% LLM fundamentals
    AWS 20% System design
    TensorFlow 18% LLM fundamentals
    MLOps 17% System design
    Kubernetes 15% System design
    LangChain / LangGraph / LlamaIndex 10% Agents / RAG
    Vector DBs 7% RAG architecture

    How the question bank maps to experience level

    The same clusters show up at every level, but the depth changes. Use this to calibrate what a given answer needs to include:

    • Junior (0-2 yrs): Expect definitional and mechanism questions — "what is attention," "what is a vector embedding," "what does temperature do." You're being checked for correct mental models and clean Python. Depth of a single correct paragraph matters more than breadth.
    • Mid (2-5 yrs): Expect trade-off and debugging questions — "your RAG answers are wrong, how do you diagnose it," "when do you fine-tune vs. use RAG," "how do you evaluate a summarizer." You're being checked for judgment under real constraints (latency, cost, quality).
    • Senior (5+ yrs): Expect open-ended system design and ownership — "design a support chatbot for 10k tickets/day," "how do you roll out a prompt change safely," "how do you catch regressions in production." You're being checked for architecture, failure modes, evaluation strategy, and how you'd lead the build.
    ℹ️Questions below are grouped by topic cluster, then tagged with a rough level (J / M / S). No question is attributed to a specific company — candidate-reported banks like Adil Shamim's ["Every AI Engineer Interview Question... From 100+ Real Interviews"](https://adilshamim8.medium.com/every-ai-engineer-interview-question-you-need-to-know-in-2026-from-100-real-interviews-b5b7ae4b961a) and [UPenn Career Services' 45-question guide](https://careerservices.upenn.edu/blog/2026/06/25/45-ai-engineer-interview-questions-answers-2026-guide/) show the same topics recurring across many companies, which is why we organize by topic and tier.

    LLM & transformer fundamentals questions

    This cluster matters because LLMs appear in 63% of JDs — the highest of any skill — with fine-tuning at 26% and PyTorch at 33% riding alongside it. Expect these on the technical screen.

    1. What is the attention mechanism, and why did it replace recurrence? (J/M) Attention lets every token attend to every other token in the sequence via query-key-value dot products, producing a weighted sum of values. It replaced RNNs because it removes the sequential bottleneck — all positions are computed in parallel — and it captures long-range dependencies directly rather than passing state step by step. Self-attention is the core building block of the transformer.

    2. Why do transformers need positional encodings? (J/M) Attention is permutation-invariant: on its own it treats a sequence as a bag of tokens with no notion of order. Positional encodings (sinusoidal, learned, or rotary/RoPE) inject order information so the model can distinguish "dog bites man" from "man bites dog." Modern LLMs mostly use rotary embeddings because they generalize better to longer contexts.

    3. Explain the difference between a base model and an instruction-tuned model. (M) A base model is trained purely for next-token prediction on a large corpus; it completes text but doesn't reliably follow instructions. Instruction tuning (supervised fine-tuning on instruction-response pairs, often followed by preference optimization like RLHF or DPO) aligns the model to answer questions and follow directions. Most production apps call an instruction-tuned model, not the raw base.

    4. What is the context window, and what breaks when you exceed it? (J/M) The context window is the maximum number of tokens the model can attend to at once, covering both your prompt and its output. Exceed it and the request errors or silently truncates — usually dropping the earliest tokens, which is why long histories "forget" the start of a conversation. It's the hard constraint behind chunking, retrieval, and conversation summarization.

    5. When would you fine-tune a model instead of using RAG or prompting? (M/S) Fine-tuning is for teaching form and behavior — a consistent output format, tone, or a narrow classification skill — not for injecting fresh facts, which RAG handles better and more cheaply. Reach for it when prompting plateaus, you have a few hundred-plus high-quality examples, and the task is stable enough to justify the training/serving overhead. In practice, try prompting, then RAG, then fine-tuning, in that order.

    6. What causes hallucinations, and how do you reduce them? (M) LLMs are trained to produce fluent, plausible continuations, not to signal uncertainty, so they'll confidently fill gaps when they lack grounded information. You reduce them by grounding answers in retrieved context (RAG), instructing the model to say "I don't know" when context is insufficient, lowering temperature, and adding a verification or citation step. You can't fully eliminate them, so high-stakes flows need guardrails and evals.

    7. What does temperature do, and when do you lower it? (J) Temperature scales the logits before sampling: higher values flatten the distribution (more diverse, more creative, riskier) and lower values sharpen it (more deterministic and focused). Lower it toward 0 for extraction, classification, and tool-calling where you want stable, correct output; raise it for brainstorming or creative generation. It's often the first knob to check when output is erratic.

    RAG architecture questions

    RAG appears in 26% of JDs and vector DBs in 7%, and it underpins the most common system-design opener. Expect both mechanism and debugging questions here.

    8. Walk me through a basic RAG pipeline end to end. (J/M) Offline, you chunk your documents, embed each chunk, and store the vectors in an index. At query time you embed the user's question, retrieve the top-k nearest chunks, insert them into the prompt as context, and have the LLM answer grounded in that context. The two halves — retrieval quality and generation quality — fail independently, which is why you evaluate them separately.

    9. Why do we chunk documents, and what makes a good chunking strategy? (M) Chunking keeps each retrievable unit small enough to embed meaningfully and to fit many into the context window, while staying large enough to be self-contained. Good strategies respect structure (split on sections, paragraphs, or semantic boundaries rather than fixed character counts) and often add overlap so a concept isn't severed mid-idea. Chunk size is a tuning parameter you validate against retrieval metrics, not a fixed rule.

    10. What is the difference between semantic search and keyword search, and why combine them? (M) Keyword (lexical/BM25) search matches exact terms and excels at names, codes, and rare tokens; semantic (embedding) search matches meaning and handles paraphrase and synonymy. Each misses what the other catches — semantic search fumbles exact IDs, lexical search misses reworded questions. Hybrid retrieval runs both and fuses the results, which is why it's a common production default.

    11. Your RAG system gives a wrong answer. How do you debug it? (M/S) Split the problem: first check whether retrieval surfaced the right chunks — if the correct passage never made it into context, it's a retrieval problem (embeddings, chunking, k, or the index). If the right context was present but the model still answered wrong, it's a generation or prompt problem. This retrieval-vs-generation triage is the single most valuable habit in RAG debugging, and it's exactly what interviewers listen for.

    12. What is a reranker and when is it worth adding? (M/S) A reranker is a second-stage model (often a cross-encoder) that rescores the top candidates from initial retrieval by looking at the query and each chunk together, which is more accurate but too slow to run over the whole corpus. You retrieve a broad top-k cheaply, then rerank to a precise top-few for the prompt. Add it when retrieval recall is fine but precision is hurting answer quality.

    13. How do you evaluate a RAG system? (M/S) Evaluate retrieval and generation separately: for retrieval, measure whether the gold chunk appears in the top-k (recall/hit-rate, MRR); for generation, measure faithfulness (is the answer supported by the retrieved context?) and answer relevance. Build a labeled question set from real usage, and increasingly use an LLM judge for faithfulness at scale, validated against human labels. Track these on every change so you catch regressions.

    14. How do you keep a RAG index fresh as source documents change? (M/S) Treat ingestion as a pipeline: detect changed/added/deleted documents, re-chunk and re-embed only what changed, and upsert or delete the corresponding vectors so stale content doesn't linger. Version your embeddings so a model or chunking change triggers a controlled re-index rather than a silent mix of old and new vectors. For time-sensitive domains, add metadata (timestamps, source) and filter or boost on recency at query time.

    Agentic systems questions

    Agents now appear in 50% of JDs — half the market — with LangChain/LangGraph/LlamaIndex at 10%. Expect questions on tool use, control flow, and failure handling.

    15. What is an LLM agent, and how does it differ from a single prompt? (J/M) An agent uses an LLM to decide actions in a loop — choosing tools, calling them, observing results, and deciding the next step — rather than producing one answer in a single pass. The defining trait is control flow driven by the model plus external tools/memory, so it can break a goal into steps and react to intermediate results. A plain prompt has no loop, no tools, and no state.

    16. Explain tool calling / function calling. (J/M) You expose functions to the model with a schema (name, description, typed parameters); the model returns a structured request to call one with specific arguments, your code executes it, and you feed the result back for the model to continue. The model never runs code itself — it only proposes calls — so your application stays in control of execution and validation. Clear tool descriptions and strict argument schemas are what make it reliable.

    17. What is the ReAct pattern? (M) ReAct interleaves reasoning and acting: the model produces a thought, chooses an action (a tool call), observes the result, and repeats until it can answer. Externalizing intermediate reasoning and grounding each step in real tool output reduces blind hallucination and makes the trajectory inspectable. It's the conceptual backbone behind many agent frameworks.

    18. How do you stop an agent from looping forever or running up cost? (M/S) Bound it: cap the number of steps/tool calls, set a token or dollar budget per task, and add timeouts on tool calls. Detect repetition (same action and arguments repeating) and break out, and design a graceful "I couldn't complete this" terminal state rather than an infinite retry. In production you also log full trajectories so you can see where loops start.

    19. How do you handle a tool that fails or returns bad data mid-run? (M/S) Validate every tool output before feeding it back — schema-check it and treat external calls as untrusted — and on failure either retry with backoff, fall back to an alternate tool, or surface a controlled error into the agent's context so it can adapt. Never let a raw exception or malformed payload silently poison the next step. For multi-step tasks, make steps idempotent or checkpointed so a retry doesn't double-execute side effects.

    20. When should you NOT use an agent? (M/S) When a deterministic pipeline or a single well-structured prompt solves the task, use that — agents add latency, cost, and failure surface that only pay off when the path genuinely can't be known ahead of time. If you can enumerate the steps, hard-code them; reserve agentic control flow for open-ended tasks with branching decisions. "Simplest thing that works" is the senior answer here.

    Dexity Intel · free newsletter

    Liking this? Get the next one in your inbox.

    JD-backed career reads, AI market signals, and field-tested tool guides — a few times a month. No fluff, no spam.

    Prompt engineering & evaluation questions

    This is the highest-signal cluster after LLMs: evals appear in 56% of JDs. Interviewers increasingly weight "how do you know it works" over pure modeling.

    21. What is few-shot prompting and when does it help? (J) Few-shot prompting includes a handful of input-output examples in the prompt so the model infers the pattern and format you want. It helps most when the task is hard to specify in words but easy to demonstrate, or when you need a strict output shape. Beyond a few well-chosen examples returns diminish and you're just burning context, so quality of examples beats quantity.

    22. What is chain-of-thought prompting and what's the trade-off? (J/M) Chain-of-thought asks the model to reason step by step before answering, which improves accuracy on multi-step reasoning, math, and logic tasks. The trade-off is more tokens (higher latency and cost) and the fact that the visible "reasoning" is not a guaranteed faithful account of the computation. For simple tasks it's unnecessary overhead.

    23. How do you evaluate an LLM feature that has no single correct answer (e.g. a summarizer)? (M/S) Define quality along explicit dimensions — faithfulness, coverage, conciseness, tone — and score against them rather than chasing exact-match. Use a labeled reference set plus an LLM judge with a clear rubric for the subjective dimensions, and validate the judge against human ratings on a sample before trusting it. The goal is a repeatable score you can track across prompt and model changes.

    24. What is error analysis and why does it matter more than a single eval score? (M/S) Error analysis means reading actual failures, clustering them by root cause (retrieval miss, format error, hallucination, refusal), and quantifying which category hurts most — instead of staring at one aggregate number. It tells you what to fix next, which a scalar score never does. This is the workflow behind streamlining AI evaluation in production, and it's a strong senior signal.

    25. What is an LLM-as-judge, and what are its failure modes? (M/S) An LLM-as-judge uses a model to score or compare outputs against a rubric, which scales evaluation far past manual grading. Its failure modes are real: position bias (favoring the first option), verbosity bias (favoring longer answers), self-preference, and rubric drift. You mitigate by randomizing order, pinning a strict rubric, and periodically checking judge-vs-human agreement.

    26. How do you prevent prompt injection in a user-facing LLM app? (M/S) Treat all retrieved and user-supplied text as untrusted data, not instructions — separate the trusted system prompt from untrusted content, and don't give the model unrestricted tools over sensitive actions. Add input/output filtering, constrain tool permissions to least privilege, and require confirmation for high-impact actions. There's no single fix, so defense is layered; acknowledging that limitation is itself a good signal.

    27. How do you catch a prompt or model change that regresses quality before it ships? (M/S) Keep a versioned evaluation set that mirrors real traffic and run it automatically on every prompt/model change, gating the rollout on the results the way you'd gate on unit tests. Roll out behind a flag with an A/B or canary and monitor production quality signals so anything the offline set missed shows up small and reversible. The principle: no prompt change reaches all users without passing evals.

    System design for LLM products

    System design is a dedicated interview stage, and it leans on AWS (20%), MLOps (17%), and Kubernetes (15%) alongside the GenAI clusters. The most-reported opener lives here.

    28. Design a RAG system for a customer support chatbot. (M/S) — the most common opener This is the single most commonly reported system-design opener in 2026 AI-engineer loops. Don't jump to a diagram — structure it:

    1. Clarify requirements. Ticket volume and QPS, latency target, knowledge-base size and update frequency, languages, whether it answers or also takes actions (refunds, escalations), and the accuracy/safety bar for a support context.
    2. Ingestion. Pull from help center, past tickets, and docs; chunk with structure-aware splitting; embed and store in a vector index with metadata (product, date, source); build an incremental re-index job for updates.
    3. Retrieval. Hybrid (semantic + keyword) retrieval with metadata filters, top-k plus a reranker for precision; return citations so answers are traceable.
    4. Generation. Grounded prompt that instructs the model to answer only from retrieved context and to escalate/say "I don't know" when context is insufficient; low temperature; return sources.
    5. Actions & safety. If it takes actions, gate them behind tool calls with confirmation and guardrails against prompt injection from ticket text.
    6. Evaluation & monitoring. Offline eval set for retrieval recall and answer faithfulness; online monitoring of deflection rate, escalation rate, and thumbs-up/down; error analysis loop feeding fixes.
    7. Non-functionals. Caching for common questions, fallbacks when the LLM or vector store is down, cost controls, and a human-handoff path.

    Leading with clarifying questions and closing with evaluation is what separates a strong answer from a component list.

    29. How would you cut latency and cost in an LLM feature under load? (M/S) Cache aggressively — exact and semantic caching for repeated questions, plus prompt caching for stable system prompts — and route easy requests to a smaller/cheaper model, reserving the frontier model for hard ones. Trim context to what retrieval actually needs, stream responses to improve perceived latency, and batch where possible. Measure first: profile the real bottleneck before optimizing.

    30. How do you monitor an LLM product in production? (M/S) Instrument both system metrics (latency, error rate, token usage/cost) and quality signals (user feedback, escalation/deflection rates, and sampled LLM-judge scores on live traffic). Log full traces — prompt, retrieved context, tool calls, and output — so you can reproduce and do error analysis on failures. Alert on drift in quality metrics, not just uptime, because an LLM feature can be "up" and quietly wrong.

    How to prepare

    • Build one real thing end to end. A RAG or agent project you can explain — including how you evaluated it — is worth more than a hundred flashcards, because every cluster above shows up in it.
    • Prepare the RAG opener cold. Rehearse "design a RAG system for a customer support chatbot" out loud with the clarify → ingest → retrieve → generate → evaluate structure until it's automatic.
    • Practice retrieval-vs-generation triage and error analysis, since debugging and evaluation questions are where mid/senior candidates separate themselves.
    • Keep Python sharp. It's in 59% of JDs; the coding screen still expects clean, correct code, often gluing together retrieval, prompts, and tool calls.
    • Say "I don't know" well. In evals, safety, and hallucination questions, acknowledging real limitations and layered mitigations reads as senior — overclaiming reads as junior.
    • Cross-check your bank against real reports. Adil Shamim's 100+-interview compilation and UPenn's 45-question guide confirm the same clusters recur across companies.

    Frequently asked questions

    What are the most common AI engineer interview questions in 2026?

    They cluster into five topics that cover ~90% of loops: LLM/transformer fundamentals, RAG architecture, agentic systems, prompt engineering & evals, and system design for LLM products. The most-reported single system-design opener is "design a RAG system for a customer support chatbot." Within Dexity's 390-JD dataset, LLMs (63%), evals (56%), and agents (50%) are the highest-signal areas.

    Do AI engineer interviews still test classical machine learning?

    Less than they used to. Dexity's data shows 60%+ of interview content is now GenAI — RAG, LLMs, prompt engineering, evals, and agents — though classical ML fundamentals still appear via PyTorch (33%) and TensorFlow (18%), mostly around fine-tuning and model basics. Prioritize the GenAI clusters, but don't be unable to explain overfitting or a train/test split.

    How much coding is in an AI engineer interview?

    Enough that you can't skip it: Python appears in 59% of JDs, second only to LLMs. The technical screen typically involves practical coding — often wiring up retrieval, prompts, or a tool-calling loop — rather than heavy competitive-programming puzzles. Clean, correct, readable code matters more than exotic algorithms.

    What is the interview loop for an AI engineer role?

    The common structure is screen → technical → system design → behavioral. The screen filters basics, the technical round goes deep on the GenAI clusters and coding, system design centers on LLM-backed products (frequently the RAG chatbot opener), and behavioral covers ownership and collaboration. Expect evaluation and debugging questions woven throughout the middle rounds.

    How do I answer "design a RAG system" in an interview?

    Start with clarifying questions (volume, latency, knowledge-base size and freshness, safety bar), then walk ingestion → retrieval → generation → actions/safety → evaluation → non-functionals. Explicitly separate retrieval quality from generation quality, and finish on how you'd evaluate and monitor it. Leading with requirements and closing with evals is what distinguishes a strong answer.

    What separates a junior from a senior answer?

    Juniors are graded on correct mental models and clean code; seniors are graded on trade-offs, failure modes, and evaluation strategy. On any question, a senior names the constraints (latency, cost, safety), the simplest approach that works, and how they'd know it's working in production. Acknowledging real limitations reads as senior; overclaiming reads as junior.


    Prep for it. The five clusters reward structured thinking under real constraints — exactly what you can drill. Systems Thinking for Tech Interviews walks you through clarifying, structuring, and evaluating open-ended design questions like the RAG chatbot opener.

    Sources: Dexity proprietary analysis of 390 live AI-engineer JDs across 69 US company boards, July 2026 (https://dexity.com/intel/ai-engineer-career-path-2026); Adil Shamim, "Every AI Engineer Interview Question You Need to Know in 2026 — From 100+ Real Interviews" (https://adilshamim8.medium.com/every-ai-engineer-interview-question-you-need-to-know-in-2026-from-100-real-interviews-b5b7ae4b961a); UPenn Career Services, "45 AI Engineer Interview Questions & Answers (2026 Guide)" (https://careerservices.upenn.edu/blog/2026/06/25/45-ai-engineer-interview-questions-answers-2026-guide/).

    Go from reading to doing · Dexity Sprint

    Systems Thinking for Tech Interviews

    Software engineers often struggle to demonstrate systems thinking during high-pressure tech interviews. This sprint equips you to decompose complex problems, make informed trade-offs, and design robust systems for scale and failure.

    5 Weeks
    Live instruction
    3 Projects
    Real deliverables
    30 Seats
    Per cohort, capped
    Alex Martinez
    Alex Martinez
    Principal Engineer · Atlassian
    Explore the sprint
    Anmol Gulwani

    Anmol Gulwani

    Dexity

    Connect on LinkedIn
    Questions or suggestions?hello@dexity.com