The AI Coding Interview Should Test How Engineers Think

An AI coding interview should show how an engineer decides what to build, directs the tools available and takes responsibility for the result. I replaced the take-home task with a 90-minute live session built around those decisions.

Before the interview: share the repository

We share a small monorepo in advance: a backend, a frontend and an app, each with a basic list. Candidates can explore it for as long as they need. Around 30 minutes is usually enough to get familiar with it.

We ask them to install it, run pnpm dev and verify that the backend, frontend and app all start successfully before the session. There is a small configuration issue to diagnose. Getting a project running and investigating a failure are part of the work.

The repository has ten visible issues, a mixture of bugs and feature requests with different sizes and priorities. Candidates can read them beforehand, so the interview begins with context rather than a surprise assignment.

I created a separate public AI interview exercise to show the shape of the setup. It has its own code, reading list and issues; it is an example of the process rather than the original repository.

The 90-minute format

Here is the working allocation. The conversation can flex, but the candidate has 40 minutes to work and 20 minutes to review the result with us.

01. Welcome and format 5 minutes

We start with a short introduction and explain the session again: share your screen, choose from the issues and talk us through your thinking. The expected outcome is a pull request.

Candidates can use any AI assistant, search engine or other tool they normally use. We do not provide an assistant or expect them to learn a new one in the interview.

02. Choose and work 40 minutes

The candidate decides which issue or issues to tackle. Some choose one. Others work through several or take on several together. There is no required sequence or target number.

Start with product judgement

Why this issue, and why now?

Before building, explain who is affected, what value the change might create, what you would prioritise and what you would leave for later. We want to understand your reasoning, not hear one predetermined answer.

We ask candidates to think aloud as they work: what are they asking the agent to do, what do they expect back, and what will they check? While the agent is working, they can explain the next decision or consider another issue.

We try to listen without interrupting. If a candidate goes quiet, a prompt such as “Why did you pick that?” or “What would you do next?” helps us understand the reasoning. AI can write code quickly; the engineer still frames the problem and owns the result. That also shapes how I approach AI-assisted development and review.

Before moving on, the candidate creates a pull request for the work. A reviewable change is part of the expected outcome.

03. Review the work 20 minutes

We look at the pull request together. Did the candidate review their own diff? Does the change address the selected issue? What did they verify, and why did they trust the agent's choices?

The discussion follows the work: why this library, why validate input this way, what is missing, and what would you change? I ask for concise answers so we can explore several decisions.

One candidate worked on three issues and later struggled to separate them into pull requests. That opened a useful discussion about planning and reviewable changes. One pull request can be appropriate, but unrelated changes can make review, release and reversal harder.

One issue deliberately describes a crash that does not occur when its steps are followed. A candidate picked it and submitted a change addressing something else. Comparing the pull request with the report revealed the gap. Checking whether a reported problem exists is itself a senior engineering judgement.

Not everyone chooses that issue, so it is one observation rather than a complete score. Different paths create different opportunities to demonstrate a habit.

04. Explore the codebase 15 minutes

We move beyond the candidate's changes and look at the existing code. I might point to an API and ask: what is missing, and what would you improve if you had more time?

We can have the same conversation about the frontend or app. The questions follow the candidate's experience and the role, and the expected depth differs between senior and principal candidates. We are looking for the concepts and trade-offs behind their suggestions.

05. Quick technical questions 5 minutes

We ask a few short questions about engineering fundamentals relevant to the role. These are quick exchanges, with concise answers, so we can check breadth without turning the session into a lecture.

06. Candidate questions 5 minutes

The candidate has time to ask their own questions. They should leave with space to understand the role and the team, as well as an opportunity to clarify anything from the session.

This live coding session is one stage of the process. A separate 60-minute system design interview follows its own format.

Keep improving the process

This format gives me a view of how an engineer chooses, communicates, verifies and ships with AI tools available. It also gives candidates context and room to show how they work.

I keep adjusting the exercise after interviews. AI workflows will change. The standard remains: the engineer owns the outcome.