How to review AI-generated code in an interview

Review behavior before polish

In an interview that permits AI assistance, generating a plausible patch is only part of the work. You still need to decide whether it meets the request. An elegant helper can duplicate network calls, swallow failures, or quietly change which records appear in a report.

Even a second AI review is not proof. GitHub’s documentation says Copilot reviews can miss problems and make mistakes, and recommends human validation of their feedback. Use generated findings as leads to investigate. GitHub: validating Copilot code reviews.

The following original practice example develops a review you can reproduce and explain. It is not an employer’s interview question or official scoring rubric. The useful habit is to connect every suspected defect to an observable consequence before asking for a repair.

Write down what a cache hit actually means

Suppose a profile service keeps an in-memory Map. A stored object means the account exists. A stored null means the service already checked and the account does not exist. An absent key means there is no cached answer. Those are three distinct states.

Agree that both stored results count as hits and must avoid an origin request. On a miss, lookup should call the origin, store its successful answer, and return it. A rejected origin request should remain an error; it must not become a cached “account not found” result.

Keep this exercise deliberately small: no expiration, eviction, concurrent request deduplication, or remote cache. Naming these boundaries helps you identify a real defect without treating every omitted production feature as a bug. If the interviewer wants one of those features, expand the contract before expanding the implementation.

Trace the branch that looks harmless

An assistant proposes this JavaScript helper. Read it with a concrete input before changing anything. Seed profiles with account-17 mapped to null. Map.get returns null, the truthiness check fails, and execution reaches origin.lookup.

If the origin also returns null, a test checking only the result passes. The defect is extra work: a cache hit still performs a network lookup. It can increase latency and origin load, or cause an otherwise answerable request to fail during an origin outage.

That distinction is valuable interview evidence. You have identified the condition, the incorrect branch, and an observable consequence. “This conditional looks suspicious” becomes a specific claim someone else can test.

function createLookup(profiles, origin) {
  return async function lookup(id) {
    const cached = profiles.get(id);
    if (cached) return cached;
    const value = await origin.lookup(id);
    profiles.set(id, value);
    return value;
  };
}

Build a regression that observes the extra work

The regression below uses a simple counter as an origin spy. Paste it after the helper in a Node .mjs file, with the import at the top. The two returned values are correct even in the flawed version; the final assertion exposes the two unexpected origin calls.

First run it against the proposed implementation and confirm the failure is specifically 2 versus 0 calls. A syntax error or missing dependency would not establish the bug. After the repair, run the same test unchanged.

Then add a miss case that returns null: the first lookup should call the origin once and the second should use the cached result. This catches a repair that handles preseeded entries correctly but forgets to store negative results.

import assert from 'node:assert/strict';

const profiles = new Map([['account-17', null]]);
let originCalls = 0;
const origin = {
  async lookup() {
    originCalls += 1;
    return null;
  },
};
const lookup = createLookup(profiles, origin);

assert.equal(await lookup('account-17'), null);
assert.equal(await lookup('account-17'), null);
assert.equal(originCalls, 0);

Make the smallest change that preserves the contract

Map.has checks whether a key is present, independently of its stored value. That is the question this helper needs to answer. Replace the truthiness branch with a membership check, leaving the miss path intact. MDN: Map.prototype.has.

For this ordinary in-memory Map, the membership check and read run synchronously without an intervening await. A remote cache would need different reasoning: two separate network operations can observe different states. A single response containing both found and value may be the appropriate API there.

Reject a suggestion to replace null with an empty object. That might silence this particular failure by making the value truthy, but it changes what callers receive. The correct repair preserves the meaning of a missing account and fixes how the cache detects presence.

if (profiles.has(id)) {
  return profiles.get(id);
}

Keep the test’s answer independent of the patch

A model can reproduce the same mistaken assumption in implementation and tests. A test that computes its expected result by calling the new helper again provides little independent evidence. Derive expected values and call counts from the agreed contract, then ask the assistant to help express them.

Use this prompt only with code the interview permits sharing. Review the resulting assertions before running them: cached objects and cached null both require zero origin calls; a new key requires one; a rejected lookup should reject and leave the key absent.

Do not mock the helper you are trying to verify. Replace its external dependency, as the origin spy does, and observe behavior through its public entry point. Keep the setup explicit enough that a reviewer can see why the expectation follows.

The cache stores null as a valid result.
Propose a regression proving a cache hit never calls the origin.
Keep the public return values and error behavior unchanged.
Explain why the test fails on the current implementation.
Do not change existing expected values to make the patch pass.

Explain rejection and control the diff

Make your decision visible: “The assistant’s empty-object workaround changes the API. I’m rejecting it because null is a meaningful result. Membership fixes the branch while preserving callers’ expectations.” This explains the requirement, the rejected alternative, and the reason for your choice.

Inspect every changed file. A cache fix should not quietly introduce a new dependency, reformat the entire service, loosen type checks, or catch all origin errors. Those changes increase the amount of behavior you must verify within the round.

If the patch is too broad, ask for a smaller revision and compare again. Avoid accepting a large change merely because the assistant describes it as cleanup. A concise diff makes it easier for both you and the interviewer to connect the original defect with the repair.

Apply the same review to retries and duplicate effects

Now imagine generated code that retries a booking request whenever a timeout occurs. Trace a specific failure: the server creates the booking, then the response is lost. The client sees a timeout, but the operation has already happened. A second successful response can conceal two bookings.

HTTP guidance cautions against automatically retrying a non-idempotent request unless the client knows the operation is safe to repeat or knows the original was not applied. A timeout alone does not establish either fact. RFC 9110: idempotent methods.

For practice, make a fake server record the effect before throwing a simulated connection error. Assert how many bookings exist after the client handles it. If the exercise defines server-supported idempotency, retries should reuse the same logical-operation key and produce one booking. Adding a header without server behavior is insufficient.

Also inspect attempt limits, cancellation, and the total time budget. The transferable review question is the same as in the cache: what work happened behind the returned value, and which test observes it?

Check the evidence behind an AI-generated report

The same approach helps in an interview that asks you to repair a reporting script. Suppose an assistant reports model accuracy from six records: four have known labels, three of those predictions are correct, and two labels are missing. If the agreed metric covers labeled records, the result is 3/4, with two excluded rows disclosed. Dividing by six answers a different question.

Calculate that tiny fixture by hand before inspecting the generated formula. Check the cohort filter, positive-label definition, threshold equality, missing-label handling, and empty-cohort behavior. A polished chart cannot resolve an undefined denominator.

Then trace where the evidence came from. If the script chooses its threshold using the final evaluation set and reports performance on that same set, it has used the evaluation data to make a modeling choice. Scikit-learn’s documentation warns that test data used in model decisions can produce optimistic estimates. Scikit-learn: data leakage.

In the interview, explain which rows may influence the choice and which rows evaluate it. Test that separation with small, named datasets. This demonstrates review of a generated workflow without turning the exercise into a survey of machine learning theory.

Finish with a result someone can verify

Reserve time to rerun the regression, relevant existing tests, and the project’s appropriate checks. Review the final diff after the last edit. Report commands that could not run separately from successful checks.

A useful closing explanation is concrete: “The helper treated cached null as a miss. The original code made two origin calls in the regression; the repaired code makes zero. Misses still populate the cache and origin failures still propagate. Expiration and concurrent miss deduplication remain outside this exercise.”

Practice that explanation after each mock session. You should be able to identify the contract, demonstrate the failure, justify the smallest repair, and name the evidence supporting it without relying on the assistant’s summary.