AI-Assisted Coding Interviews: What They Test and How to Prepare

A new interview format is showing up next to the classic algorithms round: the AI-assisted coding round, sometimes called "AI-enabled coding". You get a small, real codebase, an AI assistant in a side panel, and roughly an hour. The interviewer watches your screen and your prompts.

It is not "LeetCode, but the AI writes the code". It is closer to a debugging, code review and feature work session, and the signal is how you work with the assistant, not whether it can produce code.

What the round looks like

The details vary by company, but most candidate write-ups describe the same shape:

• You start in an existing codebase, not a blank editor. Think three to six files: a module, a few helpers, and a test file where some tests already fail.
• An assistant sits beside the editor. It can read the files and suggest code. In some setups it can edit files directly; in others it can only suggest.
• The work comes in stages: 1. Get the failing tests green (find and fix the bug). 2. Add a feature on top of the existing code. 3. Handle edge cases, or make it work at a larger scale. 4. Talk through trade-offs and what you would do next.
• Every prompt is visible. What you ask the assistant, and what you do with its answer, is part of the evaluation.

What interviewers actually grade

The biggest mindset shift: the AI writing correct code earns you nothing. You catching it when it is wrong is the signal.

Six ways candidates fail it

1. Pasting the whole task into the assistant. You hand over the design, and the interviewer learns nothing about how you think.
2. Accepting the first suggestion. Assistants are often plausibly wrong: the code looks reasonable but fixes the wrong thing.
3. Not running the tests after each change, or running them and not reading the output.
4. Typing in silence. In this round your reasoning is the product. If you don't say it, it didn't happen.
5. Letting scope creep. The assistant happily rewrites half a file. Big diffs are hard to verify and usually add new bugs.
6. Not being able to explain the final code. "The AI wrote that part" is the worst answer you can give.

A worked example

A toy version of a stage-one task: a token-bucket rate limiter, and the test "with capacity 2, the third request at the same timestamp is rejected" fails.

class TokenBucket:
    def __init__(self, capacity, rate):
        self.capacity = capacity
        self.rate = rate          # tokens per second
        self.tokens = capacity
        self.last = 0.0

    def allow(self, now):
        elapsed = now - self.last
        self.tokens = min(self.capacity, self.tokens + elapsed * self.rate)
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

A weak flow: paste the file and say "this test fails, fix it". The assistant replies that the class isn't thread-safe and wraps allow in a lock. That sounds senior, but it is not the bug: the test is single-threaded, it still fails, and now there is a lock nobody asked for.

A strong flow:

1. Read and hypothesise out loud. "elapsed is measured from self.last, but nothing ever updates self.last, so every call refills as if no time had passed since t=0."
2. Confirm with a concrete trace. Capacity 2, rate 1, three calls at t=10: each call computes elapsed = 10 - 0 = 10, refills to full, and the third request is wrongly allowed. With this bug the bucket can never drain.
3. Ask for something narrow. "In allow(), set self.last = now after the refill. Change nothing else." The diff is one line and easy to review.
4. Verify, then extend the tests yourself. Run the suite, then add a case the original tests missed: what if now is slightly before last because clocks moved? Should elapsed be clamped at zero?
5. Only then discuss the bigger picture: what changes with multiple threads, or multiple servers sharing one limit.

Both flows end with the same one-line fix. They send very different signals.

How to prepare

• Practise on small codebases, not single functions. Three to six files with tests, timeboxed to 45–60 minutes.
• Use the same loop every time: read → reproduce → hypothesise → prompt narrowly → verify → explain.
• Train reviewing on purpose. Ask an assistant for a solution, then find what is wrong with it before you run it. If you can't point to the line that breaks on an edge case, you haven't reviewed it.
• Narrate while you practise, even alone. It feels awkward for a week, then it becomes natural.
• Keep your fundamentals sharp. The extend and scale stages still come down to choosing the right data structure: heaps, hash maps with linked lists, tries, graphs.
• Rehearse the scale conversation: what breaks at 100x traffic, what you would cache, what has to become idempotent.

Practise the exact format. Prepd's AI-assisted coding track has 50 original problems (rate limiter, TTL LRU cache, consistent hash ring, wallet ledger, webhook verifier, LLM token chunker and more). Each one is split into the stages of the real round: fix the bug, direct the AI, catch its mistakes, extend, and scale, with written feedback on every answer.

Practise it

• AI-Assisted Coding drills (50 problems)
• Free LLD drill: OTP System
• Free system design drill: Like Button