Master the IT-English vocabulary for asynchronous code review: clear threads, blocking vs non-blocking, resolving comments and follow-ups.
0 / 18 completed
1 / 18
A reviewer marks a comment as 'blocking'. What does that mean?
A blocking comment must be resolved before merge; non-blocking ones are optional.
2 / 18
In async review, why is it good to make comments 'self-contained'?
Async reviewers aren't online together, so each comment should carry enough context to stand alone.
3 / 18
An author 'resolves' a review thread. What does that indicate?
Resolving a thread signals the comment has been handled and need not be revisited.
4 / 18
Which phrase clearly defers a non-essential point?
Labelling 'non-blocking' and suggesting a follow-up keeps the review moving while noting the idea.
5 / 18
Why include a 'TL;DR' summary on a complex review comment?
A TL;DR (too long; didn't read) summary gives the gist quickly, helping async readers prioritise.
6 / 18
Alice: 'Hey, this PR introduces a potential race condition in the user authentication flow. We need to investigate further.'
Bob: 'I've added a comment explaining that we're using optimistic locking and it should be fine.'
During a code review discussion, which of the following is most appropriate for Alice to say next?
Alice is raising a concern about a serious technical issue – a race condition. It's crucial to push back on assertions that seem overly confident without sufficient evidence. Option 1 asks for specific details and justification, prompting Bob to elaborate and demonstrate understanding of the potential problem. Options B, C, and D are all premature conclusions or escalate the discussion inappropriately; they don't address the core concern of a possible concurrency vulnerability.
7 / 18
Reviewer: 'This commit introduces a potential deadlock in the payment processing service. We need to examine the locking strategy before merging.'
Alice: 'I've added a comment suggesting we use a retry mechanism.'
The initial reviewer has identified a serious concurrency risk (a deadlock). Simply suggesting a retry mechanism without understanding *why* the deadlock is occurring is insufficient. While a retry might be part of the solution, Alice needs to demonstrate she understands the problem's complexity and doesn't just jump to a superficial fix; that's why option 3 is correct – it acknowledges the issue and invites a deeper discussion about synchronization.
8 / 18
Alice: 'Hey, this PR introduces a potential race condition in the user authentication flow. We need to investigate further.'
Bob: 'I've added a comment explaining that we're using optimistic locking and it should be fine.'
During a code review discussion, which of the following is most appropriate for Alice to say next?
Alice is raising a concern about a serious technical issue – a race condition. It's crucial to push back on assertions that seem overly confident without sufficient evidence. Option 1 asks for specific details and justification, prompting Bob to elaborate and demonstrate understanding of the potential problem. Options B, C, and D are all premature conclusions or escalate the discussion inappropriately; they don't address the core concern of a possible concurrency vulnerability.
9 / 18
Reviewer: 'This commit introduces a potential deadlock in the payment processing service. We need to examine the locking strategy before merging.'
Alice: 'I've added a comment suggesting we use a retry mechanism.'
The initial reviewer has identified a serious concurrency risk (a deadlock). Simply suggesting a retry mechanism without understanding *why* the deadlock is occurring is insufficient. While a retry might be part of the solution, Alice needs to demonstrate she understands the problem's complexity and doesn't just jump to a superficial fix; that's why option 3 is correct – it acknowledges the issue and invites a deeper discussion about synchronization.
10 / 18
Alice: 'Hey, this PR introduces a potential race condition in the user authentication flow. We need to investigate further.'
Bob: 'I've added a comment explaining that we're using optimistic locking and it should be fine.'
During a code review discussion, which of the following is most appropriate for Alice to say next?
Alice is raising a concern about a serious technical issue – a race condition. It's crucial to push back on assertions that seem overly confident without sufficient evidence. Option 1 asks for specific details and justification, prompting Bob to elaborate and demonstrate understanding of the potential problem. Options B, C, and D are all premature conclusions or escalate the discussion inappropriately; they don't address the core concern of a possible concurrency vulnerability.
11 / 18
Reviewer: 'This commit introduces a potential deadlock in the payment processing service. We need to examine the locking strategy before merging.'
Alice: 'I've added a comment suggesting we use a retry mechanism.'
The initial reviewer has identified a serious concurrency risk (a deadlock). Simply suggesting a retry mechanism without understanding *why* the deadlock is occurring is insufficient. While a retry might be part of the solution, Alice needs to demonstrate she understands the problem's complexity and doesn't just jump to a superficial fix; that's why option 3 is correct – it acknowledges the issue and invites a deeper discussion about synchronization.
12 / 18
Alice: 'Hey, this PR introduces a potential race condition in the user authentication flow. We need to investigate further.'
Bob: 'I've added a comment explaining that we're using optimistic locking and it should be fine.'
During a code review discussion, which of the following is most appropriate for Alice to say next?
Alice is raising a concern about a serious technical issue – a race condition. It's crucial to push back on assertions that seem overly confident without sufficient evidence. Option 1 asks for specific details and justification, prompting Bob to elaborate and demonstrate understanding of the potential problem. Options B, C, and D are all premature conclusions or escalate the discussion inappropriately; they don't address the core concern of a possible concurrency vulnerability.
13 / 18
Reviewer: 'This commit introduces a potential deadlock in the payment processing service. We need to examine the locking strategy before merging.'
Alice: 'I've added a comment suggesting we use a retry mechanism.'
The initial reviewer has identified a serious concurrency risk (a deadlock). Simply suggesting a retry mechanism without understanding *why* the deadlock is occurring is insufficient. While a retry might be part of the solution, Alice needs to demonstrate she understands the problem's complexity and doesn't just jump to a superficial fix; that's why option 3 is correct – it acknowledges the issue and invites a deeper discussion about synchronization.
14 / 18
David from the backend team sends this Slack message: 'Just FYI, I've implemented the new API endpoint. Let me know if you have any questions.'
What does 'just FYI' typically imply in this context of asynchronous code review?
'Just FYI' often means 'for your information,' signaling that David is sharing a piece of data without expecting immediate interaction. This aligns with asynchronous code reviews where collaboration happens iteratively. It's distinct from seeking immediate testing or delaying discussion until the review is complete.
15 / 18
Sarah, a senior developer, is reviewing a PR and comments: 'This section could benefit from clearer variable naming to improve readability.'
Which of the following best describes Sarah's intention?
Sarah's comment about 'clearer variable naming' focuses specifically on readability – a common, low-risk suggestion in code reviews. It doesn't imply a complete rewrite or architectural concerns. This is a typical feedback loop in asynchronous development.
16 / 18
Mark writes this PR description for a merge request:
'Fixed bug #1234. Resolved by implementing the suggested algorithm.'
What is the primary purpose of including 'Resolved by…' in a PR description?
The 'Resolved by…' clause provides crucial context for understanding *how* the issue was addressed. This allows reviewers to quickly assess the solution's validity and avoid re-investigating the problem. It's a standard practice for efficient asynchronous communication.
17 / 18
Elena says: 'Let's discuss this later.'
In the context of code review feedback, what does she mean?
'Let's discuss this later' is a polite way to defer a deeper conversation. It indicates Elena doesn't want to engage in an immediate debate but intends to revisit the issue at a suitable time. This phrase avoids confrontation and facilitates asynchronous progress.
18 / 18
Tom is reviewing a complex code change with many related modifications. He writes in the comment: 'This refactoring introduces potential concurrency issues – need to investigate locking.'
Why would Tom include a 'TL;DR' (Too Long; Didn't Read) summary alongside this detailed comment?
A 'TL;DR' summary provides a concise overview of the key concerns—in this case, the concurrency issues and locking strategy. This allows reviewers to quickly grasp the core problem without needing to read the entire, technically detailed comment, streamlining asynchronous communication.
What does the "Async Code Review Communication" exercise practise?
Master the IT-English vocabulary for asynchronous code review: clear threads, blocking vs non-blocking, resolving comments and follow-ups.
How many questions are in this exercise?
This exercise has 18 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Code Review Language category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Async Code Review Communication" part of a larger series?
Yes — it's one exercise in the Code Review Language category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Code Review Language category page for related exercises, or browse the main Exercises hub for other IT English topics.