Build fluency in the language used during technical design reviews.
0 / 5 completed
1 / 5
During a design review, a senior engineer asks the presenter to justify a technical choice over the alternatives. What is this document section usually called?
The tradeoffs (or alternatives considered) section explains why one approach was chosen over other viable options, addressing cost, complexity, or risk differences. Reviewers commonly probe this section to test whether the design was thoroughly evaluated. Presenting it upfront often heads off repetitive questioning.
2 / 5
At standup, a dev mentions their design review surfaced a concern serious enough to pause implementation. What should they call this concern?
A blocking concern is significant enough that the team agrees implementation shouldn't proceed until it's resolved, unlike a minor suggestion. Clearly labeling a concern as blocking versus non-blocking sets expectations about urgency. This distinction keeps design reviews actionable rather than just a list of undifferentiated comments.
3 / 5
In a code review discussion, a teammate references the document that captures who attended and what was decided in the design review. What is this called?
Meeting notes or a decision record capture attendees, key discussion points, and the final decisions made during a design review, serving as institutional memory. Without this, teams risk re-litigating settled decisions later. Recording decisions is especially important for consequential or contested designs.
4 / 5
An incident report references a design review where a scaling concern was raised but never resolved before launch. What process gap does this reveal?
If a raised concern has no clear owner or follow-up tracking, it can silently fall through the cracks even after being flagged in a design review. Establishing a resolution process, such as requiring sign-off before concerns are considered closed, prevents this gap. This is a common root cause traced back in postmortems.
5 / 5
During a PR review, a teammate asks why the implementation diverges from the reviewed design doc. What should have happened first?
When implementation needs to significantly diverge from an approved design, best practice is to update and re-circulate the design doc, or at least flag the change to reviewers, rather than silently drifting. This keeps the design doc a trustworthy source of truth. Skipping this step undermines the purpose of doing a design review at all.