5 exercises — writing focused review requests, setting scope, following up without friction, and asking for specialist reviews.
0 / 5 completed
1 / 5
You need a code review on a 400-line PR. Which message to your colleague is most effective?
An effective review request gives the reviewer exactly what they need to say yes and prepare: PR reference (PR #412), scope summary (auth refactor, 400 lines), focus area (token validation logic with file path and lines), deadline (Thursday), and a low-friction offer (10-min walkthrough). Option A is too vague and signals low urgency. Option C is vague about what to focus on. Option D is urgent but provides no context — urgency without context creates friction.
2 / 5
Complete the review request: "I've opened PR #88. The main change _____ (refactor) the retry logic in api/client.ts. I _____ (appreciate) a quick look at the error-handling path specifically — it _____ (be) the riskiest part."
Present simple (refactors) describes what the PR does as a fact — this is the standard way to describe code changes ("this function returns…", "this PR adds…"). Would appreciate is polite conditional phrasing for a request. Is (present simple) states the current risk assessment. "Is refactoring" (present continuous) would imply an ongoing action in progress right now, which is not the case. "Has refactored" (present perfect) works for completed actions but sounds more formal/distant here.
3 / 5
Your PR has been open for 4 days with no review. Which follow-up is most professional?
The best follow-up is specific, actionable, and friction-reducing. Option C: names a person (@alice so she gets notified), references the PR and its name, states days open without sounding accusatory, gives a concrete deadline with a clear window (reviewed by EOD Wednesday → Thursday merge), offers help inline or via call, and offers to restructure if size is the blocker. Option A sounds frustrated. Option B is abrupt and uses "Blocking" in a pressuring way without empathy. Option D is passive — it just states existence without giving any reason to act.
4 / 5
You're asking for a security-focused review of an OAuth implementation. What do you include that you wouldn't include in a regular review request?
Security reviews require explicit scope and a threat surface checklist. Instead of saying "be careful", list the specific attack vectors or invariants to verify: token expiry handling, PKCE flow, scope validation, redirect URI whitelist. This lets the reviewer know exactly what to look for and signals that you've already thought about the risks. Option A dumps theory, not a useful direction. Option C is too vague — "be extra careful" doesn't help a reviewer know what to look for. Option D is an organizational gatekeeping preference, not a communication technique.
5 / 5
Choose the correct phrasing to request a review asynchronously: "I don't _____ (need) you _____ (finish) it today — any time before Thursday _____ (work) for me. If anything _____ (look) confusing, leave a comment and I'll clarify."
Don't need + to-infinitive (don't need you to finish) is the correct negative request structure in English. Any time before Thursday works uses present simple for a statement of current preference/condition. If anything looks confusing uses present simple in the if-clause (not "is looking" — continuous is not used for perception/state verbs like look in this sense). "Will work" (option B) would also be grammatically possible, but present simple is more natural for a standing arrangement. "Looked" (past) is wrong — the confusion hasn't happened yet.