Code Review Interviews: How to Ace the "Review This Pull Request" Round

More companies now replace or supplement algorithm puzzles with a code review exercise: you get a pull request, sometimes with a short product description, and 30 to 60 minutes to review it while talking through your thinking. It is closer to real work, and it rewards a specific set of habits. What interviewers are looking for - Can you understand unfamiliar code quickly? - Do you prioritize: correctness and security before style? - Is your feedback kind, specific, and actionable? - Do you ask questions instead of assuming intent? A repeatable review order 1. Read the description first. What problem is the change solving? What would "done" look like? If there is no description, say that a real PR would need one; it is a valid first comment. 2. Skim the whole diff before commenting. Get the shape: which files changed, where the core logic lives, what is test code. 3. Check correctness. Walk through the main path with a concrete input. Then try edge cases: empty collections, nulls, very large inputs, concurrent calls, time zones, retries. 4. Check security and data handling. Look for unvalidated input, SQL built with string concatenation, secrets in code, missing authorization checks, and sensitive data in logs. 5. Check reliability. Error handling, timeouts on network calls, idempotency for retried operations, resource cleanup. 6. Check tests. Do they cover the new behavior and at least one failure case? Would they fail if the bug you suspect were present? 7. Only then comment on readability: naming, duplication, function size, comments that explain why rather than what. How to phrase comments Label severity so the author knows what blocks merge: - "Blocking: this query interpolates user input; please use parameters." - "Suggestion: extracting this into a helper would make the retry logic testable." - "Nit: consider a more descriptive name than data2." - "Question: is this endpoint called by the mobile app too? If so, the response shape change may break it." Interviewers notice when you separate must-fix issues from preferences. Common traps - Spending ten minutes on formatting while missing an off-by-one in pagination. - Rewriting the whole design in comments instead of reviewing the change in front of you. - Being harsh. Tone is part of the evaluation because it predicts how you will treat teammates. - Staying silent. Narrate what you are checking even when you find nothing. Practising Pick open-source PRs in a language you know, review them on your own with a timer, then compare with the maintainers' comments. You will quickly see which issues experienced reviewers catch first. Help in the live round Because this round is conversational, follow-up questions like "How would you test this?" can arrive at any moment. Some candidates use Linkjob AI (https://linkjob.ai), which gives real-time help during live job interviews and technical interviews, to keep their review structured while they talk. A strong code review interview looks like a calm senior colleague at work: understand the goal, find what matters most, and explain it clearly and respectfully.