Practice the vocabulary for RFC reviews, architecture review board meetings, and API design discussions.
0 / 20 completed
1 / 20
An engineer is presenting an RFC for a new caching layer. Another reviewer wants to propose a different approach without derailing the session. Which comment is most appropriate?
Proposing an alternative in a design review: name the alternative ('read-through cache'), name the specific benefit and where it applies ('simplifies invalidation in section 3'), explain the mechanism ('populates on misses'). Then signal your overall position: '+1 with one consideration.' This is non-blocking feedback — you're proposing an improvement, not blocking the RFC. Vague historical analogies ('we tried this and it failed') without specifics are not useful review feedback.
2 / 20
You are reviewing an RFC and have a concern about the approach that you believe must be resolved before approval. How do you flag it?
A blocking concern is stated explicitly with the word 'blocking.' Name the specific technical risk ('drops a column referenced in three services'), identify the impact ('dependencies not owned by this team'), and state the resolution condition ('cannot be approved until migration path is defined'). A concern raised offline or after approval is not a blocking concern — it has no effect on the RFC process. 'Approved — but I have issues' is contradictory.
3 / 20
The design review is running out of time and two agenda items remain unresolved. How do you close the meeting as facilitator?
Closing a design review with open items: name the specific items still open, state the RFC status explicitly ('needs revision' — not 'approved'), identify the next step (follow-up session with date), and ask if there is time pressure. 'Table both for a follow-up' is the correct facilitation phrase. Forcing a vote or deferring everything async loses accountability — someone must own the open items and a date must be set.
4 / 20
A reviewer gives feedback that is vague: 'I'm not sure about the scalability of this approach.' How do you as facilitator draw out a useful response?
Vague concerns in design reviews are not actionable. As facilitator, your job is to make every concern specific: 'which part?' + offer structured options ('write throughput, read latency, data volume') to help the reviewer locate their concern. 'Naming the specific bottleneck' is the actionability standard for design review feedback. Don't accept vague concerns as-is — they block progress without creating resolution.
5 / 20
The RFC has been discussed and most reviewers are aligned. How do you declare it approved and close the review?
Design review closure: explicitly declare the outcome ('approved to proceed'), name any non-blocking feedback and how it's tracked ('follow-up item'), give the author a clear action ('update status to accepted, link from ticket'), and close the meeting. 'I guess we're good?' is ambiguous — approval must be stated explicitly. A follow-up email confirmation is redundant if the declaration is made clearly in the meeting.
6 / 20
Sarah, the lead backend engineer, is leading a Slack channel discussing a potential refactor of the user authentication service. A junior developer, David, suggests using JWTs for improved security. Which response best reflects a constructive contribution to the discussion?
The key here is a constructive response that encourages further discussion and understanding. Option 2 demonstrates an open-minded approach by acknowledging the suggestion and prompting David to explain his reasoning. Options A and C are dismissive or overly prescriptive, while option D immediately rejects the idea without exploration. This aligns with best practices for collaborative problem-solving.
7 / 20
You're reviewing a Pull Request (PR) containing a significant change to a microservice API endpoint. The PR description briefly mentions 'improved performance,' but lacks specific details about the changes made or any metrics used to measure improvement. How should you proceed?
A robust PR description is crucial for effective code review. The author's vague statement highlights a missing element—quantifiable evidence of improvement. Option 1 emphasizes requesting clarification and details, which allows reviewers to properly assess the change and ensure it aligns with performance goals. Rejecting or approving without further information would be irresponsible.
8 / 20
During a design review for a new data processing pipeline, one reviewer raises concerns about potential bottlenecks in the system. They state, 'I'm worried this architecture won't scale to handle peak loads.' What is the most appropriate follow-up question for the facilitator to ask?
The reviewer's statement is a valuable concern, but it lacks specific details. The facilitator needs to elicit more information to understand the scope of the potential problem. Option 1 prompts for quantifiable metrics – throughput and latency – which are essential for assessing scalability risks. Options A and C ignore the feedback, while option D dismisses the concern prematurely.
9 / 20
The architect, Mark, is leading a discussion on a new API design. During the meeting, a developer, Emily, offers an alternative approach but begins to elaborate extensively on its advantages and potential benefits, dominating the conversation. How should Mark, as facilitator, intervene?
Effective facilitation requires managing conversation flow and ensuring all voices are heard. Option 1 demonstrates proactive intervention by gently redirecting the discussion to the primary objective – evaluating the design itself. Interrupting abruptly or allowing one person to dominate would be counterproductive.
10 / 20
After a lengthy and productive architectural review of a new service, the team has reached consensus on the proposed design. As the meeting facilitator, what is your next step?
Formalizing the approval process is crucial for maintaining clarity and accountability. Option 1 involves documenting the agreed-upon design and key decisions – this creates a clear record for future reference. Confirming agreement or starting the next meeting are premature steps at this stage.
11 / 20
Sarah, the lead backend engineer, is leading a Slack channel discussing a potential refactor of the user authentication service. A junior developer, David, suggests using JWTs for improved security. Which response best reflects a constructive contribution to the discussion?
The key here is a constructive response that encourages further discussion and understanding. Option 2 demonstrates an open-minded approach by acknowledging the suggestion and prompting David to explain his reasoning. Options A and C are dismissive or overly prescriptive, while option D immediately rejects the idea without exploration. This aligns with best practices for collaborative problem-solving.
12 / 20
You're reviewing a Pull Request (PR) containing a significant change to a microservice API endpoint. The PR description briefly mentions 'improved performance,' but lacks specific details about the changes made or any metrics used to measure improvement. How should you proceed?
A robust PR description is crucial for effective code review. The author's vague statement highlights a missing element—quantifiable evidence of improvement. Option 1 emphasizes requesting clarification and details, which allows reviewers to properly assess the change and ensure it aligns with performance goals. Rejecting or approving without further information would be irresponsible.
13 / 20
During a design review for a new data processing pipeline, one reviewer raises concerns about potential bottlenecks in the system. They state, 'I'm worried this architecture won't scale to handle peak loads.' What is the most appropriate follow-up question for the facilitator to ask?
The reviewer's statement is a valuable concern, but it lacks specific details. The facilitator needs to elicit more information to understand the scope of the potential problem. Option 1 prompts for quantifiable metrics – throughput and latency – which are essential for assessing scalability risks. Options A and C ignore the feedback, while option D dismisses the concern prematurely.
14 / 20
The architect, Mark, is leading a discussion on a new API design. During the meeting, a developer, Emily, offers an alternative approach but begins to elaborate extensively on its advantages and potential benefits, dominating the conversation. How should Mark, as facilitator, intervene?
Effective facilitation requires managing conversation flow and ensuring all voices are heard. Option 1 demonstrates proactive intervention by gently redirecting the discussion to the primary objective – evaluating the design itself. Interrupting abruptly or allowing one person to dominate would be counterproductive.
15 / 20
After a lengthy and productive architectural review of a new service, the team has reached consensus on the proposed design. As the meeting facilitator, what is your next step?
Formalizing the approval process is crucial for maintaining clarity and accountability. Option 1 involves documenting the agreed-upon design and key decisions – this creates a clear record for future reference. Confirming agreement or starting the next meeting are premature steps at this stage.
16 / 20
Sarah, the lead backend engineer, is leading a Slack channel discussing a potential refactor of the user authentication service. A junior developer, David, suggests using JWTs for improved security. Which response best reflects a constructive contribution to the discussion?
The key here is a constructive response that encourages further discussion and understanding. Option 2 demonstrates an open-minded approach by acknowledging the suggestion and prompting David to explain his reasoning. Options A and C are dismissive or overly prescriptive, while option D immediately rejects the idea without exploration. This aligns with best practices for collaborative problem-solving.
17 / 20
You're reviewing a Pull Request (PR) containing a significant change to a microservice API endpoint. The PR description briefly mentions 'improved performance,' but lacks specific details about the changes made or any metrics used to measure improvement. How should you proceed?
A robust PR description is crucial for effective code review. The author's vague statement highlights a missing element—quantifiable evidence of improvement. Option 1 emphasizes requesting clarification and details, which allows reviewers to properly assess the change and ensure it aligns with performance goals. Rejecting or approving without further information would be irresponsible.
18 / 20
During a design review for a new data processing pipeline, one reviewer raises concerns about potential bottlenecks in the system. They state, 'I'm worried this architecture won't scale to handle peak loads.' What is the most appropriate follow-up question for the facilitator to ask?
The reviewer's statement is a valuable concern, but it lacks specific details. The facilitator needs to elicit more information to understand the scope of the potential problem. Option 1 prompts for quantifiable metrics – throughput and latency – which are essential for assessing scalability risks. Options A and C ignore the feedback, while option D dismisses the concern prematurely.
19 / 20
The architect, Mark, is leading a discussion on a new API design. During the meeting, a developer, Emily, offers an alternative approach but begins to elaborate extensively on its advantages and potential benefits, dominating the conversation. How should Mark, as facilitator, intervene?
Effective facilitation requires managing conversation flow and ensuring all voices are heard. Option 1 demonstrates proactive intervention by gently redirecting the discussion to the primary objective – evaluating the design itself. Interrupting abruptly or allowing one person to dominate would be counterproductive.
20 / 20
After a lengthy and productive architectural review of a new service, the team has reached consensus on the proposed design. As the meeting facilitator, what is your next step?
Formalizing the approval process is crucial for maintaining clarity and accountability. Option 1 involves documenting the agreed-upon design and key decisions – this creates a clear record for future reference. Confirming agreement or starting the next meeting are premature steps at this stage.
What will I practise in "Design Review & Architecture Review Meetings — Vocabulary"?
This module focuses on Meetings & Collaboration — real workplace phrasing you'll use on the job. It contains 20 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 20 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Meetings & Collaboration exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around meetings & collaboration — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Meetings & Collaboration exercises?
See the Meetings & Collaboration hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.