AI Engineer Interview Prep: Rounds, Questions and Study Plan

They prepare for the coding round and stop there. An AI engineer interview also asks why a model answers the way it does, and how you would prove your feature works.

Picture a common setup. A backend engineer has spent three years writing Python services that move money between shop owners and banks. The setup is made up, but the problem is real. They apply for two AI engineer roles and clear both coding rounds easily.

Then an interviewer asks why the model gave two different answers to the same question. The candidate guesses, and guesses wrong. The next question is how they would know whether a RAG answer is correct.

RAG, short for retrieval-augmented generation, means the system first fetches matching documents, then lets the model answer from them. The candidate had built one, but had never measured it. Both companies say no.

The next target is a team building an invoice assistant. It answers small shop owners' questions about their GST (goods and services tax) invoices. This guide follows the preparation for that loop, round by round.

An AI engineer interview is a set of rounds that checks whether you can build useful products on top of existing AI models. It tests coding, model basics, system design, a real build and how you work with people.

An AI engineer is a software engineer who builds features on top of ready-made models. The daily work is prompts, search over company data, tool calls, testing and keeping costs in check. An ML (machine learning) engineer usually trains and tunes the models themselves.

The line is blurry, and job titles vary between companies. Read the job description. Words like training and research point to an ML role; words like product, RAG and evaluation point to AI engineering.

Loops vary, but their rounds come from six kinds: a recruiter screen, coding, LLM fundamentals, GenAI system design, a take-home build and a behavioural round. The grouping is ours; companies merge, skip or reorder rounds.

GenAI means generative AI, models that write text, images or code. An LLM, or large language model, is the kind that reads and writes text. A loop is the full set of rounds for one job.

Think of state-level football selection trials. Players move between stations: a fitness test, ball control drills, a short match and a talk with the coach. Map it part by part:

• Each station is one round.
• Each selector is one interviewer, who watches one skill and writes feedback alone.
• The panel that meets at the end is the hiring committee, the group that reads all the feedback and decides.
• Brilliant dribbling cannot be counted on to rescue a failed fitness test. A great coding round cannot be counted on to rescue a blank fundamentals round either.

Where the picture breaks: trials only watch you, while an interview is a conversation. You can ask questions, and good ones count in your favour.

Here is the loop for the invoice assistant role. The onsite is the final block of rounds, held on one day.

The table sums up each round in one line before the sections below.

The recruiter screen is a short call that checks basic fit before engineers spend time on you. Expect questions about your experience, why you want AI work, your notice period and your salary expectations.

The recruiter also wants to know which kind of AI engineer you are. Some roles build product features on top of model services; others sit closer to research and train models. The candidate says plainly that they build products.

Prepare a 60-second pitch with three parts. First, three years of Python payment services. Second, the one AI project you built, with a number from its evaluation. Third, why this team's problem interests you.

Use the call to ask about the loop:

• Which rounds are in the loop, and in what order?
• Is there a take-home, and how many hours is it meant to take?
• May I use an AI coding assistant in the coding round?
• Which language should I code in?
• What does the team build today, and who uses it?

AI engineer coding rounds often mix classic DSA problems with practical Python tasks close to AI work. DSA means data structures and algorithms: arrays, hash maps, trees, graphs and the patterns for solving problems with them.

The classic half looks like any software interview: hash maps, sliding windows, heaps for the top few items and simple graph searches. Ask the recruiter what difficulty to expect, because it varies by company.

The practical half is where AI roles differ. Two words help here. A token is a small piece of text the model reads, often a whole word or part of one. A vector is a list of numbers that stands for a piece of text.

• Split a long document into chunks of a fixed size that overlap a little, so a phrase cut at the edge still appears whole somewhere.
• Call a flaky service with retries, waiting longer after each failure. Add a little randomness, called jitter, so many clients do not all retry at the same moment.
• Given a list of vectors, return the 3 closest to a query vector by cosine similarity, a score of how closely two vectors point the same way.
• Parse messy JSON from a model's reply, and fall back safely when a field is missing.
• Count tokens roughly and trim a prompt so it fits a size limit.

Here is an answer to the first task. A chunk is one small piece of a document. The overlap repeats the last few words of one chunk at the start of the next one. The last two lines are a check you can run.

def chunk_words(text, size=200, overlap=40):
    if overlap >= size:
        raise ValueError("overlap must be smaller than size")
    words = text.split()
    step = size - overlap
    chunks = []
    for start in range(0, len(words), step):
        chunks.append(" ".join(words[start:start + size]))
        if start + size >= len(words):
            break
    return chunks


print(chunk_words("w1 w2 w3 w4 w5 w6 w7 w8 w9 w10", size=4, overlap=1))
print(chunk_words(""))

Run it with python3 and you should see exactly this:

['w1 w2 w3 w4', 'w4 w5 w6 w7', 'w7 w8 w9 w10']
[]

What just happened? Each chunk starts 3 words after the previous one, because the step is size minus overlap. The words w4 and w7 each appear in two chunks. Empty text gives an empty list.

Two lines matter most. The check at the top rejects an overlap as large as the chunk, because the step would then be zero or less. Without the break, this run would add a fourth chunk holding only w10.

Know what the overlap buys you. Any phrase of up to overlap plus 1 words that crosses a chunk edge appears whole in the next chunk. With the defaults, that is 41 words, and a brute-force check over every phrase confirmed it.

The follow-up is the real test: what if a chunk cuts a sentence in half? A good answer counts tokens rather than words, because model limits are in tokens, and prefers to cut at sentence or paragraph boundaries.

Some companies now run a coding round where you use an AI coding assistant. In June 2025, Canva's engineering blog said it expects backend, machine learning and frontend candidates to use AI tools in technical interviews. Its new AI-assisted coding round, piloted for backend and frontend roles, checks whether candidates can find and fix problems in AI-written code.

That round has its own tactics, so see our guide on preparing for the AI-assisted coding interview.

The fundamentals round checks whether you understand what a model does, so you can predict where it fails. Expect short spoken questions on tokens, context windows, embeddings, sampling, RAG, fine-tuning and evaluation.

An LLM is trained on huge amounts of text to predict the next token. The design behind today's widely used LLMs is the Transformer, from a 2017 paper called Attention Is All You Need. You do not need its maths.

You should explain attention in one plain sentence. In a model that writes text, attention lets each token look back at the tokens before it and weigh which ones matter. The paper's decoder, the part that writes, blocks each position from seeing later ones.

Here are the question types to practise, each with what a good answer must contain.

• Tokens: why do model services charge by tokens? Text is split into pieces, often whole words or parts of words, and both price and size limits count those pieces.
• Context window: what happens when a chat grows past it? The context window is the most tokens a model can handle in one request. Past it, you must cut old turns, summarise them or fetch only what is needed.
• Sampling: why can one prompt give two different answers? The model scores every possible next token, then picks one at random, weighted by those scores. A setting called temperature makes that choice sharper or flatter.
• Embeddings: what is an embedding? It is a vector that captures meaning, so texts with similar meanings land close together and search can find them.
• RAG or fine-tuning: when would you choose each? RAG brings in facts at question time. Fine-tuning, further training on your own examples, changes the model itself.
• Hallucination: why does a model state false things confidently? It writes likely text, not checked text. Retrieval, citations and checks in code reduce the risk.
• Evaluation: how do you know a prompt change helped? Run a fixed set of test questions before and after, compare the results question by question, and read the failures.
• Safety: what is prompt injection? It is text in a user message or a document that tries to override your instructions.

Some of these answers have well-known roots. The 2020 paper that named RAG paired a trained model with a searchable vector index of Wikipedia. A 2023 study found RAG beat fine-tuning on raw text at teaching a model facts, both familiar and new.

OWASP, a non-profit that publishes security guidance, lists prompt injection first, as LLM01, in its Top 10 for LLM applications. As of 19 October 2026, the current list is the 2025 edition.

For the sampling question, give two sentences, then an example. For an invoice total, do not lean on temperature at all. Read the total from the invoice data in code, and let the model only phrase the reply.

For a deeper base, see our guide on how LLMs work.

In a GenAI system design round, you design a full AI feature out loud, from user needs to quality checks, cost and safety. It looks like a classic design round, but the hard parts are retrieval, model choice and evaluation.

The practice question matches the target team's product: design an assistant that answers shop owners' questions about their own GST invoices, for 20,000 shops. Interviewers score how you clarify the problem, what you trade off and how you measure quality.

Cover six areas:

• Requirements: who asks, what they ask, how fast replies must be, and how much a wrong answer hurts.
• Data: where invoices come from, how their text is read, and how they are stored for each shop.
• Retrieval: how the system finds the right invoices before the model writes anything.
• Model choice: a small, cheap model for easy questions, and a larger one only when needed.
• Evaluation: a test set of real questions with known answers, run before every change.
• Cost and safety: rough cost per question, a spending cap, and a guard against instructions hidden in invoice text.

Do the rough maths out loud. Say each shop asks 5 questions a day (made up). That is 100,000 questions a day, about 1.2 a second on average, or about 2.8 a second if they all arrive in 10 working hours.

At 3,000 tokens per question for the chunks, the question and the answer (made up), that is 300 million tokens a day. Multiply by your provider's price per million tokens, and you have a daily bill to cap.

One point earns extra credit. A shop must never see another shop's invoices. Filter by shop in code, before the model sees any text, so no prompt can talk its way past the filter.

This guide stops at what the round checks. For a full 45-minute answer plan and a worked sample question, see our guide on the GenAI system design interview.

You do well in a take-home by shipping a small working feature with an evaluation set, clear limits and a README that explains your choices. The evaluation set is a fixed list of test questions with known answers.

The made-up brief for the invoice role is simple. Build a tool that answers questions about 50 sample invoices. You get five days, and the brief asks for no more than 8 hours. That time box is part of the test.

Here is the shape of a strong submission. Notice the evaluation script and the cost log at the bottom. They are what turn a demo into an engineering submission.

Work through the brief in five steps, in this order.

1. 1

   Read the brief twice

   Note the inputs, the time box and what to submit. If something is truly unclear, ask one short question on day one.

2. 2

   Build the simplest version that works

   Get one question answered from start to finish on the first day, even if the answer is rough. A working thin version beats a half-built clever one.

3. 3

   Write the evaluation set

   Write 30 questions with known answers, such as an invoice total or a GST number. Score the simple version before changing anything.

4. 4

   Improve one thing at a time

   Change one part, such as chunk size, then run the evaluation again. Note which questions each change fixed and which it broke.

5. 5

   Write the README

   Cover how to run it, why you chose each part, cost per question, known failures, and what you would do with another week.

Here is the core of the evaluation script. Each case holds a question and a value the answer must contain. The answer_question argument is the function that runs the whole tool on one question.

def run_eval(cases, answer_question):
    passed = 0
    failures = []
    for case in cases:
        reply = answer_question(case["question"])
        if case["must_include"].lower() in reply.lower():
            passed += 1
        else:
            failures.append(case["question"])
    print(f"{passed}/{len(cases)} passed")
    return failures

To check it, feed it three cases and a fake tool that gets one date wrong. It prints 2/3 passed and returns the date question, the one to read first.

Checking for a known value is exact and cheap, with one trap. A plain contains check also passes a reply of 14,820 when the answer is 4,820. Match whole values, or parse the number and compare.

Some answers need judgement, not an exact match. For those, teams sometimes use a second model as a judge. In a 2023 study, the strongest judge model agreed with human preferences over 80% of the time, about as often as humans agreed with each other.

The same study found judges can favour the answer shown first, longer answers and answers written by themselves. Name these biases in your README; it shows you know the limits of your own tests.

Answer behavioural questions with short, true stories in the STAR shape: Situation, Task, Action, Result. The University of Washington's career centre suggests spending about 60% of your answer on the Action, the part you did yourself.

It puts the rest at about 20% Situation, 10% Task and 10% Result. Behavioural rounds check how you work with people, make decisions and handle mistakes.

AI roles add themes of their own, because models fail in new ways. Prepare for these:

• Tell me about a time something you built gave wrong results to users.
• Tell me about a time you decided not to use AI for a problem.
• Describe a disagreement with a product manager about scope or a deadline.
• Tell me about a time you had to learn a new tool quickly.
• How did you decide a feature was safe enough to launch?

The candidate's failure story comes from payments work. A matching job they wrote linked some refunds to the wrong shop for two days. They found it through a support ticket, fixed it and added a daily check that compares totals.

That one story answers failure, quality and ownership questions. Keep the Action part specific: what you checked, what you changed and how you knew it worked.

Some interviewers ask how you think about AI risk. A simple anchor is the NIST AI Risk Management Framework, a voluntary guide that NIST, a US standards body, released in January 2023. Its core has four functions: Govern, Map, Measure and Manage.

As of 19 October 2026, NIST's page says version 1.0 is being revised. Do not recite the framework. Check that your stories show owning a risk, spotting it, measuring it and acting on it.

Spend the first four weeks on skills and the last four on proof: a project, design practice and mock rounds. At about 10 hours a week, that is 80 hours, which fits around a full-time job.

Back to the selection trials: players train for every station, with extra time on their weakest one. For the candidate, the weak station is fundamentals, so it gets two full weeks.

1. 1

   Week 1: Python and DSA warm-up

   Arrays, strings and hash maps. Two problems a day, written in clean Python with clear names.

2. 2

   Week 2: DSA patterns and practical tasks

   Sliding window, heaps and graph search. Add the practical tasks: chunking, retries with waits, and parsing messy JSON.

3. 3

   Week 3: LLM basics

   Tokens, context windows, attention in plain words, sampling and temperature. Say each answer out loud in under a minute.

4. 4

   Week 4: RAG and evaluation

   Embeddings, retrieval, fine-tuning versus RAG, hallucination and prompt injection. Build a tiny RAG over 20 documents and score it.

5. 5

   Week 5: One project, end to end

   Grow the tiny RAG into a portfolio project with an evaluation set, a cost log and an honest README.

6. 6

   Week 6: GenAI system design

   Practise four design questions out loud, with a timer. Do rough cost and speed maths in every one.

7. 7

   Week 7: Stories and the pitch

   Write five STAR stories and map each to several questions. Polish the 60-second pitch for the recruiter screen.

8. 8

   Week 8: Mock loop and rest

   Ask a friend to run a full mock loop. Spend the last days fixing your weakest round, then rest before the real one.

A loop is a set of separate checks, so one unprepared round can sink it. Each interviewer judges one skill, and the others cannot vouch for a skill they did not see.

These mistakes leave that kind of gap:

• Jumping to the model before asking what the user needs.
• Naming tools and products instead of explaining the idea underneath them.
• Having no way to measure quality, in the design round or the take-home.
• Ignoring cost and latency, which means how long one request takes to answer.
• Overclaiming project work. Interviewers ask follow-up questions until the gap shows.
• Treating the behavioural round as small talk, with vague stories and no results.

Temperature divides the model's raw scores, called logits, before they become probabilities. A low temperature sharpens the choice toward the top token; a high one flattens it.

The same formula appears as equation 1 of a 2015 paper on distilling large models into small ones. The code below is that formula and nothing more.

Here is a toy version. Assume the model has scored three candidate next tokens for an invoice total whose true value is 4,820. Real tokenisers may split a number into several tokens; this example keeps one token each.

import math

def next_token_probs(scores, temperature):
    scaled = [s / temperature for s in scores]
    top = max(scaled)
    weights = [math.exp(s - top) for s in scaled]
    total = sum(weights)
    return [w / total for w in weights]

tokens = ["4,820", "4,280", "about"]
scores = [2.0, 1.0, 0.5]
for t in (1.0, 0.5, 0.2):
    probs = next_token_probs(scores, t)
    shown = ", ".join(f"{tok} {p:.0%}" for tok, p in zip(tokens, probs))
    print(f"temperature {t}: {shown}")

Run it and you should see:

temperature 1.0: 4,820 63%, 4,280 23%, about 14%
temperature 0.5: 4,820 84%, 4,280 11%, about 4%
temperature 0.2: 4,820 99%, 4,280 1%, about 0%

What just happened? At temperature 0.2, the wrong total, 4,280, still gets 0.67% of the choice, which the printout rounds to 1%. That is about 1 time in 150.

If every question were like this one, 100,000 questions a day would give about 670 wrong totals. With temperature alone, the wrong token keeps a share above zero at any temperature above zero.

A second setting, top-p, cuts off the unlikely tail. With top-p at 0.9, temperature 0.2 keeps only 4,820, but temperature 0.5 still keeps 4,280. Cutting the tail cannot tell a right number from a wrong one.

Treat a small evaluation set as a noisy measurement and report its range. With 30 questions, 24 passing fits a true pass rate anywhere from about 63% to 90%.

That range is a 95% Wilson interval, a standard way to put error bars on a pass rate. NIST's engineering statistics handbook gives the formula used below.

from math import comb, sqrt

def wilson(passed, total, z=1.96):
    p = passed / total
    centre = (p + z * z / (2 * total)) / (1 + z * z / total)
    half = z * sqrt(p * (1 - p) / total + z * z / (4 * total * total)) / (1 + z * z / total)
    return centre - half, centre + half

def sign_test(fixed, broken):
    n = fixed + broken
    k = min(fixed, broken)
    tail = sum(comb(n, i) for i in range(k + 1)) / 2 ** n
    return min(1.0, 2 * tail)

for passed in (24, 26):
    low, high = wilson(passed, 30)
    print(f"{passed}/30 passed: 95% range {low:.0%} to {high:.0%}")
print(f"2 fixed, 0 broken: p = {sign_test(2, 0):.2f}")
print(f"8 fixed, 1 broken: p = {sign_test(8, 1):.3f}")

Run it and you should see:

24/30 passed: 95% range 63% to 90%
26/30 passed: 95% range 70% to 95%
2 fixed, 0 broken: p = 0.50
8 fixed, 1 broken: p = 0.039

No, it is not proof. The two ranges overlap heavily. A sign test looks only at the questions whose result changed. If the change fixed 2 and broke none, it gives p = 0.50.

Here p is the chance of a split at least that lopsided if the change did nothing. A coin flip would give it half the time. With no breaks, you need at least 6 newly fixed questions before p falls below 0.05. Eight fixed and one broken gives p = 0.039.

So report fixed and broken counts, not just two scores, and grow the set as the project grows. That is an answer a sceptical reviewer can check.

Expect to rank stored vectors by cosine similarity to a query and return the top few. That is the DSA half hiding in an AI task: Python's heapq.nlargest returns the k highest scores, and its docs say it works best when k is small.

import heapq
import math

def cosine(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    norm_a = math.sqrt(sum(x * x for x in a))
    norm_b = math.sqrt(sum(y * y for y in b))
    if norm_a == 0 or norm_b == 0:
        return 0.0
    return dot / (norm_a * norm_b)

def top_k(query, vectors, k=3):
    scored = ((cosine(query, v), name) for name, v in vectors.items())
    return heapq.nlargest(k, scored)

vectors = {
    "invoice_101": [0.9, 0.1, 0.0],
    "invoice_102": [0.7, 0.7, 0.0],
    "invoice_103": [0.0, 1.0, 0.0],
    "invoice_104": [1.8, 0.2, 0.1],
    "empty_page": [0.0, 0.0, 0.0],
}
for score, name in top_k([1.0, 0.0, 0.0], vectors):
    print(f"{name} {score:.3f}")

Run it and you should see:

invoice_101 0.994
invoice_104 0.992
invoice_102 0.707

What just happened? The vector for invoice_104 is about twice as long as invoice_101, yet scores almost the same, 0.992 against 0.994. Cosine compares direction, not length.

The empty page has no direction at all, so the function returns 0.0 instead of dividing by zero. Say that edge case out loud; it is the one interviewers wait for.

Walk the interviewer from the user's problem to measured results, in six steps. The same frame works for the take-home review, the design round and the question about a past project.

1. 1

   Start with the user and the cost of a mistake

   One sentence on who asks what, and what a wrong answer costs. For invoices, a wrong total hurts more than a slow reply.

2. 2

   Draw the path of one question

   Question, filter by shop, search the index, model call, reply naming the invoice. Point at where each failure can happen.

3. 3

   Show the baseline score with its range

   Give the simplest version's score and its range, such as 24 of 30, roughly 63% to 90%.

4. 4

   Walk through one change

   Name one change, such as smaller chunks, and give the fixed and broken counts, not just the new score.

5. 5

   Give cost and speed numbers

   Tokens per question, the daily bill as a formula, and the reply time. Say what happens when the spending cap is hit.

6. 6

   End with known failures

   Name two failures you have not fixed, and what you would try next with another week.