Review a Production Pull Request and Calibrate Feedback to the Author's Seniority

You are in the code review round of a staff-level software engineering loop. Instead of solving a puzzle, you are handed a real-world pull request and asked to review it the way you would at work: understand what it is trying to do, find the problems that matter, decide whether it can merge, and write the comments you would actually leave. The interviewer is grading two things at once. The first is the technical quality of your review. The second is your feedback style, and in particular how you would adjust it for engineers at different levels, from someone early in their career to a senior peer. The specific diff used in the interview is not reproduced here. For practice, assume a moderately sized change to a production backend service: some new logic, a few modified call sites, and accompanying tests. Talk through your review out loud as you would in the room. ### Constraints and Clarifications - The change is realistic production code rather than a planted-bug exercise, so the problems you find will vary in severity and some will be judgment calls. - You are expected to produce actual review comments, not only describe a process. - The author's level is a variable: be ready to give feedback on the same PR as if it came from engineers at different levels. ### Clarifying Questions - What does the PR description say it does, and is there a ticket or design doc that defines the intended behavior? - Who opened it: what level is the author, and how familiar are they with this part of the codebase? - How risky is the code path: does it touch data writes, external calls, or anything customer-facing, and is it behind a flag or rolled out gradually? - Is the review written and asynchronous, or will you walk through it live with the author? ### Part 1 — Review the change Walk through how you would review this PR from the moment you open it to your final verdict. Explain what you look at first, which kinds of problems you treat as merge-blocking, how you check the tests, and how you mark each comment so the author can tell a must-fix from a preference. ```hint Order your passes Decide what you need to understand before reading individual lines, and which classes of problem you would hunt for before thinking about style. ``` #### What This Part Should Cover - A deliberate sequence of review passes, from intent and risk down to readability - An explicit bar separating merge-blocking issues from optional suggestions - Scrutiny of the tests and of how the change behaves when things fail in production - A clear, labeled verdict the author can act on ### Part 2 — Calibrate the feedback to the author Pick one serious issue and one minor issue from your review. Write the comment you would leave for each if the PR came from an early-career engineer, then rewrite both as if a senior or staff peer had opened it. Explain what you changed, what you deliberately kept the same, and at what point you would stop commenting and talk to the author directly. ```hint Same finding, different reader Ask what each author most needs from your comment: background, a pointer, a decision, or room to push back. ``` #### What This Part Should Cover - Concrete rewritten comments for both audiences, not just a description of tone - What stays constant regardless of the author's level - How depth of explanation, questions versus directives, and teaching intent shift with level - When to move from written comments to a conversation ### What a Strong Answer Covers - Prioritizes correctness, safety and operability over style, and leaves formatting to tooling - Comments that are specific, actionable and tied to a reason or consequence - Adapts delivery to the reader while holding one quality bar for everyone - Treats review as a way to grow engineers and spread standards, not only to gate code - Respects the author's time: batched feedback, a clear verdict, no drive-by nitpicking ### Follow-up Questions - A senior author pushes back on one of your blocking comments and you are no longer sure you are right. How do you resolve it? - You keep seeing the same class of issue in PRs from different engineers. What do you do beyond commenting on this one? - How would you handle a very large PR that mixes a refactor with a behavior change? - How does your review change when the PR is an urgent fix for an active incident?