Code Review Interview Practice: Reviewing AI-Written PRs

Some coding interviews hand you a pull request instead of a blank file. You read someone else's change, find what is wrong with it, and explain what should happen next. More and more often, the "someone" is an AI. This guide covers where these rounds show up, what graders look for, and a routine you can practice. It is part of our AI coding interview overview.

Practice it on AICodingRound. Our review problems are real pull requests written by an AI, inside working apps: you comment on lines, prove findings by running the tests, then approve or request changes. Start with Review the AI's profile-editing PR (easy, about 10 min). The beta is free and places are limited: get a place.

Where review rounds show up

A few companies describe the round in public. Others are known only from candidate reports, which we label as such.

• GitLab (company page). For some positions, the technical interview "revolves around a merge request to a small application created for the interview." You get the link at least 72 hours before the call, are asked to spend up to an hour reviewing it, and should finish at least 24 hours ahead. The call is 90 minutes: you walk through your review and write some code to improve the merge request. The page also says: "We encourage the use of AI in the interview process." (GitLab handbook, last modified August 19, 2026)
• Canva (company blog). Canva replaced its CS Fundamentals screen with an AI-assisted coding round for backend and frontend roles. One of the questions it asks about candidates: "Can they identify and fix issues in AI-generated code?" In its list of what successful candidates did: "Critically reviewed and improved AI-generated code." (Canva Engineering, June 11, 2025)
• Anthropic (candidate report). A first-person account on PracHub, edited by the site, describes an onsite round with four pull requests and Claude Code allowed: explain and comment on every PR, then improve one. (PracHub, September 7, 2026; reported, not confirmed by Anthropic.) Anthropic's own guidance says live interviews use no AI "unless we indicate otherwise," so expect to be told clearly when AI is allowed (Anthropic).
• Indeed (older candidate report). A 2022 Blind thread describes "a standard merge/pull request style code review" where you comment in the UI and graders look for "both technical correctness and following best coding practices." (Blind; reported, and old.)

What graders look for

Put those descriptions side by side and the same four things come up.

1. Did you find the problems that matter? Correctness first, then security and data loss, then everything else. A review full of naming nits that misses a real bug is a failed review.
2. Did you check, or guess? A claim like "this breaks for empty input" is stronger when you ran it. GitLab's format even asks you to write code during the call.
3. Can people act on your comments? GitLab says the round looks at how you communicate asynchronously. A comment should say what is wrong, why it matters, and what to change.
4. Did you make a call? End with a decision, approve or request changes, and a short summary.

How AI-written PRs fail differently

AI-written code tends to look tidy. It has good names, docstrings and a confident PR description. That makes some failure modes easier to miss.

• The description promises more than the diff does. "Handles all edge cases" is a claim, not a fact. Check each claim in the description against the code.
• Things that do not exist. In a study of 576,000 code samples from 16 models, the share of recommended packages that did not exist averaged at least 5.2% for commercial models and 21.7% for open-source models (Spracklen et al., USENIX Security 2025). The same habit shows up as calls to functions or options that are not in the library version you use.
• Security gaps in working code. Veracode tested more than 100 models on 80 coding tasks and found the generated code introduced security vulnerabilities in 45% of cases. Its summary: "models are getting better at coding accurately but are not improving at security" (Veracode, July 30, 2025).
• Tests that mirror the code. When the same AI writes the change and its tests, the tests often check what the code does, not what the ticket asked for. Read the tests against the ticket, not against the code.
• Only the happy path. Error handling, retries, time zones, money rounding and permissions are where the quiet bugs live.
• Clean code that ignores the house rules. The change may be fine in isolation and still break the project's contract for errors, money or idempotency. Read the project docs before you approve.

A 20-minute review routine

Here is a routine for a medium-sized PR. Scale the minutes to the round.

1. Minutes 0 to 3: the goal. Read the ticket and the PR description. Write one sentence: "This PR should..." Note every claim the description makes.
2. Minutes 3 to 6: the map. Skim the list of changed files. Find the riskiest one: anything that moves money, checks permissions, writes data or talks to another service.
3. Minutes 6 to 12: the risky lines. Read the risky file line by line. Follow one real request from start to end. Check each claim from step 1.
4. Minutes 12 to 16: proof. Run the tests. If you suspect a case, write a quick test or send one request to prove it. One proven bug is worth three suspicions.
5. Minutes 16 to 20: write it up. Comments on the exact lines, then a decision and a two-line summary.

If you have an AI assistant, use it to read faster: "Where is this function called?" or "What does the provider's doc say about retries?" Then confirm its answer in the code before you write a comment based on it.

How to write a comment

Google's public code review guide gives a simple rule: label how serious each comment is, so the author knows what must change. Its labels are "Nit:" for minor things, "Optional (or Consider):" for suggestions, and "FYI:" for ideas for later. It also says to comment on the code, not the developer, and to explain why (Google eng-practices).

In an interview, add one more label for the things that must change: Blocking. A good blocking comment has three parts:

• What is wrong: "This parses dates month-first for every user."
• Why it matters: "Customers in the UK send day-first dates, so 03/04 becomes March 4 and their invoices are due a month late."
• What to change: "Use the account's locale, and add a test with a day-first date."

Keep nits short and few. If you have ten nits and one blocking bug, the bug should be the first thing the interviewer reads.

Practice set on AICodingRound

These are real pull requests written by an AI, inside working multi-file apps, from our library. Each one asks you to comment on lines and then approve or request changes.

• Review the AI's profile-editing PR (easy, about 10 min). A short warm-up.
• Review the AI's retry PR (medium, about 10 min). A retrying HTTP client with flaws to find.
• Review the AI's webhook-signature PR (medium, about 10 min). Is the security fix actually safe? Check it against the provider's docs.
• Review the AI's reminders PR (medium, about 30 min). A feature PR in a booking API. Don't take the description's word for it.
• Review the AI's percentage-refunds PR (medium, about 35 min). A change that moves real money, with a contract to check it against.

Start with a 10-minute drill to learn the review tools, then do the 30-minute reminders PR with the routine above.

The workspace is checked out on the PR branch, so you can run the tests and, in the larger apps, call the API to prove a finding. When you submit, your comments and decision are checked against the problems we know the PR has, and a short debrief asks about your review. The report gives a level per skill (Strong, Solid or Developing), including how you used AI. Your own Claude or Codex is there as a coach: it reads code and explains, but it does not write your review.

Do one review a day for a week and the routine becomes habit. The beta is free and places are limited: get a place.

Interviewers who let you use AI often ask how you checked its output. Our guide to the HackerRank Chakra AI interview covers how to answer that question.