How to approach an AI-assisted coding interview

First, establish what “AI interview” means

An AI-assisted coding interview is a programming exercise in which the employer explicitly permits some use of an AI tool. It is different from interviewing for a machine learning role, and different from an automated interviewer asking you questions. Those formats can overlap, but they demand different preparation. Start with the instructions for your specific round.

Ask which tools are allowed, whether the tool is provided, what you may share with it, and whether the task starts from an existing repository. Also ask whether you will share your screen, whether documentation access is permitted, and what happens if the tool stops working. A company experimenting with AI in one assessment has not necessarily authorized it throughout its hiring process.

The workflow below is our suggested rehearsal for an explicitly AI-enabled repository exercise. It is not a description of every employer’s rubric or an actual company question. For the policy details, read the separate Microsoft and Amazon articles.

Prepare the environment before practicing speed

Use a language in which you can read unfamiliar code without constantly translating syntax. Practice opening a repository, finding the test command, following a call into another file, reading a diff, and reverting one change. These mundane operations become expensive when you are also explaining your reasoning aloud.

Rehearse with the tool and permissions you expect to have. If the assessment supplies a browser editor, being fast in your personal editor is not enough. If you may use your own assistant, check authentication and usage limits beforehand. Ask about a fallback; do not spend the opening minutes of a real interview trying to obtain access to another service.

Keep a small working note with four headings: requirement, current behavior, evidence, next check. This is a way to retain context when an AI response is long or the interviewer changes a constraint. Do not prepare a hidden answer script. The note should reflect the problem in front of you.

Use the first few minutes to form a testable contract

Consider this original practice task: a document search endpoint sometimes returns fewer results than requested, even when more visible documents exist. The repository contains a route handler, a search service, an authorization helper, and tests. The request says to fix pagination without changing which documents a user may see.

Before editing, turn that sentence into observable behavior. A response should include up to the requested number of documents the user can access, in the specified order. Inaccessible documents should not consume the visible result limit. An empty page, repeated cursor, and final page need defined behavior. Ask whether the total count refers to all matches or only visible matches.

Explain your first hypothesis without presenting it as fact: “The limit may be applied before authorization. I’ll trace where filtering and pagination happen, then construct a case that separates those two orders.” That sentence tells the interviewer what you intend to learn. It also gives the assistant a much better task than “fix pagination.”

Trace one request instead of reading every file

Find the entry point and follow one request to its result. Read the request type, the function that builds the candidate list, the authorization predicate, and the existing tests around those boundaries. Run the relevant baseline tests before editing. A failing baseline is useful information: it distinguishes the supplied problem from a regression you introduce.

An assistant can help locate code, but verify its map by opening the files. A function named “filterResults” might filter relevance rather than permissions. Generated explanations can be plausible while describing an older implementation or a different layer. GitHub’s Copilot Chat documentation explicitly places responsibility for validating generated responses on the user.

In the example, suppose you find matches.slice(0, limit).filter(canRead). This supports the hypothesis, but does not yet settle the cursor contract. Read the caller before changing the order. If the cursor refers to the unfiltered candidate stream, moving one line may fix page size while breaking continuation.

Trace a search request from the route to the returned page.
Identify where permissions, ordering, limit, and cursor are applied.
Show the relevant files and functions. Do not edit yet.
Separate observed behavior from assumptions about the intended contract.

Give the assistant one decision at a time

Break work into questions that you can evaluate: locate the behavior, propose a regression, explain a repair, then implement the smallest agreed change. This does not mean every edit needs four prompts. It means the assistant should not decide the requirement, change production code, and redefine success in a single opaque step.

Once you confirm that the existing cursor identifies the last scanned candidate, preserve that convention: resume after that position, scan in the established order, and collect only readable documents until the visible limit or the end of the candidate stream. Advance past every scanned item, including private ones, and encode the last scanned position using the existing opaque format. For A-private, B-visible, C-visible, D-visible with limit two, page one returns B and C; its cursor resumes before D. Verify page two returns D without repeating B or C. If the service caps how much it scans in one request, clarify how a partial page signals continuation instead of silently promising a full page.

Give it the concrete fixture: candidate A is inaccessible; B and C are visible; the requested limit is two. If the contract is to return two visible matches, expect B and C. Ask for a test at the service boundary so that a correct helper wired into the wrong caller still fails.

Read the proposed assertion. A test asserting that every returned item is readable does not prove the page is full. A test asserting only length two can pass while leaking A. Check identity, ordering, and continuation when they are part of the contract. If the assistant writes an assertion that merely repeats its implementation, replace it with an independently calculated expectation.

Add a regression for candidates [private-A, visible-B, visible-C],
limit=2, with the current user allowed to read only B and C.
Assert returned IDs are [B, C], in that order.
Use the existing service API and test style.
Do not change production code or loosen existing assertions.

Treat the patch and the test output as separate evidence

Read the diff before accepting it. Did the assistant alter authorization, change the meaning of the cursor, introduce a dependency, or catch an exception that used to propagate? A green test run does not make those changes part of the assignment. If the patch is too broad, keep the useful test and ask for a narrower implementation.

Run the new regression on the original behavior and check that it fails for the intended reason. Apply the repair, rerun that regression, then run relevant existing tests and the build or typecheck. If a command fails because a dependency is unavailable, report that as an environment limitation rather than claiming the behavior was verified.

Finish with a deliberate adversarial check. For pagination, try no visible results, a boundary exactly at the limit, a final partial page, and an inaccessible item between two visible ones. You do not need an enormous test suite. You need cases that distinguish your intended behavior from a plausible wrong implementation.

Narrate decisions, not every keystroke

Continuous commentary can make it harder to think. Instead, explain transitions: your current hypothesis, the evidence that changed it, and why you chose the next action. Give the interviewer enough information to follow your judgment without reading your entire chat transcript.

For example: “The new regression shows that the visible limit is applied too early. The suggested patch also changes cursor encoding; I’m removing that part because the existing caller depends on it. I’ll verify a second page before calling the fix complete.” This makes a rejection useful evidence of understanding rather than a performance of skepticism.

Be ready to explain a generated line without asking the model. Walk through one input by hand, describe complexity at the relevant scale, and name the invariant it preserves. If you cannot do that, pause and investigate. An assistant can help you learn an API, but its explanation is another claim to check, not a substitute for your own account of the result.

Keep time for verification and a handoff

For a 45-minute practice session, try spending the first five minutes clarifying the contract, the next seven tracing code and running a baseline, about eighteen reproducing and fixing the issue, ten verifying boundaries, and the last five explaining the result. This is a rehearsal budget, not a company’s prescribed timing. Adjust it to the task and the time actually available.

If the assistant spends several minutes going in circles, change the method. Reduce the prompt to the smallest failing input, inspect the function yourself, or implement the small correction directly. Repeating “try again” without adding evidence consumes time without reducing uncertainty.

With five minutes left, favor a coherent, explained partial solution over an unreviewed rewrite. Say what works, which command supports that claim, and what remains unverified. If you would need a transaction or a different cursor design for a production version, explain the reason and the scope boundary rather than quietly introducing it at the end.

Practice the decisions that survive a change of model

Repeat one small repository exercise three ways. First work without AI to find where your understanding is weak. Then allow AI for navigation and test generation while you implement. Finally use it for a patch, but require yourself to reject or revise anything that does not meet the contract. Compare the quality of your evidence, not just elapsed time.

After each attempt, write a short retrospective: What assumption was wrong? Which test changed my mind? Where did I accept generated output too quickly? What could I explain independently? A useful practice target is “I will test the side effect, not just the return value,” rather than “I will prompt more effectively.”

Use a fresh scenario for the next timed attempt so that memory does not masquerade as skill. nrml’s problem library offers existing repositories for this kind of rehearsal. Pick a topic you can reason about, keep the session small, and use the result to choose one concrete improvement for the next round.