The Interview Changed While Nobody Was Looking

For years, the coding interview tested one thing above all: could you reproduce a known solution, from memory, under pressure, on a whiteboard? That test made sense when the job was writing every line yourself. It makes much less sense now, when a working developer writes code with an AI assistant sitting next to them all day.

So a growing number of interviews have flipped the rules. You are allowed to use AI help. Sometimes you are even expected to. And the interview got harder, not easier — because the thing being tested moved. Nobody cares whether you can make the model produce a working function. Everybody cares whether you understand the function it produced.

This is good news for candidates who actually build things, and bad news for candidates whose entire preparation is memorising solutions. Here is how the new interview works, and how to practise for it.

What Interviewers Grade Now

In an AI-allowed interview, the interviewer already knows the AI can write the baseline solution. That is the starting line, not the finish line. The grading happens in what comes after:

  • Comprehension. Can you walk through the generated code line by line and say what each part does, without reading the AI explanation back verbatim?
  • Debugging. Can you find the bug the AI left in — the off-by-one, the wrong edge case, the assumption that breaks on empty input?
  • Trade-offs. Can you say why this approach and not the other one, in terms of time, memory, readability, and what breaks when the input grows?
  • Adaptation. When the interviewer changes one requirement halfway through, can you change the solution, or does your understanding collapse the moment the problem stops matching the template?

Notice what is missing from that list: typing speed, recall, and prompt cleverness. A beautiful prompt that produces code you cannot explain is worth nothing here. A mediocre first attempt that you can reason about, fix, and defend is worth a great deal.

A Real Example: The Bug You Are Supposed to Catch

Suppose the task is: given a list of numbers, return the first value that appears more than once. You ask the AI, and it gives you this:

def first_duplicate(nums): seen = set() for n in nums: if n in seen: return n seen.add(n) return None print(first_duplicate([2, 5, 1, 2, 3, 5])) # 2
print(first_duplicate([1, 2, 3])) # None
print(first_duplicate([])) # None

That code is correct, and that is exactly why the interview gets interesting. The interviewer will not ask you to write it. They will ask you things like: what does this return when the input is empty, and is None a good answer if None could also be a valid list element? What is the memory cost, and when would you accept a slower approach that uses no extra memory? What changes if the list is a stream you can only read once, and what changes if it does not fit in memory at all?

Now try the same exercise with a subtly wrong version. Imagine the AI had returned the first value whose second occurrence appears earliest, or had used a list instead of a set and made the whole thing quadratic. Could you spot it? Could you prove your fix with a test, not just a feeling? That skill — reading code sceptically, testing the claim — is the entire interview now.

The Practice Routine That Actually Builds This Skill

Forget grinding fifty problems a week. In an AI-allowed world, depth beats volume. Pick one problem a day and run this thirty-minute loop:

  • Attempt first (10 minutes). Work on the problem with no AI at all. Write down your approach in plain words before you write code. A half-finished attempt with a clear idea is more useful than a perfect generated answer.
  • Hint, not answer (5 minutes). If you are stuck, ask the AI for a hint: the data structure to consider, or the invariant to maintain. Do not ask for the solution yet.
  • Re-explain aloud (5 minutes). Once you have working code — yours or the AI's — explain it out loud as if the interviewer just asked “walk me through this.” If you stumble, that stumble is the gap. Fill it before moving on.
  • Break it with tests (5 minutes). Write tests for empty input, single-element input, duplicates, and the largest input you can imagine. Fix whatever fails. A test you wrote yourself is worth ten lines of explanation.
  • Change one constraint (5 minutes). What if the input is sorted? What if you cannot use extra memory? What if duplicates must be counted, not just found? Adapt the solution. This is the closest simulation of the real follow-up question.

Do that for two weeks and you will notice something: the AI stops being a crutch and starts being a sparring partner. You will also notice your interview answers getting shorter and sharper, because you are no longer reciting — you are reasoning.

What Not to Do

Three habits will sink you in this format. First, pasting the problem into the AI and pasting the answer back without reading it. The interviewer will ask one follow-up and the whole performance falls apart. Second, memorising fifty solutions. The interviewer changes one constraint precisely to defeat memorisation, and a memorised answer adapts badly. Third, narrating the AI's explanation instead of your own reasoning. Interviewers can tell the difference between someone who understands and someone who is paraphrasing, usually within a minute.

One more rule, and it matters: only use AI in an interview when the interviewer has explicitly allowed it. Some interviews still forbid it, and using it there is not clever — it is a failed interview. Ask at the start, every time.

Practise in the Real Room

The format matters as much as the content. If your real interview happens in a collaborative editor with video, practising alone in a notebook will not prepare you for talking while you type, or for someone watching you debug live. Rehearse in the same shape as the real thing: a shared editor, a problem on screen, and a friend (or a recording of yourself) asking follow-ups.

Open a collaborative room on CoderFile's coding interview editor, run the thirty-minute loop above with a partner, and make them change one constraint halfway through. That single habit — adapting live, out loud — is the closest thing to a cheat code this interview format has. And for structured practice between sessions, CoderFile Lab's guided courses give you runnable problems to run the loop on.