The AI-assisted coding interview
An AI-assisted coding interview is a working session in a real editor where an assistant is allowed, required, or banned. The task is usually to read unfamiliar code and change behaviour correctly, not to invent an algorithm. What is scored is how you orient in the codebase, whether you verify the assistant's output instead of trusting it, and whether you finish something working. Your recruiter is the only reliable source for which rule applies.
Applies wherever a coding round happens in a real editor or repository. Traditional algorithm rounds are a different exercise and are not covered here.
Allowed, required, or banned
Three genuinely different exercises hide behind the same round name. Confirm which one you are getting before you prepare.
| Rule | What it means | What is being scored |
|---|---|---|
| Allowed | The assistant is available and using it is neither expected nor penalised. | Judgment about when to delegate, and whether you check what comes back. |
| Required | You are expected to work with the assistant, sometimes on a deliberately large task. | Whether you can direct it, catch it being wrong, and keep the result coherent at speed. |
| Banned | No assistant, usually in a real editor on real code. | Whether you can still read, reason and debug without one. |
Some teams state the rule in the invitation; many do not. Asking is routine and is not read as a weakness.
What to ask your recruiter
Before you prepare anything, send one short email: how many rounds, what each one is called, how long each runs, whether any of them is a take-home, and whether an AI assistant is allowed in the coding round. Recruiters answer this routinely. Anything they confirm outranks every pattern on this page, because it is first-party evidence about your loop rather than a general tendency across companies.
What the name usually means
- You work in a real editor on a real repository or a non-trivial starter, with an assistant available.
- The task is usually to read unfamiliar code, change behaviour, and keep it correct — not to invent an algorithm from scratch.
- Some teams watch how you use the assistant. Some watch whether you catch it being wrong. Some ban it entirely and say so.
- Sessions are commonly 45 to 60 minutes, and a working, tested, smaller change beats an ambitious unfinished one.
What it tends to test
- Reading unfamiliar code
- Orienting fast in a codebase you did not write, and finding the right place to change.
- Verification habits
- Whether you run it, test it, and check the assistant's output instead of pasting it in and hoping.
- Judgement about the tool
- Knowing which parts of the task to delegate and which to write yourself, and being able to say why.
- Debugging under observation
- Forming a hypothesis, testing it, and narrowing — out loud — rather than changing lines at random.
- Finishing
- A working, tested, smaller change beats an ambitious unfinished one almost every time.
- Communication while working
- Saying what you are about to do before you do it, so the interviewer can follow your reasoning rather than guess at it.
What it is not
- Not a timed puzzle round, usually. Speed on tricks is rarely the signal.
- Not a test of whether you can type quickly without help.
- Not permission to skip reading the code the assistant produced.
- Not a trap. Where the assistant is allowed, using it well is the expected behaviour.
Study now, review, skip
- One practice session in your normal editor on an unfamiliar open-source repo: fix a real issue, with tests, in 45 minutes.
- Narrating a debug loop out loud — hypothesis, check, narrow.
- Writing a test first for the behaviour you are about to change.
- Your habit for reviewing generated code before accepting it.
- Fast orientation techniques: entry points, tests, grep, call paths.
- Your editor's own tooling, so setup does not eat the session.
- Reading stack traces and test output quickly.
- Algorithm puzzle grinding, unless your recruiter confirmed that format.
- Memorising assistant prompting tricks.
- Learning a new editor the week of the interview.
Common failure modes
- Accepting generated code without reading it, then being unable to explain what it does.
- Working silently, so the interviewer sees output with no reasoning attached.
- Changing lines at random when a test fails, instead of forming a hypothesis.
- Starting the most ambitious version of the task and finishing none of it.
- Refusing to use an assistant that was explicitly allowed, which reads as inflexibility rather than rigour.
- Losing ten minutes to environment setup that could have been checked beforehand.
A three-day plan
Day 1 — Confirm the rule
- Ask your recruiter one direct question: is an assistant allowed, required, or banned. That answer changes how you prepare.
- Check your environment: editor, language runtime, test runner, and assistant access if permitted.
Day 2 — A real repository
- Pick an unfamiliar open-source project and fix a genuine issue with a test, timed at 45 minutes.
- Note where you lost time. For most people it is orientation, not writing code.
Day 3 — Narration and verification
- Repeat the exercise narrating every step out loud, as though observed.
- Practise reviewing generated code deliberately: read it, test it, then keep or discard it.
Common questions
- Should I use the AI assistant if it is allowed?
- Generally yes, and deliberately. Delegate the mechanical parts, write the parts where correctness matters yourself, and read everything before accepting it. Refusing an explicitly permitted tool usually reads as inflexibility.
- What if the assistant produces wrong code during the interview?
- That is frequently the point of the exercise. Noticing it, saying so, and correcting it is the strongest sequence available in the round.
- Do companies still run traditional algorithm rounds?
- Some do and some have replaced them with repository-based sessions. It varies by company rather than by role, so confirm the format with your recruiter rather than assuming either way.
- How much does finishing matter?
- A great deal. A smaller change that works and is tested almost always scores better than an ambitious change left broken at the end of the session.
Related interview guides
- AI engineer interview: rounds and prep
The generalist AI engineering loop: coding, AI system design, project deep dive, behavioral.
- Agentic AI interview: rounds and prep
State, tools, orchestration, recovery, guardrails, and how agent reliability is actually probed.
- LLM interview questions, organised by what they test
Nine themes instead of a question bank, and why memorised answers fall apart under follow-up.
- AI interview prep: the 2026 guide
The hub. Every role guide and round guide on this site, and how to decide which ones apply to your loop.
How every ranking on this site is reasoned about, including what counts as evidence: read the methodology.
Map your actual interview.
This page is the general pattern. Paste the job you are actually interviewing for and the wording your recruiter used, and the map ranks the rounds you are likely to face, explains why each is ranked where it is, and tells you what to skip.
See a complete Full Interview Map example