AI Engineer Interview Questions (2026): 13 Worked Answers

Key Takeaways

• AI engineer interviews in 2026 test whether you can build and operate LLM features: retrieval, evals, tool calling, cost, security and a practical coding round, with some ML theory on top.
• The same question changes depending on who asks it. Labs probe internals, startups probe shipping speed, big tech probes scale and rubrics, and enterprise teams probe permissions and cost control.
• Google says its process takes roughly 6-8 weeks and does not permit AI tools in its interviews. Anthropic says no AI assistance in live interviews unless it says otherwise.
• This guide answers 13 questions with a short worked outline and one follow-up each. Twelve of them are the free-sample questions from our interview kit and one is new.
• Every technical claim links to official documentation. Where a detail comes only from candidate reports, we leave it out; which topics come up most often is our editorial judgment.

AI engineer interview questions in 2026 mostly ask you to reason about a working LLM system: why a RAG answer is wrong, how a tool call executes, what a chatbot costs per month, how to keep a model from being tricked. Expect a mix of concept questions, a system design round, a practical coding exercise and behavioral questions about projects you shipped. Below are 13 of them with the answer shape that interviewers tend to reward.

We tag each question two ways. Level is junior, mid or senior: the depth where a good answer starts. Seen at is the kind of company where the question fits best: AI labs, AI-native startups, big tech, or enterprise and non-tech employers. Those tags are our editorial judgment, built from the kit we sell, not data published by any company. Treat them as a way to decide what to practice first.

How AI Engineer Interviews Work in 2026

There is no single format. What the companies publish is thin, and most round-by-round breakdowns online come from candidate reports. Here is what is on the record.

What the company pages say

• Anthropic: its careers page says all interviews are conducted over Google Meet, technical interviews use live coding tools such as Colab and CodeSignal, and non-technical interviews are conversational (Anthropic careers).
• Anthropic and AI help: its candidate AI guidance says live interviews are "This is all you–no AI assistance unless we indicate otherwise," and take-homes should be done without Claude unless told otherwise. It does allow using Claude to refine an application draft you wrote yourself.
• Google: its how we hire page says the process typically takes roughly 6-8 weeks, may start with a hiring assessment or a coding exercise, and then moves to a panel of interviews over video or in person. Candidates are assessed against clear rubrics, there are no brainteasers, and AI tools are not permitted in interviews.

OpenAI also publishes an interview guide, but we could not read it reliably, so we do not quote it. The loop lengths and round counts you see for OpenAI and Anthropic on prep sites are candidate-reported; Anthropic does not publish its stages. If a number matters to you, check the company page the week you apply.

The rounds you can plan for

Across companies the rounds fall into the same few buckets. This is our synthesis, not an official format.

In our reading, labs tend to keep some algorithmic coding in the mix. Applied teams at startups and enterprises lean on the practical round instead, because the job is wiring models into products. If your target is a coding-heavy loop where AI rules differ by company, read our guide on coding interviews in the age of AI.

AI Engineer Interview Questions and Answers: 12 From the Free Sample

Each answer below is an outline you could deliver in two to three minutes. Interviewers care less about the exact wording than about whether you hit the structure and can handle the follow-up.

Fundamentals and evals

1. What is a token, and why does tokenization matter in practice?

Level: junior. Seen at: AI labs, AI-native startups, big tech, enterprise.

What it tests: Whether you can connect tokenization to cost, limits and odd model behaviour instead of reciting a definition.

A token is the chunk of text the model actually reads and writes, usually a word piece rather than a whole word. OpenAI's docs give the English rule of thumb as about 4 characters, or 0.75 words, per token (OpenAI concepts).

• Cost: providers bill per token, and input and output are priced separately.
• Limits: your prompt plus the output must fit the context window, so token count, not character count, is the budget.
• Weird behaviour: models see tokens, not letters, so character-level tasks like counting letters or reversing strings go wrong, and non-English text often costs more tokens for the same meaning.

Close with the practical habit: measure tokens with the provider's tokenizer rather than estimating when it matters.

Follow-up: If the same document costs twice as many tokens in another language, what changes in your cost model and your chunking?

2. Why can't you test an LLM feature the way you unit-test ordinary code?

Level: junior. Seen at: AI labs, AI-native startups, big tech, enterprise.

What it tests: Understanding that outputs are non-deterministic and open-ended, and what replaces exact-match assertions.

A unit test asserts that one input gives one exact output. An LLM can phrase a correct answer many ways, and the same prompt can return different text on different calls. An exact-match assertion would be flaky and would also fail good answers.

What replaces it is an eval set: a fixed collection of realistic inputs with a way to score each output. Scoring can be a deterministic check (valid JSON, contains the required field), a reference comparison, or a model grading against a rubric. You then track a pass rate over the whole set, and you run it whenever the prompt, model or retrieval changes. Keep ordinary unit tests for everything around the model: parsing, routing, permissions.

Follow-up: You change one sentence in the prompt and the eval pass rate moves from 84% to 86%. Do you ship it?

Retrieval and cost

3. Your RAG assistant gives fluent, confident answers that are wrong. How do you find out whether retrieval or generation is at fault?

Level: mid. Seen at: AI-native startups, big tech, enterprise.

What it tests: Whether you split the pipeline into measurable stages instead of tweaking the prompt.

Take a set of failing questions and, for each one, look at what was retrieved before looking at what was generated.

1. Was the right passage retrieved? Find the document that contains the answer by hand, then check whether it appears in the top results. If not, the fault is retrieval: chunking, embeddings, query phrasing or missing hybrid search.
2. If it was retrieved, was it used? Give the model only the correct passage. If it still answers wrongly, the fault is generation: prompt, instruction ordering, too much noise around the passage.
3. Count it. Report retrieval hit rate and answer correctness separately, so the next change is aimed at the weaker stage.

A retrieved-but-ignored passage and a never-retrieved passage need completely different fixes, and that is the point the question is probing.

Follow-up: The retrieved passages contradict each other because some documents are outdated. What do you do?

4. Walk me through estimating the monthly model cost of a support chatbot.

Level: junior. Seen at: AI-native startups, big tech, enterprise.

What it tests: Building a cost model from first principles, with input and output tokens priced separately.

State the formula before any numbers:

monthly cost = conversations x turns x (input_tokens x input_price + output_tokens x output_price)

Then fill in the parts people forget. Input tokens per turn are not just the user message: they include the system prompt, retrieved passages, tool definitions and the whole conversation history, which gets re-sent every turn, so cost grows faster than linearly with conversation length. Output tokens are usually fewer but priced higher per token. Add retries, an eval or judge model if you run one, and embedding costs for retrieval.

Use a price from the provider's current pricing page, say it is an assumption, and give a range for volume. Then name the levers: shorter prompts, caching the stable prefix, a smaller model for easy turns, capping history.

Follow-up: Traffic doubles but the bill triples. What are the first three things you check?

Tools, prompts and design

5. How does tool calling work, from the model's point of view and from your application's?

Level: junior. Seen at: AI labs, AI-native startups, big tech, enterprise.

What it tests: Knowing that the model only proposes calls and your application executes them.

The model never runs anything. OpenAI's function calling guide describes a five-step loop (OpenAI function calling):

1. Send a request that includes the tools the model may call.
2. Receive a tool call from the model.
3. Run the code in your application with the arguments from that call.
4. Send a second request containing the tool output.
5. Receive the final answer, or more tool calls, and repeat.

Anthropic's API works the same way: the response has stop_reason: "tool_use" with tool_use blocks, and your code sends back a tool_result (Anthropic tool use). The consequence worth saying out loud: because your code executes the call, validation, permissions and limits on the loop are your responsibility.

Follow-up: The model returns arguments that do not match your schema. What do you do, and which API setting reduces the problem?

6. What goes into a good system prompt for a production feature?

Level: junior. Seen at: AI-native startups, big tech, enterprise.

What it tests: Structure and specificity rather than clever wording.

Think of it as a spec, not a spell. A solid production prompt has:

• the role and the task in one or two plain sentences;
• the inputs it will receive and how they are delimited, so untrusted text is clearly separate from instructions;
• the exact output format, ideally enforced by structured output rather than described in prose;
• what to do when information is missing or the request is out of scope;
• a few examples where the format or tone is hard to describe.

Then say the part that distinguishes a production answer: the prompt lives in version control, has an eval set behind it, and changes only when the eval says the change helps.

Follow-up: The model ignores one of your instructions. How do you debug it?

7. How do you structure your answer in an LLM system design interview?

Level: mid. Seen at: AI-native startups, big tech, enterprise.

What it tests: A repeatable framework that covers the AI-specific concerns, not only boxes and arrows.

Use the normal system design order, and add the parts that are specific to models:

1. Clarify: users, volume, latency target, what a wrong answer costs.
2. Baseline: the simplest pipeline that could work, drawn end to end.
3. Data and retrieval: sources, chunking, freshness, permissions.
4. Model choice and routing: which model for which step, and why.
5. Evals: how you know it works before launch and after changes.
6. Failure and safety: provider outages, bad output, prompt injection, cost spikes.
7. Cost and scale: tokens per request, caching, what breaks at 10x.

Most weak answers stop at step 3. Spending the last third of the time on evals and failure modes is what reads as experience.

Follow-up: Your model provider has an outage in the middle of your design. How should the system behave?

8. Tell me about an AI project you built. What would you do differently?

Level: junior. Seen at: AI labs, AI-native startups, big tech, enterprise.

What it tests: Depth of ownership and honest reflection, not how novel the project was.

Pick one project you can go deep on and use a simple arc: the problem and who had it, what you built, one decision you made and the alternative you rejected, how you measured whether it worked, and what failed.

The "do differently" part carries the answer. Concrete beats modest: "I started with fine-tuning before I had an eval set, so I could not tell if it helped; I would build the eval first." Avoid listing frameworks. If you built something with a coding agent, say what you checked yourself.

Follow-up: What would the first version have looked like if you had one week instead of one month?

Choosing techniques and staying safe

9. How do you decide between prompting, retrieval and fine-tuning for a new feature?

Level: junior. Seen at: AI-native startups, big tech, enterprise.

What it tests: Knowing what each technique changes and picking the cheapest one that solves the actual problem.

Match the technique to the type of failure:

Go in that order because each step costs more to build and maintain. Fine-tuning changes behaviour, it is a poor way to add changing knowledge. Whatever you pick, have the eval set first so you can show the cheaper option was or was not enough.

Follow-up: After fine-tuning, your target metric rose but users say the model got worse at other things. What happened?

10. What is prompt injection, and how is it different from a jailbreak?

Level: junior. Seen at: AI-native startups, big tech, enterprise.

What it tests: Clear definitions, and why indirect injection matters for real applications.

OWASP defines prompt injection as user prompts altering the model's behaviour or output in unintended ways (OWASP LLM01). A jailbreak is a form of it: input crafted to make the model ignore its safety rules. Jailbreaking targets the model's built-in guardrails; prompt injection more broadly targets your application's instructions.

The case that matters in production is indirect injection: the malicious text is not typed by the user but sits in a web page, email or document the model reads, and it may steer an agent that has tools. OWASP's mitigations include least privilege for tools and tokens, deterministic validation of output, separating and labelling untrusted content, human approval for high-risk actions, and adversarial testing, and it says no method is fully foolproof. So the senior answer is to limit what a compromised model can do, not to promise detection.

Follow-up: An agent reads a user's email and can send messages. Design the defences.

11. How does a vision-language model "see" an image, and what does that imply for cost and accuracy?

Level: junior. Seen at: AI-native startups, big tech, enterprise.

What it tests: A working mental model of images as tokens.

The image is cut into patches, each patch is turned into an embedding, and those become tokens the model processes alongside text. So an image is not free and not fixed-cost: bigger images mean more tokens, until the provider resizes them.

Anthropic documents the arithmetic: an image costs ceil(width / 28) x ceil(height / 28) visual tokens, with a cap that depends on model tier, and it resizes images that are too large. A 1000 x 1000 image comes to 1,296 tokens by that formula (Anthropic vision docs). OpenAI also counts patches, with different sizes and multipliers by model (OpenAI images guide). Accuracy implication: downscaling to save tokens can erase small text, so test on your real images.

Follow-up: Users upload phone photos of receipts and you must extract line items. What would you downscale, and what would you test?

Live coding

12. In a live coding round, implement a function that calls an LLM API and returns parsed JSON. What would you make sure to handle?

Level: junior. Seen at: AI-native startups, big tech.

What it tests: Production instincts around a simple model call: errors, retries, validation.

Write the happy path in two minutes, then spend the rest of the time on what can go wrong, and say each one aloud:

• Timeouts: set one explicitly; the default may be none.
• Transport and rate-limit errors: retry the retryable ones with backoff (question 13 shows how).
• Malformed output: the response may not be valid JSON, may be wrapped in text, or may be truncated. Use structured output if the API offers it, still parse inside a try block, and validate against a schema.
• Bounded repair: one retry that feeds the validation error back to the model, then fail loudly.
• Secrets and logging: key from the environment, no raw user data in logs.

Write one test with a fake client that returns bad JSON first and good JSON second.

Follow-up: The JSON is valid but a required field is a plausible-looking guess. How would you catch that?

A Question Not in the Kit: Handling 429s and Timeouts

Rate limits are a frequent production topic in applied AI interviews, in our experience, and they come up as a coding question, a design question and a debugging question. This is the one we expect to be asked and rarely see answered properly in prep lists.

13. Design the client wrapper that calls an LLM API. How do you handle 429s and timeouts?

Level: junior to mid. Seen at: AI-native startups, big tech, enterprise.

What it tests: Whether you know which failures are retryable, how to back off without causing a retry storm, and when to stop.

Start with what a 429 means. OpenAI returns it when a request exceeds a temporary rate limit, measured in requests and tokens per minute, among others (OpenAI rate limits). Anthropic limits requests, input tokens and output tokens per minute using a token bucket, so even a short burst can trigger a 429 when your average is under the limit (Anthropic rate limits).

The design rules:

1. Honor Retry-After. Both providers say to wait at least that long; OpenAI adds a small random delay on top. If the header is missing, fall back to exponential backoff with jitter.
2. Add jitter. Without it, many clients that failed together retry together.
3. Cap everything: maximum attempts, maximum single wait, and a total deadline so a user-facing request does not hang for minutes.
4. Retry only what can succeed. Timeouts, 429s and 5xx errors are candidates. Bad requests and auth errors are not. Anthropic documents a 429 for hitting a monthly spend cap that has no retry-after and keeps failing until access resumes, so treat it as terminal.
5. Shape the load, not just the retries. A client-side limiter or queue keeps you under the limit in the first place, and prompt caching can reduce counted input tokens on Anthropic.
6. Make retries safe. A timed-out request may still have run. For calls with side effects, use an idempotency key or retry only the model call, not the side effect.

A compact version we ran against simulated failures:

import random
import time


class Timeout(Exception):
    pass


RETRYABLE = {408, 429, 500, 502, 503, 504, 529}


def call_with_retry(send, max_attempts=5, base=0.5, cap=30.0, deadline=60.0,
                    sleep=time.sleep, now=time.monotonic):
    start = now()
    for attempt in range(max_attempts):
        try:
            resp = send()
        except Timeout:
            resp = None
        if resp is not None:
            if resp["status"] < 400:
                return resp
            if resp["status"] not in RETRYABLE or resp.get("code") == "enforced_spend_limit_reached":
                raise RuntimeError(f"not retryable: {resp['status']}")
        if attempt == max_attempts - 1:
            break
        wait = min(cap, base * 2 ** attempt)
        retry_after = (resp or {}).get("headers", {}).get("retry-after")
        if retry_after is not None:
            wait = max(wait, float(retry_after))
        wait += random.uniform(0, base)
        if now() - start + wait > deadline:
            break
        sleep(wait)
    raise RuntimeError("gave up")

In our test run a 429 with retry-after: 2 followed by a timeout and then a success waited about 2.1 and 1.3 seconds, and the spend-cap error stopped immediately. Production code would also log each retry, emit a metric, and use the provider SDK's built-in retries rather than stacking a second layer on top of them.

Follow-up: You have 50 workers and one shared rate limit. Where does the limiter live, and what happens when a deploy restarts every worker at once?

More AI Engineer Interview Questions by Topic

These are other questions from the 120 in the kit, listed here without answers. Use them as a self-test: if you cannot give a two-minute answer to a topic, that is where to study. The kit has a full answer, a follow-up and a note on what each question tests.

RAG and retrieval

• How do you choose a chunk size, and what goes wrong at each extreme?
• What does a reranker add, and what does it cost?
• Documents in the corpus have different access permissions. How do you make sure the assistant never answers from a document the user can't see?

Evals

• You have a new LLM feature and no eval set. How do you build one?
• How do you make an LLM-as-judge grader trustworthy?
• How do you get reliably structured output (JSON) from a model, and how do you test it?

Inference and cost

• What is prompt caching and when does it help?
• Your LLM feature's p99 latency is ten times its median. How do you investigate?

Agents and tools

• How do you stop an agent from looping forever or running up a large bill?
• What is the Model Context Protocol (MCP), and what problem does it solve?
• The agent has 60 tools and keeps picking the wrong one. What do you do?

System design and security

• Design a code-review assistant that comments on pull requests.
• Why should you treat model output as untrusted input, and where does that matter in code?

The full set, with answers and follow-ups, is in the AI Engineer Interview Kit.

How to Prepare by Level

The same topics appear at every level, but what counts as a good answer shifts.

Whatever the level, rehearse speaking, not reading. Rounds are live, and some companies say outright that you work without AI help. For the rest of the loop, our interview prep hub and the interview readiness checklist cover the non-AI parts. If you are weighing the job market and pay for these roles, see our software engineer job market and salary breakdowns, and will AI replace software engineers for the bigger picture.

How We Built This List

The 12 sample questions are one per chapter of our kit. Level and company-type tags are our judgment and may not match what a given employer asks. Company process facts come only from pages we read on October 31, 2026: Anthropic's careers and candidate guidance pages and Google's how we hire page. Technical facts link to official documentation, which changes without dates, so verify limits and prices on the provider page before an interview. We left out round counts, loop lengths and "real interview" statistics that we could not trace to a company or a primary source.

FAQ

What are the most common AI engineer interview questions?

Building a RAG system and finding out why it gives wrong answers is, in our judgment, the most common theme, followed by evals, tool calling and agents, cost and latency, prompt injection, and a practical coding task such as calling an LLM API and parsing the JSON. Behavioral questions about an AI project you shipped are nearly universal.

What do AI engineer interviews cover in 2026?

Typically concepts (tokens, embeddings, fine-tuning trade-offs), a practical coding round, a system design round for a RAG or agent product, and behavioral questions. Applied roles weight production topics such as evals, cost and security; research-leaning roles weight model internals.

How long is an AI engineer interview process?

It depends on the company. Google says its process takes roughly 6-8 weeks and includes some mix of assessments, recruiter conversations and a panel of interviews. Anthropic does not publish stage counts, and OpenAI's loop length is only reported by candidates, so check each company's page.

Can you use AI tools in an AI engineer interview?

Not unless the company says so. Google says AI tools are not permitted in its interviews, and Anthropic says live interviews are without AI assistance unless it indicates otherwise. Some other companies run formats that allow AI, so read the instructions you are sent.

Do AI engineer interviews include coding?

Yes, but the form varies. Expect a practical exercise like calling an LLM API, validating structured output or building a small tool loop, and at some companies a conventional algorithm round as well. Anthropic names Colab and CodeSignal as its live coding tools.

Where can I get AI engineer interview questions and answers as a PDF?

The free AI Engineer Interview Kit sample contains 12 questions with full answers and follow-ups, one from each chapter of the kit.

Further Reading

• Anthropic careers: how we hire: interview format and tools.
• Anthropic candidate AI guidance: when AI help is and is not allowed.
• Google: how we hire: process length, rubrics and AI policy.
• OpenAI rate limits guide: 429s, backoff and jitter.
• Anthropic rate limits: token bucket and retry-after.
• OWASP LLM01: prompt injection: definition and mitigations.