How do you prepare for an AI-assisted coding interview?

Updated August 12, 2026 · 12 min read · Crack ML Interview

TL;DR

In this interview an AI writes the code, and you are graded on everything around it: the choices you make while guiding the AI, how well you can explain what it wrote, and whether you can show it works in the real world. There is no single "right" answer to match against, so your score comes from three things we call Direction, Ownership, and Hardening. People who do well do not memorize a magic prompt — they treat every draft the AI produces as something to check and stand behind.

What Is Different About This Interview

You spend less time writing code and more time explaining it

In a normal coding interview, most of the hour goes into typing out the solution. Here, an AI writes the code for you in seconds. That frees up time, and the interviewer uses it to ask why the code works the way it does. So the questions keep getting harder: a stricter requirement, a tougher test, then an extra feature. Writing code quickly does not help you much. Being able to explain and defend what the AI produced is what counts.

When the question is vague, say so

Interviewers often leave part of the problem unclear on purpose. When that happens, point it out. Say something like, "This could mean X or Y — I will assume X because it fits the example," and then check with them. Spotting the gap and making a clear choice scores better than quietly guessing and hoping you picked right.

There is no single right answer, so they watch how you work

An AI can solve the same problem in many different ways, so there is no model answer to compare you against. Instead, the interviewer watches what you do with the code: how you check it, explain it, test it, and catch what is missing. Expect to: • Go past the first version that just barely runs. • Notice when the question quietly leaves a decision up to you. • Read the code and its test results yourself. • Explain a part of it without asking the AI. • Point out edge cases and real-world problems the first version ignored.

The Three Things You Are Graded On

Working code is just the starting point

Getting the code to work is only step one. After that, the interviewer looks at how well you check and defend it: Do you understand it? Can you judge the decisions inside it? Can you show it actually works? There is no "correct" set of prompts to use — what matters is that the finished result is genuinely yours.

1. Direction

Direction means having your own opinion about what the AI wrote, and changing course when it goes the wrong way.

Do this

You read the AI's code before accepting it, and fix the mistakes you spot.
You notice choices the AI made on its own, and compare them to other options.
When something is wrong, you work out why first, then make the fix.
You delete failed attempts instead of leaving messy code behind.
You switch approach as soon as the current one clearly is not working.

Avoid

You accept the AI's code without really reading it.
You treat the AI's first choice as the only option.
After a failure, you just ask again without knowing what went wrong.
Broken, half-finished fixes pile up in the code.
You keep going down a path that clearly is not working.

2. Ownership

Ownership means you can explain the AI's code as if you had written it yourself.

Do this

Point at any part and you can walk through it and say why it is written that way.
Your explanation is your own reasoning, not just repeating what the AI said.
You can say what the chosen approach is good at and where it falls short.
You catch bugs or missing cases while reviewing.
You connect the code to bigger concerns, not just the example in the question.

Avoid

You cannot explain a line unless the AI explains it for you.
Your explanation stops exactly where the AI's did.
You are unclear on why the important choices were made.
You assume the code is correct because it looks correct.
You never go past the simple "it works" case.

3. Hardening

Hardening means checking how the code holds up in the real world — when something fails, when traffic is high, when it runs every day — not just when the example works.

Do this

You point out failures the first version did not handle, and how bad each one would be.
You look for things that can grow forever, like lists or counters with no limit.
You ask what logs or alerts would help someone debug it when it breaks live.
You say what should happen when the main path is down — a backup plan.
You treat passing tests as a good sign, not as full proof it is correct.

Avoid

You only talk about failures the code already handles.
You never mention memory or other limits.
You have no way to even notice a problem once it is live.
You have no backup for when the main path fails.
You treat passing tests as proof that everything is fine.

How to Work With the AI: Five Habits That Score

Why these habits matter

The way you would hand a task to another engineer is exactly how you should work with the AI here — and it is what earns points. (We cover these in our LLM Prompting course at crackmlinterview.com/learn/prompting-engineering.) Here are five habits that help the most, and which of the three areas each one shows.

Tell it to look before it leaps

Before you ask the AI to change anything, tell it to read the existing code and tests first. If it edits blindly, it often breaks things or writes code that does not match the rest of the project. Saying this shows Ownership — you are treating the current code as something to understand, not bulldoze.

Say what it should do, not how to build it

Describe the result you want — the inputs, the outputs, the edge cases — instead of telling the AI exactly how to write it. For example, "Cache successful lookups for five minutes, but never cache errors" is clearer than "add caching." This is Direction: it stops the AI from confidently building the wrong thing, and gives you something concrete to test against.

Tell it what it is allowed to touch

Say which files it can change, what it must not change, and whether it is allowed to rewrite things. This keeps the change small and easy to review — which matters a lot when the interviewer asks you to walk through it. Vague requests lead to huge, messy changes you cannot fully explain.

Give it the problem, not your guess

Tell the AI what is going wrong, but keep your guess about the cause separate. If you state your guess as fact, the AI will just chase it. Give it the symptom and let it investigate. This shows Direction — and it saves the time you would otherwise waste on repeated tries.

Ask it to prove the fix works

Do not stop at "it is fixed." Ask for proof: a test for that exact case, the test actually run, or a specific example traced through the code. A passing test you can point to beats "looks fixed." This is Hardening — the difference between claiming it works and showing it.

How You Work and Talk Also Count

Keep the work moving on your own

The three graded areas show most clearly when you drive the task yourself. Interviewers quietly notice whether you can keep going without being rescued. • Before you generate anything, point out any unclear part that would change the design, state your assumption, and confirm you are solving the right problem. • Keep enough time to read, test, and explain the code — extra code is useless if you cannot defend it. • Test often, and when something fails, look into it calmly and methodically. • Get past most problems yourself instead of waiting for the interviewer to help.

Explain your thinking clearly

Give the interviewer a clear line of reasoning to follow, not a string of one-line prompts. • Answer in a way that covers both the code and the thinking behind it, without needing many follow-up questions. • Say your assumptions out loud, and put the main points first. • Keep making progress after a mistake or a failed attempt. • When the requirement is unclear, turn it into specific questions and a simple plan. • Take the feedback you are given and use it in the next version.

There is no one right way to prompt

Engineers work with AI in different ways. You might talk through the design before any code is written, or generate a small first version and pick it apart; you might start with a short instruction and refine it, or give lots of detail up front. None of these is automatically better. The only thing that matters is a result you have checked and can explain, so do not waste practice time hunting for the perfect prompt. Spend it learning to take responsibility for whatever the AI gives you.

What the Hour Usually Looks Like

One hour, a starting task, then follow-ups

A common setup is about 60 minutes on CodeSignal with an AI coding tool like Claude Code available. You start with one task, then work through follow-ups that raise the bar. Finishing every follow-up is not the goal — doing two or three of them really well beats rushing through many. The interviewer may skip or reorder a follow-up if you already covered it, or if another part is leading to a better discussion.

What each step feels like

Each stage tends to follow the same steps: • You get the requirement, usually said out loud and also written in the project's README file. • You build it with the AI — plan, generate, check, test, adjust. • You explain the result, walk through the code, and point out what is still weak. • You back up your claims with evidence, not just a passing test. • You save a clean checkpoint by committing the finished stage, so you have a solid starting point and can spot anything a later change breaks.

How to Practice

Practice the whole loop, not just prompting

For each practice problem, run the same steps the interview will ask for, instead of just prompting until something works: • State the assumptions that matter and get the code working. • Review what the AI changed and remove the failed or unneeded parts. • Explain one part in depth and defend one choice against a reasonable alternative. • Run the tests, read the output, and use a specific input to show the result is right. • Name one thing the first version missed — a failure, something that can grow without limit, no way to see problems in production, or no backup plan. • Commit the stage before you move to the next follow-up. Our in-browser tools make this easy to practice: use LeanCode and the ML Coding Practice decks to write and run real solutions, and use the AI Review button on Problems to test whether your code actually holds up.

Read the first version closely, and find the cause before fixing

Read the AI's output before deciding it is done. Look for clear mistakes, questionable choices, and decisions the AI slipped in on its own — and for the important ones, practice saying whether you would keep them, what the alternative is, and why. When something breaks or a test fails, slow down long enough to form a guess about the cause, then use that to guide your next change. If a fix does not work, take it back out so the code stays clean instead of piling up patches.

Be ready to explain any line, and to prove it works

Practice explaining whichever function or line someone points at — not just the parts you planned to show — including what it does, why it is there, what it assumes, and where it could break, all without asking the AI. Writing a test suite is not the end: run it, read the results, tie them to what you are claiming, and be ready to trace one specific input through the code. Finish each practice run with an honest review — what is good, what you would change, and what breaks if something it depends on fails.

A Quick Checklist for the Interview

Keep this in mind during the round

• Say and defend your decisions as you plan, build, and change things. • Turn unclear requirements into stated assumptions instead of letting the AI quietly choose. • Review both the plan and the AI's changes at a point that fits how you work. • Run the tests and read the output yourself. • Work out the cause of a problem before you ask the AI again, and clear out failed attempts. • Be ready to explain any line you are asked about and give your own view of the trade-offs. • Think about failures, how far they would spread, limits, seeing problems in production, and backup plans. • Choose a result you can defend over sheer speed or lots of code. • Save a clean commit before you start the next stage. The big shift is from writing code to owning it. A strong candidate can go through the AI's work on their own, say how it behaves, show why it works, and point to where it still needs care.

What Earns and Loses Points in Each Graded Area

Graded area	What earns points	What loses points
Direction	Reading the AI's code before accepting it, finding the cause before re-asking, removing failed fixes, switching approach early	Accepting code without reading it, re-asking with no idea what went wrong, letting broken code pile up
Ownership	Walking through any line in your own words, weighing what an approach is good and bad at, catching gaps while reviewing	Needing the AI to explain the code, stopping at the simple case, assuming it works because it looks right
Hardening	Naming failures the code misses and how bad they are, checking limits, asking about logs and backup plans	Only mentioning failures already handled, ignoring limits, treating passing tests as full proof
Execution	Stating assumptions up front, testing often, getting unstuck yourself, leaving time to review	Generating code you cannot defend, skipping tests, waiting for the interviewer to move you along
Communication	One clear answer covering the code and the reasons, using feedback, recovering after a slip	Long strings of follow-up prompts, messy explanations, freezing after a failed attempt

Who this is for

Strong solo coder who trusts the AI too much

Profile: Writes clean code fast on their own, but in the AI round tends to accept the first version and rush on to the next requirement.

Pain points: Loses points on review, not on correctness: cannot always say which decisions the AI made, why it made them, or what the first version skipped — and sometimes leaves a failed fix sitting in the code.

Strategy: Practice the review half of every stage on purpose. After each version, take two minutes to name one choice the AI made, one alternative, and one gap, then delete whatever did not work. Practicing on runnable problems — like the ML Coding Practice decks with their in-browser test runner — builds the habit of checking and defending instead of just generating.

Engineer new to working with AI agents

Profile: Knows the language and the domain well, but has not paired with an AI agent much, so the workflow itself feels unfamiliar under time pressure.

Pain points: Spends too long trying to write the perfect prompt, then has little time left to test, explain, and harden — which is where most of the score is.

Strategy: Use a fixed routine each stage — assume, build, review, test, name a gap, commit — and give the AI only a short slice of time so most of the stage goes to checking and explaining. Any prompting style is fine; the goal is a result you can own, so repeat the routine until it feels automatic.

FAQ

Q: Do I need to memorize the perfect prompt to do well?

A: No. The interview does not grade your prompting style. Whether you talk through the design first, generate a small version and check it, or start short and refine, the thing that counts is a result you have checked and can defend. Spend your prep on reviewing, testing, and explaining code, not on memorizing prompts.

Q: How is this different from a normal coding interview?

A: A normal round rewards planning and typing out a correct solution. This one treats working code as the starting point and grades what comes next: the direction you give the AI, how well you can own the code it wrote, and how well you harden it against failures, limits, and real-world use. The interviewer digs into your decisions instead of comparing you to a set answer.

Q: Is it a bad sign to lean on the AI a lot?

A: No — leaning on the AI is expected and fine. The bad signs are about behavior: accepting code without reading it, re-asking after a failure with no idea what went wrong, not being able to explain a line the interviewer points at, and treating a passing test as the whole story. Let the AI write the code, but own the reviewing, testing, and explaining.

Q: How much code should I aim to write?

A: Aim for a result you can defend, not a large amount of code. Taking two or three requirements really far — reviewed, tested, explained, and hardened — beats generating a pile of code you cannot walk through. Save a clean checkpoint after each stage so you have a solid base and can catch anything a later change breaks.

Q: What is the best way to practice?

A: Practice a full stage rather than just generating code: state your assumptions, build, review and trim the changes, explain one part and defend one choice, check it with a specific input, name one thing the first version missed, and commit. Practicing in a runnable place like LeanCode or the ML Coding Practice decks, and using the AI Review feature on Problems, builds the check-test-explain habit this interview rewards.

Go deeper: our LLM Prompting course

A hands-on, in-browser course on prompting coding agents like a senior engineer — the exact habits this interview rewards.

Start the course

Want to practice with real, verified ML interview questions from top companies?

Browse the question bank