Courses › AI-Assisted Coding › Tools & Pitfalls

Common Mistakes

The ten habits that sink AI-assisted rounds — and what to do instead.

AI-assisted rounds fail in predictable ways. Most failures aren't about skill. They come from habits under time pressure that hand your judgment over to the tool. Here are the mistakes interviewers see most, and what to do instead.

1. Pasting the whole problem in

What happens: the full spec goes into the agent, a 400-line diff comes out, and you spend 40 minutes debugging code you didn't design.

Instead: clarify, plan, and delegate one small slice at a time. See A Winning Workflow.

2. Accepting diffs without reading them

What happens: a subtle bug slips in (wrong comparison, swallowed exception, off-by-one) and surfaces later, far from its cause.

Instead: read every diff as if you were reviewing a colleague's pull request. If it's too large to review in a minute or two, it was too large to ask for.

3. The "fix this error" loop

What happens: paste the error, accept the patch, rerun, and repeat five times. Each patch adds a special case, and the root cause is never found.

Instead: form a hypothesis first, then use the assistant to test it. See Debugging with AI.

4. Prompt thrashing

What happens: the same vague request is rephrased again and again, hoping for a better result. Ten minutes go by.

Instead: after two failed attempts, stop. Either add the missing context (the files, an example, the constraint you forgot to mention) or write that piece yourself. Knowing when to stop using the tool is a skill interviewers look for.

5. Going silent

What happens: the interviewer watches code appear on the screen with no idea what you're thinking. You get no credit for the judgment you used.

Instead: narrate the key decisions: what you're delegating and why, what you're checking, and what you found. One sentence per step is enough.

6. Letting the assistant own the design

What happens: the data model, the module structure and the error handling are whatever the first generation produced. When requirements change, nothing fits.

Instead: decide the data model and the interfaces yourself, write them down, and put them in your prompts.

7. Letting the tests be weakened

What happens: asked to "make the tests pass", the assistant loosens an assertion, skips a test or special-cases the test input.

Instead: treat edits to tests as high-risk. Review them separately, and say out loud when you reject one.

8. Never writing code yourself

What happens: the interviewer can't tell whether you can code at all.

Instead: write the trickiest logic yourself, the core algorithm or the subtle comparator, and delegate the mechanical parts. Say which is which.

9. Ignoring the codebase's conventions

What happens: your additions use a different error style, naming and test structure from the rest of the repo, and they read like a foreign object.

Instead: find the closest existing feature and tell the assistant to follow it. See Working in an Unfamiliar Codebase.

10. Running out of time with nothing working

What happens: ambitious scope, no checkpoints, and a broken build at the end.

Instead: build vertical slices, commit after each verified one, and stop adding features 15 minutes before the end to test, clean up and walk through your work.

[!INTERVIEW] Self-check every 15 minutes Ask yourself three questions. Do I understand every line in the codebase that I've added? Are the tests passing? Have I said my last decision out loud? If the answer to any of them is no, fix that before doing anything else.

[!TIP] Practice Extend an Unfamiliar Codebase with AI · Debug a Failing Test Suite with AI · Build a Small App from a Spec with AI