AI-Assisted Coding Interviews

The coding interview is in the middle of its first real format change in about fifteen years, and candidates are getting contradictory advice because both sets of advice are currently true — at different companies.

> This is a moving target, and the specifics below are reported rather than officially documented. Company policies are changing between hiring cycles and are not consistent across teams within the same company. Nothing here substitutes for asking your recruiter directly, which is covered below and is the single most useful thing you can do.

The split, as it stands

Two things are happening at once.

Some large companies have been reported to be piloting rounds where an AI assistant is made available to you during the problem, and your use of it forms part of the assessment. The stated logic is straightforward: engineers use these tools daily, so an interview that bans them measures something the job no longer asks for.

At the same time, industry survey reporting from early 2026 indicated that the clear majority of organisations still prohibit AI in technical interviews, and treat undisclosed use as a serious integrity issue.

So there is no single answer to "can I use AI in my coding interview". There is only the answer for the specific round you are sitting — which is why the first step is not a preparation technique at all.

Step one: ask

Ask your recruiter, in writing, before the round:

• Is an AI assistant available or permitted during the coding round?
• If yes, which tools, and is my use of them assessed?
• If no, does that include autocomplete in the editor?
• Is the round run in a shared editor, and is the screen recorded?

This is a completely normal question and asking it signals diligence rather than intent to cheat. Guessing is the failure mode here — assuming AI is allowed when it is not is a serious problem, and assuming it is banned when it is offered means you look slow and inflexible against candidates who used it well.

If AI is not allowed

Prepare exactly as you always would. This is still the majority case and the fundamentals have not changed: pattern recognition, clean implementation under time pressure, and reasoning out loud.

One genuine risk is worth naming. If you have been practising with an AI assistant available, you may have built much less unaided recall than you think, because the assistant was quietly filling the gaps. Practise the way you will be assessed — assistant closed, timer running. Work by pattern rather than at random; the 22 essential DSA patterns is the smallest set that covers most of what gets asked, and every company set is ordered by the patterns that company leans on most.

Note also that "no AI" often includes editor autocomplete, and disabling it on the day for the first time is unpleasant. Turn it off during practice.

If AI is allowed

This is the harder case to prepare for, because the thing being assessed is not whether you can produce a correct solution — the assistant can usually do that. It is your judgement.

What tends to be assessed:

• Whether you understood the problem before prompting. Reaching for the assistant before restating the problem and clarifying constraints reads as not thinking.
• The quality of your prompt. A precise prompt that carries the constraints is a demonstrable skill. A vague one that produces plausible-but-wrong code is the failure mode being tested for.
• Whether you verify the output. Accepting generated code without reading it is the single worst thing you can do in this format. Trace it, test the edge cases, say out loud what you checked.
• Whether you can recognise a wrong answer. Assistants produce confident, subtly incorrect solutions — off-by-one errors, wrong complexity, mishandled edge cases. Catching that is precisely the signal.
• Whether you can work without it when it fails. If the assistant goes in circles, can you take over?

The counter-intuitive implication: you need stronger fundamentals for an AI-assisted round, not weaker ones. You cannot evaluate a solution you could not have written. Candidates who lean on the assistant to compensate for shaky fundamentals are exactly who this format identifies.

How to practise for it

Practise both ways, deliberately, rather than drifting between them:

1. Unassisted first, always. Solve the problem yourself, timed, assistant closed. This builds the recall and the judgement everything else rests on.
2. Then re-solve it assisted. Same problem, this time with the assistant. Compare its approach to yours. Where it differs, work out which is better and why — that is the judgement being assessed.
3. Practise catching errors. Ask an assistant for a solution to a problem you know well and check it properly. You will find real bugs. Learning what its failure modes look like is directly transferable.
4. Practise narrating. In both formats you are assessed on reasoning out loud. Saying "I'm going to check this against an empty input and a single-element input" is worth marks.

What has not changed

Almost everything else. Core CS subjects are still asked and still pure recall — see core subjects. System design rounds still test judgement and trade-offs, which is a conversation an assistant cannot sit for you; the system design sheet covers HLD and LLD. The HR round is unchanged.

Pattern-based DSA preparation remains the foundation under all of it, whichever way the round is run. If anything, the shift raises the value of understanding why a pattern applies, because reciting a memorised template is the part that has been automated.