Ask useful questions in your first backend review
Ask precise backend review questions about identity, partial updates and external effects, even while learning the codebase.
You can ask useful questions in a backend review before you know every library in the repository. Start with the behavior the change promises, then identify which assumptions you cannot verify. I value a specific question with a concrete failure case more than a confident comment that repeats a pattern from an unrelated codebase.
Imagine reviewing a hypothetical account-update endpoint. The patch lets a user change a display name and email address. You understand the form, but the service’s identity and transaction conventions are unfamiliar. That is enough context to begin a careful review without pretending to have completed a security audit.
Read the change from the caller’s perspective
Find the accepted input, the caller identity and the record being changed. Does the endpoint derive the account from the authenticated session, or accept an account identifier in the request? If it accepts an identifier, where is the permission to update that account checked?
A useful review question might be: “What prevents this request from updating another account if the identifier is changed? I found the input validation, but I have not found the object-level permission check.” The question states what you inspected and what evidence is missing. It does not accuse the author of a vulnerability before the surrounding code has been examined.
The Google review guide covers design, functionality, complexity and tests. Those categories help organize an unfamiliar patch. You can review the observable contract while asking a domain expert to confirm repository-specific conventions.
Separate questions by the decision they affect
For the account example, the most useful questions might look like this:
| Question | Why it matters to this change |
|---|---|
| Which identity chooses the updated account? | Input validation alone does not establish permission |
| Does email change require verification? | The product may distinguish a requested address from a trusted address |
| Which fields change together? | A partial update may leave an unintended account state |
| What happens after a lost response? | A retry may repeat notifications or another side effect |
| Which existing clients depend on the response? | An apparently local change may alter a shared contract |
These questions are not a universal checklist that certifies an endpoint. They are tied to the fields and behavior in this patch. A profile-photo update or password-reset flow would deserve different attention.
The diagram keeps external effects separate from the database write. A transaction around account fields does not automatically make a verification email atomic with those changes. The review needs to understand how the application handles that gap.
Ask for a behavior example
If the implementation is difficult to follow, request a concrete case. “What should happen when the new email is already used?” gives the author a result to explain. Then locate the validation, database constraint and test that establish that result.
Suppose the test only checks that the endpoint returns a response. That is weaker than checking the expected status, stored values and absence of a prohibited side effect. Explain the missing evidence rather than asking for “more tests” without a purpose.
A small table of cases can help both people agree on the contract before debating implementation details. Include one ordinary update, one invalid value and one relevant conflict. If a case depends on an unstated product rule, name the decision owner instead of inventing the rule in a review comment.
Make the comment easy to answer
The Google guidance on review comments recommends explaining reasoning and treating the developer respectfully. A comment should help the author understand the consequence you are concerned about and what would resolve it.
Compare “This is wrong; use a transaction” with “The display name is saved before the email uniqueness check finishes. If the second write fails, should the first change remain? If the operation is meant to be atomic, could we test that partial-failure case?” The second comment exposes the requirement and leaves room for an existing mechanism you may have missed.
Distinguish a blocking correctness concern from a suggestion about naming or organization. A reviewer unfamiliar with the codebase should be especially careful not to turn personal preference into a requirement. At the same time, uncertainty is not a reason to ignore a concrete risk.
Close the learning loop
After the author responds, inspect the referenced mechanism and revise your understanding. If authorization lives in a shared service wrapper, follow that path for this endpoint and record what it guarantees. If the patch changes, read the new diff and rerun or inspect the relevant check according to the review process.
Keep one reusable lesson from the exchange, such as “this repository derives account ownership in the service boundary” or “this endpoint deliberately separates requested and verified email addresses.” Avoid generalizing it into a rule for every project.
The limitation of a first review is real: you may miss behavior that an experienced maintainer would notice. Pairing with that maintainer can improve the review while giving you a concrete model to reuse. Your contribution is the careful question, the inspected evidence and the willingness to update the conclusion when the code answers it.
Trace a requested address through verification
Extend the account example with a proposed product rule: a requested email address does not become the trusted address until verification succeeds. The review should identify separate meanings for the currently verified address, the pending address and the pending change identity. Those meanings need not imply particular column names, but the implementation must preserve the distinction.
Suppose the account currently trusts E0. The user requests E1 under change C1, then requests E2 under C2 before using the first verification link. For this exercise, the agreed rule is that C2 supersedes C1. A link belonging to C1 must not verify E2 merely because E2 is now the pending address.
A precise comment is: “The verification handler reads the current pending email after finding this token. Which check binds the token to the exact requested change? Could we exercise C1, then C2, then the older C1 link and confirm that E0 remains verified?” The comment names the sequence and expected result without prescribing a token format.
The example is a product-policy exercise, not a complete email-verification design. Token unpredictability, expiry, one-time use, account binding and the surrounding authentication flow need appropriate security review. Asking one good stale-link question does not cover all of those obligations.
Follow the evidence through the changed call path
An author may answer that a shared wrapper performs authorization or that an existing transaction helper makes both account writes atomic. Follow the actual endpoint through that wrapper or helper. Similar code elsewhere and a passing unit test for the helper do not establish that this changed route invokes it with the right inputs.
Keep a small evidence map. For ordinary input, identify the expected stored account and response. For another account’s identifier, locate the deny path and check that no account or notification changes. For a conflicting address, identify whether neither field changes or whether the product deliberately accepts part of the request. For the C1/C2 sequence, find the pending-change comparison at verification.
This map is more useful than counting test files. A test can execute the changed line and still fail to assert the behavior under discussion. Conversely, an existing integration test may already demonstrate the case, so asking for another almost identical test adds little. Read what the evidence establishes before requesting a new fixture.
After a revision, inspect the changed path again. A fix might move authorization earlier but accidentally skip it for a second entry point. Narrowly rereading the patch and its callers is a concrete review task; claiming to have re-audited the whole service is a much larger one.
State what blocks approval and what can follow
The Google code-review standard favors changes that improve overall code health without requiring perfection. It also distinguishes technical evidence from preference and allows educational comments that are clearly nonmandatory. That gives a new reviewer a way to be both careful and useful.
For the account patch, an unresolved path that can update the wrong account is a correctness concern that needs resolution. A question about where the established wrapper is called is a request for evidence; once answered and inspected, it may require no code change. A suggestion to rename a local variable can follow the repository’s style rules without holding up a correct behavior change.
Record the conclusion at the same scope as the work: which cases were inspected, which explanation resolved the question and whether a specialist still needs to review an unfamiliar boundary. The goal is an understandable decision about this patch. You can learn from the exchange without turning every useful observation into another requirement for the author.