My AI-assisted coding interview was a lesson in reading unfamiliar code

The AI assistant was right there in my coding interview. It wasn’t allowed to help me debug.

Implementation help was restricted too.

I regularly use AI in day-to-day coding, so that took some adjusting. I was given an unfamiliar codebase and asked to fix bugs within a time limit. The immediate challenge was figuring out where to look.

Which files mattered? Where did the relevant behavior start? How did the execution flow through the application? What were the unit tests setting up, and what did they expect?

Those questions became a substantial part of the exercise.

In a codebase you know, you carry around context that’s easy to take for granted. You recognize the entry points. You know which component owns a behavior. You have some sense of where a change belongs and which other parts might be affected.

Even when you don’t know the answer, you usually have a reasonable starting point.

In this interview, I had to build that understanding while the clock was running.

Finding my way through the code

Navigating an unfamiliar repository involves more than opening files and reading methods. The useful part is connecting them.

A method can make sense on its own while leaving important questions unanswered. Who calls it? What assumptions does the caller make? Has the input already been validated or transformed? What happens to the result?

That surrounding context matters when you’re trying to fix a bug. A line can look suspicious in isolation and still be doing exactly what its caller expects.

The time limit made this more noticeable. I had to decide what to investigate next without first understanding the whole project.

For a task like this, the practical goal is to build a small, accurate picture of the behavior involved: where the input comes from, which code handles it, and where the result starts differing from what’s expected.

That’s enough to support an investigation. Reading every file isn’t a prerequisite.

Unit tests were part of understanding the application

The unit tests were another part of the codebase I needed to understand.

A failing assertion gives you somewhere to start, but the assertion alone doesn’t explain the whole situation. The setup matters. So do the inputs, dependencies, and assumptions built into the test.

Reading a test means asking:

• What situation is being created?
• What behavior does this assertion expect?
• How does the implementation produce a different result?
• What would explain that difference?

These questions help connect the test to the application’s behavior.

They also make it easier to judge a proposed fix. If I can explain only why a change makes an assertion pass, I may still be missing something about the underlying problem.

The stronger explanation is why the behavior was wrong, how the change addresses its cause, and what evidence supports that conclusion.

What the AI-assisted label didn’t tell me

I wouldn’t use this experience to describe every AI-assisted interview. The tool’s permissions shaped this particular exercise.

In my normal coding workflow, I can ask AI to help investigate a failure or suggest an implementation. Those options weren’t available here.

That made the distinction between having an assistant and having debugging assistance very concrete.

My experience felt like a software engineering exercise in getting oriented: navigating files, tracing execution, understanding tests, and building enough context to reason about a change.

I don’t know the interviewer’s complete scoring rubric. Those were the demands of the task from my side of the screen.

For anyone preparing for a similar interview, I’d ask about the assistant’s capabilities beforehand. “AI is available” leaves several questions open. Can it explain existing code? Suggest changes? Investigate failures? Or is its role more limited?

Knowing those boundaries helps you choose a useful way to practise.

What I’d change about my preparation

After this experience, I’d give unfamiliar repositories more room in my interview preparation.

Working on your own project is useful, but you already know why much of the code exists. You remember the decisions behind it. An unfamiliar project makes you practise reconstructing that context.

I’d start with a small repository that has a working test suite and a reproducible issue. Then:

1. Establish the starting state. Run the existing tests and see what passes and fails before changing anything.
2. Read the relevant test. Understand its setup, inputs, and assertions.
3. Trace the execution path. Follow the behavior involved in the failure across the relevant files.
4. Form an explanation. Write down what might be causing the problem and check that against the code.
5. Make a focused change. Run the relevant tests again and check nearby behavior that the change could affect.
6. Review and explain the fix. Read the diff and describe why the change addresses the cause.

I’d also practise within the tool restrictions expected in the interview. If debugging help is unavailable, it makes sense to rehearse investigating without it.

The explanation at the end matters to me. Could I walk someone through the failure, the cause, and the fix without relying on “the tests passed” as my entire justification?

That’s the skill I’d want the practice to develop.

The part of this interview that stayed with me was having to make sense of code I hadn’t written under time pressure. Before I could make a useful change, I had to understand enough of the system to know what that change should be.