Practice the vocabulary for RFC reviews, architecture review board meetings, and API design discussions.
0 / 5 completed
1 / 5
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 / 5
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 / 5
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 / 5
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 / 5
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.