What an AI coding interview is actually like

Candidates tend to prepare for an AI coding interview the way they'd prepare for a whiteboard algorithm round: grind puzzles, memorise patterns, hope the problem is familiar. Then the round asks them to read forty lines of a service, find the bug, and explain why it matters, and the puzzles didn't help.

Here's what these rounds actually look like, what they reward, and what to practise instead.

Three things people mean by an AI coding interview

The phrase gets used for three different rounds. Find out which one you have, because each rewards something different.

1. A coding exercise inside an AI interview

A conversational AI interviewer asks technical questions, and at some point shows you a snippet. You're asked what it does, what's wrong with it, or how you'd change it, and then followed up on your answer. This is the version that has grown fastest, because it tests the thing engineers do all day: reading code they didn't write.

2. A recorded or timed coding assessment

You solve problems in a browser editor against a clock, and your solution, and often your process, is reviewed afterwards, sometimes with automated scoring first. Some one-way video platforms, HireVue among them, can add a coding step to the same session. One-way and AI video interviews covers that setting.

3. A coding round where you're allowed to use AI

A growing number of companies now let candidates use an AI assistant during the coding round, because that's how the job is done. The assistant doesn't make the round easier. It changes what's scored: how you break down the problem, how you check what the assistant produced, and whether you notice when it's wrong.

What changes when the reviewer is AI

• Your reasoning has to be in words. A human watching you type can infer what you're thinking. An AI reviewer only has what you wrote and said. Silent correct code earns less credit than it deserves.
• Nobody gives hints. A human interviewer often nudges a stuck candidate. An automated round won't, so you need your own way of getting unstuck: state the brute force, then improve it.
• The follow-up is about your own code. In the conversational version, the next question is generated from your fix. If you changed something without being able to say why, that's what you'll be asked.
• Process can be visible. Timed platforms may record edits, pastes and the order you did things in. Follow the rules the round states, and assume anything you do in the editor is part of the evidence.

The code-reading round, step by step

This is the most common shape, and the easiest to prepare for once you've seen it. You get a snippet like this one:

async function sendReminders(users) {
  users.forEach(async (user) => {
    await emailClient.send(user.email, "Your trial ends soon");
    await db.markReminded(user.id);
  });
  return { sent: users.length };
}

A strong answer works through it in the same order every time:

1. Say what the code is trying to do. "It emails every user and records that it did." This proves you read it before judging it.
2. Name the bug and the mechanism. "forEach doesn't wait for async callbacks, so the function returns before any email is sent, and a failure in one callback is an unhandled rejection that nobody sees."
3. Say what it costs in production. "The caller thinks everything was sent. If the process exits, some users never get the email, and nothing logs it."
4. Make the smallest fix that's actually right. A plain for...of loop, or Promise.allSettled if the sends can run in parallel, and return what really happened.
5. Name the next problem. "With ten thousand users I'd batch this, and the email and the database write aren't atomic, so a retry could email someone twice."

When you're allowed to use AI in the round

If the rules let you use an assistant, the interviewer isn't grading whether you can type a prompt. They're watching for judgement:

• Do you break the problem down before asking for code, or paste the whole task in?
• Do you read what comes back, or run it and hope?
• Do you catch it when the output is subtly wrong, like a missing edge case or an API that doesn't exist?
• Can you explain every line you kept, as if you'd written it yourself?

The candidates who do worst in these rounds accept the first answer and can't defend it on the follow-up. The code they submitted is only as strong as their explanation of it.

Where candidates lose points

• Fixing without explaining. A correct change with no stated reason reads as a lucky guess.
• Rewriting everything. Replacing the whole function when one line was wrong suggests you didn't find the actual problem.
• Stopping at the first bug. Snippets often have a second, quieter issue. Say so even if you don't fix it.
• Ignoring production. Scale, retries, partial failure and security are where the senior points are.
• Going quiet. In a conversational round, silence is an empty transcript.

How to prepare for an AI coding interview

Swap some puzzle time for code reading. Take real code, ideally from an open source project in your language, pick a function, and do the five steps above out loud: intent, bug or risk, production cost, smallest fix, next problem. It feels slow at first. After ten or so it becomes the way you read code anyway.

Then practise being followed up on. The part that trips people up isn't finding the bug, it's the second question about their own fix. The Code Challenge mode here is built for exactly this: it shows you a realistic snippet in Node.js, Python, Go or Java, you fix it in place, and you see your change compared with a senior reference. For the spoken version, an AI mock interview mixes code questions into a full technical screen.

And if the round includes live coding with a person watching, the habits carry over, with a few additions covered in live coding interview tips.