"Review this PR / diff"

Some teams replace a coding round with a code review. They want to see what you notice + how you communicate. Both matter — a correct review delivered badly still fails the round.

First, the vocabulary — every term, defined

Before the strategy, lock down the words, because the interviewer will use them as if you already know them. None of this requires prior team experience — it is just naming the parts.

• Code review — the practice of one engineer reading another engineer's proposed change before it merges into the shared codebase, to catch problems early and keep quality high. It is the most common gate in professional software: almost nothing ships without at least one other human (or now, a model) reading it.
• The review round — the interview format where you play the reviewer. You are given a finished change and asked to talk through it aloud: what is good, what is wrong, what you would ask the author, and whether you would approve. There is usually no coding from scratch; the skill on test is judgment, not typing speed.
• PR (pull request) — a bundled set of changes (often across several files) that an author "requests" be "pulled" into the main branch. It comes with a title, a description of intent, the file changes, and a discussion thread. (GitLab calls the same thing a "merge request" — MR.)
• Diff — the line-by-line before/after view of the change. Removed lines are marked - (usually red), added lines + (usually green), unchanged context lines are shown plain for orientation. Reviewing the diff, not the whole file, keeps you focused on what actually changed.
• What to look for — the standard checklist, in priority order: correctness (does it produce the right result?), edge cases (empty input, zero, negatives, nulls, the very first and very last element, duplicates, huge input), readability (can the next person understand it in 30 seconds?), security (can untrusted input cause harm?), performance (does it scale, or is it secretly slow?), and tests (is the new behavior actually verified?).
• Severity levels — how badly a problem matters. A blocking issue must be fixed before merge (a real bug, a security hole, a missing critical test). A nit (short for "nitpick") is a minor, optional suggestion (naming, formatting, a slightly tidier line) that should never hold up the change. Calling out which is which is the single most important communication move in a review.
• Giving feedback kindly + specifically — comment on the code, never the person ("this loop re-reads the file each iteration," not "you didn't think this through"). Be concrete enough to act on, and where possible suggest the fix. Kind and specific are not in tension — specificity is a kindness, because vague criticism is the frustrating kind.

A plain-English on-ramp: you already do this

The six things to look for, expanded

The pass order above is the skeleton. Here is what each pass actually means when your eyes are on real code, with the concrete questions to ask yourself.

Worked review: a small, smelly snippet

Here is the part that turns the checklist into a skill. Below is a tiny, realistic function someone has put up for review — "given a list of orders, return the average order total for a given customer." It runs. It even has a test that passes. Read it the way a reviewer would, top to bottom, before scrolling to the findings.

# PR: add average_order_total(orders, customer_id)
def average_order_total(orders, customer_id):
    seen = []
    total = 0
    count = 0
    for o in orders:
        if o["customer"] in seen:      # dedupe customers we've counted
            continue
        seen.append(o["customer"])
        if o["customer"] == customer_id:
            total = total + o["amount"]
            count = count + 1
    return total / count

# the test that "passes"
def test_avg():
    orders = [{"customer": 1, "amount": 100}]
    assert average_order_total(orders, 1) == 100

It looks innocent and the test is green. Now the review, organized by severity — blockers first, nits dead last, each with a suggested fix phrased the way you'd actually write it in the thread.

How to phrase it (kind + specific)

The same finding can land as helpful or as hostile depending on wording. The pattern that works: name the issue on the code, explain the why/cost, and offer a fix or a question.

What interviewers reward — and the pitfalls