Intermediate
Writing
#code-review
#pull-request
#async
Requesting Code Reviews
5 exercises — writing focused review requests, setting scope, following up without friction, and asking for specialist reviews.
0 / 26 completed
1 / 26
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 / 26
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 / 26
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 / 26
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 / 26
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.
6 / 26
You've submitted a PR containing a significant refactor of the user authentication module. The PR is approximately 600 lines long and includes several new tests. You want to request a thorough review from your senior engineer, Sarah, who's currently focused on another project. Which Slack message would be most effective in prompting her attention?
Option 1 is the most effective because it directly calls out the PR's significance (600 lines), specifies the module involved (authentication), and provides a direct link for easy access. It also highlights your concern about potential impact – demonstrating that you've considered the broader implications of the change. Options A and C are too informal, while option D lacks crucial details and doesn't explicitly request a review.
7 / 26
You've just finished implementing a new feature in the payment processing service. Before merging your code, you want to ensure it aligns with the team's existing design patterns and doesn't introduce any unexpected side effects. You need to request a review from David, who is familiar with the codebase but currently working on a high-priority bug fix. Which of the following messages would be most effective in prompting him to take a look?
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
git status
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
The best approach here is to politely request feedback and highlight the specific areas where input is needed. Option 1 frames the request as seeking 'feedback' and specifically mentions integration with existing architecture—demonstrating awareness of potential issues. Options 2 and 3 are overly demanding and lack context, while option 4 is too aggressive and doesn't invite collaboration. A clear, respectful request focusing on alignment will be more likely to get a timely response from a busy colleague.
8 / 26
You've just finished implementing a new API endpoint for retrieving user profile data. The endpoint is roughly 250 lines of code and includes comprehensive unit tests. You need to request a review from Ben, who's currently leading the effort to migrate the backend infrastructure to a serverless architecture. Which message would be most effective in prompting him to consider your changes?
You: "Hey Ben, could you take a look at my new user profile API endpoint? I've focused on robust testing and want to ensure it aligns with our broader serverless migration goals."
The correct answer emphasizes proactive communication and explicitly connects your work to Ben's current priorities – the serverless migration. This demonstrates you value his input and are seeking alignment. Options A is passive, B dismisses collaboration, and C is a generic request without highlighting the important connection between the new code and Ben's project. This approach increases the likelihood of a focused review because it shows respect for Ben's time and expertise.
9 / 26
Your team is preparing to merge a new feature – a complex payment gateway integration – into the core system. The PR is 750 lines long and includes extensive unit tests, but you're aware that John, the senior backend engineer, is deeply involved in debugging a critical production outage. Which of the following approaches would be most effective for requesting a review while acknowledging his current priorities?
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
This scenario highlights the importance of tact and understanding team dynamics when requesting reviews. Option B demonstrates empathy by acknowledging John's busy schedule and offering support without imposing urgency. Options A and C are overly demanding and could be perceived negatively, while option D offers a collaborative approach that respects his priorities and provides an easy way for him to engage.
10 / 26
You've submitted a PR containing a significant refactor of the user authentication module. The PR is approximately 600 lines long and includes several new tests. You want to request a thorough review from your senior engineer, Sarah, who's currently focused on another project. Which Slack message would be most effective in prompting her attention?
Option 1 is the most effective because it directly calls out the PR's significance (600 lines), specifies the module involved (authentication), and provides a direct link for easy access. It also highlights your concern about potential impact – demonstrating that you've considered the broader implications of the change. Options A and C are too informal, while option D lacks crucial details and doesn't explicitly request a review.
11 / 26
You've just finished implementing a new feature in the payment processing service. Before merging your code, you want to ensure it aligns with the team's existing design patterns and doesn't introduce any unexpected side effects. You need to request a review from David, who is familiar with the codebase but currently working on a high-priority bug fix. Which of the following messages would be most effective in prompting him to take a look?
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
git status
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
The best approach here is to politely request feedback and highlight the specific areas where input is needed. Option 1 frames the request as seeking 'feedback' and specifically mentions integration with existing architecture—demonstrating awareness of potential issues. Options 2 and 3 are overly demanding and lack context, while option 4 is too aggressive and doesn't invite collaboration. A clear, respectful request focusing on alignment will be more likely to get a timely response from a busy colleague.
12 / 26
You've just finished implementing a new API endpoint for retrieving user profile data. The endpoint is roughly 250 lines of code and includes comprehensive unit tests. You need to request a review from Ben, who's currently leading the effort to migrate the backend infrastructure to a serverless architecture. Which message would be most effective in prompting him to consider your changes?
You: "Hey Ben, could you take a look at my new user profile API endpoint? I've focused on robust testing and want to ensure it aligns with our broader serverless migration goals."
The correct answer emphasizes proactive communication and explicitly connects your work to Ben's current priorities – the serverless migration. This demonstrates you value his input and are seeking alignment. Options A is passive, B dismisses collaboration, and C is a generic request without highlighting the important connection between the new code and Ben's project. This approach increases the likelihood of a focused review because it shows respect for Ben's time and expertise.
13 / 26
Your team is preparing to merge a new feature – a complex payment gateway integration – into the core system. The PR is 750 lines long and includes extensive unit tests, but you're aware that John, the senior backend engineer, is deeply involved in debugging a critical production outage. Which of the following approaches would be most effective for requesting a review while acknowledging his current priorities?
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
This scenario highlights the importance of tact and understanding team dynamics when requesting reviews. Option B demonstrates empathy by acknowledging John's busy schedule and offering support without imposing urgency. Options A and C are overly demanding and could be perceived negatively, while option D offers a collaborative approach that respects his priorities and provides an easy way for him to engage.
14 / 26
You've submitted a PR containing a significant refactor of the user authentication module. The PR is approximately 600 lines long and includes several new tests. You want to request a thorough review from your senior engineer, Sarah, who's currently focused on another project. Which Slack message would be most effective in prompting her attention?
Option 1 is the most effective because it directly calls out the PR's significance (600 lines), specifies the module involved (authentication), and provides a direct link for easy access. It also highlights your concern about potential impact – demonstrating that you've considered the broader implications of the change. Options A and C are too informal, while option D lacks crucial details and doesn't explicitly request a review.
15 / 26
You've just finished implementing a new feature in the payment processing service. Before merging your code, you want to ensure it aligns with the team's existing design patterns and doesn't introduce any unexpected side effects. You need to request a review from David, who is familiar with the codebase but currently working on a high-priority bug fix. Which of the following messages would be most effective in prompting him to take a look?
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
git status
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
The best approach here is to politely request feedback and highlight the specific areas where input is needed. Option 1 frames the request as seeking 'feedback' and specifically mentions integration with existing architecture—demonstrating awareness of potential issues. Options 2 and 3 are overly demanding and lack context, while option 4 is too aggressive and doesn't invite collaboration. A clear, respectful request focusing on alignment will be more likely to get a timely response from a busy colleague.
16 / 26
You've just finished implementing a new API endpoint for retrieving user profile data. The endpoint is roughly 250 lines of code and includes comprehensive unit tests. You need to request a review from Ben, who's currently leading the effort to migrate the backend infrastructure to a serverless architecture. Which message would be most effective in prompting him to consider your changes?
You: "Hey Ben, could you take a look at my new user profile API endpoint? I've focused on robust testing and want to ensure it aligns with our broader serverless migration goals."
The correct answer emphasizes proactive communication and explicitly connects your work to Ben's current priorities – the serverless migration. This demonstrates you value his input and are seeking alignment. Options A is passive, B dismisses collaboration, and C is a generic request without highlighting the important connection between the new code and Ben's project. This approach increases the likelihood of a focused review because it shows respect for Ben's time and expertise.
17 / 26
Your team is preparing to merge a new feature – a complex payment gateway integration – into the core system. The PR is 750 lines long and includes extensive unit tests, but you're aware that John, the senior backend engineer, is deeply involved in debugging a critical production outage. Which of the following approaches would be most effective for requesting a review while acknowledging his current priorities?
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
This scenario highlights the importance of tact and understanding team dynamics when requesting reviews. Option B demonstrates empathy by acknowledging John's busy schedule and offering support without imposing urgency. Options A and C are overly demanding and could be perceived negatively, while option D offers a collaborative approach that respects his priorities and provides an easy way for him to engage.
18 / 26
You've submitted a PR containing a significant refactor of the user authentication module. The PR is approximately 600 lines long and includes several new tests. You want to request a thorough review from your senior engineer, Sarah, who's currently focused on another project. Which Slack message would be most effective in prompting her attention?
Option 1 is the most effective because it directly calls out the PR's significance (600 lines), specifies the module involved (authentication), and provides a direct link for easy access. It also highlights your concern about potential impact – demonstrating that you've considered the broader implications of the change. Options A and C are too informal, while option D lacks crucial details and doesn't explicitly request a review.
19 / 26
You've just finished implementing a new feature in the payment processing service. Before merging your code, you want to ensure it aligns with the team's existing design patterns and doesn't introduce any unexpected side effects. You need to request a review from David, who is familiar with the codebase but currently working on a high-priority bug fix. Which of the following messages would be most effective in prompting him to take a look?
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
git status
'Hey David, could you take a quick spin through my payment processing changes? I'm particularly keen to get your feedback on how it integrates with the existing architecture.' 'David, just wanted to flag that I've made some changes to the payment service. It should be ready for review in about an hour.' 'Hi David, please review my PR when you have a moment – it's pretty urgent!'
The best approach here is to politely request feedback and highlight the specific areas where input is needed. Option 1 frames the request as seeking 'feedback' and specifically mentions integration with existing architecture—demonstrating awareness of potential issues. Options 2 and 3 are overly demanding and lack context, while option 4 is too aggressive and doesn't invite collaboration. A clear, respectful request focusing on alignment will be more likely to get a timely response from a busy colleague.
20 / 26
You've just finished implementing a new API endpoint for retrieving user profile data. The endpoint is roughly 250 lines of code and includes comprehensive unit tests. You need to request a review from Ben, who's currently leading the effort to migrate the backend infrastructure to a serverless architecture. Which message would be most effective in prompting him to consider your changes?
You: "Hey Ben, could you take a look at my new user profile API endpoint? I've focused on robust testing and want to ensure it aligns with our broader serverless migration goals."
The correct answer emphasizes proactive communication and explicitly connects your work to Ben's current priorities – the serverless migration. This demonstrates you value his input and are seeking alignment. Options A is passive, B dismisses collaboration, and C is a generic request without highlighting the important connection between the new code and Ben's project. This approach increases the likelihood of a focused review because it shows respect for Ben's time and expertise.
21 / 26
Your team is preparing to merge a new feature – a complex payment gateway integration – into the core system. The PR is 750 lines long and includes extensive unit tests, but you're aware that John, the senior backend engineer, is deeply involved in debugging a critical production outage. Which of the following approaches would be most effective for requesting a review while acknowledging his current priorities?
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
Option A: 'Just pushing this through – it's ready for review!'
Option B: 'Hey John, could you take a look at the new payment gateway integration when you have a moment? I've focused on thorough testing and would appreciate your input.'
Option C: 'This PR is blocking deployment. Please prioritize reviewing it ASAP.'
Option D: 'I've submitted a PR for the payment gateway integration. Let me know if you need any context – I'm happy to jump on a quick call to walk you through the changes.'
This scenario highlights the importance of tact and understanding team dynamics when requesting reviews. Option B demonstrates empathy by acknowledging John's busy schedule and offering support without imposing urgency. Options A and C are overly demanding and could be perceived negatively, while option D offers a collaborative approach that respects his priorities and provides an easy way for him to engage.
22 / 26
You've completed a new function for handling user session timeouts. It's roughly 120 lines of code and includes unit tests, but you want to ensure it integrates smoothly with the existing authentication service. Which Slack message is most appropriate to send to Sarah, the senior security engineer, requesting a review?
Option 2 is the most professional and targeted approach. It clearly states the purpose of the message, requests a review specifically from Sarah (the security engineer), and acknowledges her potential concerns about vulnerabilities. Options A and B are too vague, while option D lacks a crucial request for feedback.
23 / 26
During a daily standup meeting, you're discussing your progress on updating the user profile API. You need to inform the team that you've created a PR with 450 lines of code and are requesting a review from David, who specializes in data modeling. What would be the most effective way to phrase this update?
Option 2 directly addresses David by name, specifies the PR details (450 lines, unit tests, data model changes), and clearly requests his review. This demonstrates proactive communication and focuses on relevant areas of expertise. The other options are too informal or lack crucial information.
24 / 26
You've submitted a PR containing a significant refactor of the order processing service. The PR is approximately 500 lines long and includes several new tests. In your PR description, what's the *most* important element to include regarding requesting a review?
Option 3 is crucial because it specifically directs reviewers to focus on the 'complex area' (transaction management). A good PR description highlights areas of potential risk or complexity that require extra scrutiny. The other options are too general and don't provide targeted guidance for the reviewer.
25 / 26
You're preparing a PR to integrate a new payment gateway. The PR is 680 lines long, includes comprehensive tests, and you've identified a potential issue with rate limiting. You want to highlight this during your review request. Which of the following phrases would be most effective in your comment on the PR?
Option 3 proactively flags a potential issue (rate limiting) and requests focused attention on that specific area. This is far more effective than simply asking for a general review. The other options are too passive or don't communicate critical information.
26 / 26
You've just finished implementing a new feature in the user authentication service and created a PR containing approximately 300 lines of code. Before requesting a review from Maria, who is the team's lead on API design, what's the *best* way to start your request?
Option 3 directly mentions Maria's expertise (API design), clearly states the purpose of the PR (new authentication feature), and specifically requests her attention to API alignment. This demonstrates that you've considered her role and priorities, increasing the likelihood of a thorough review.
Frequently Asked Questions
What does the "Requesting Code Reviews — Writing Exercise" exercise cover?
Practice writing effective code review requests: scoping PRs, setting expectations, following up professionally. 5 interactive exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Requesting Code Reviews — Writing Exercise"?
This exercise has 26 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Email & Writing exercises?
Browse the full Email & Writing hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.