Prompt and scope
A developer platform sees merge requests waiting for review while authors repeatedly chase reviewers. Reviewers worry that a hard deadline will encourage rubber-stamping. The team is considering a code-review SLO informed by public engineering processes that define feedback timing, blocking concerns, and collaborative review values.
Answer from user problem through metric design, segmentation, notification and ownership, quality guardrails, experiment design, and rollback. An SLO is a team operating contract, not a single-reviewer performance ranking.
What the interviewer evaluates
The interviewer looks for a decomposition of waiting into actionable stages and a balance among delivery speed, review quality, author experience, and reviewer load.
A strong answer discusses median and tail latency, urgent-change exemptions, time-zone coverage, blocking versus non-blocking comments, sampling, quality regression, and gaming instead of choosing one 24-hour number.
Clarifications to ask first
- Is the goal faster first useful feedback or a shorter create-to-merge cycle?
- Which changes need two maintainer approvals, and which have a fast path?
- How are leave, time zones, external dependencies, and large refactors handled?
- Which quality signals matter: rollbacks, defects, rework, missed review issues, or security events?
- Is the SLO for a team, repository, service tier, or individual?
A 30-second answer
“I would separate first response, blocking-item handling, and final merge, then segment by risk, size, and dependency instead of ranking individuals. I would pilot in one repository with rotation, reminders, and structured deferral reasons. Quality guardrails would include rollbacks, defects, rework, and security issues. If waiting improves while defects or review depth worsen, I would stop expansion and fix the segmentation or bottleneck rather than tighten the deadline.”
Step-by-step solution
Define user value and scope
Until an author receives useful first feedback, direction remains uncertain; reviewers need context and complete CI. The product goal is to remove avoidable waiting while retaining security, architecture, and test review. Separate author readiness, CI delay, and external dependency from reviewer delay.
Design segmented metrics
Measure create-to-first-response, first-response-to-blockers-closed, close-to-merge, total cycle, and reopen count. Report P50, P90/P95, and breach rate; averages hide large changes and overnight requests. Each segment needs explicit start and end events with a single time-zone rule.
Segment by risk and size
Small low-risk changes can have a short first-response target; security, database, cross-service, and large refactor changes need longer windows and more approvals. Urgent fixes use an explicit label and follow-up review, not a universal emergency lane. Generate or audit segmentation fields so authors cannot silently lower risk.
Provide notification and ownership
Rotation schedules, reviewer suggestions, working-hours reminders, and escalation paths reduce waiting better than a countdown. Notifications should point to the queue and duty, never shame an individual. GitLab's public process emphasizes timely, traceable feedback and maintainer accountability; turn those principles into team operations, not a race.
Add quality guardrails
Observe rollback rate, production defects, rework rounds, missed review issues, security findings, and change-failure rate alongside the SLO. Compare the same risk tier, repository, and release window so high-risk changes are not punished for being slower. Sample comments for requirements, tests, maintainability, and security coverage.
Make deferrals explainable
Allow structured reasons such as missing context, external dependency, maintainer absence, or security expertise. A deferral is not automatically a breach, but the queue state and next update must be visible. Remove systemic bottlenecks such as missing rotation or CI queues instead of asking individuals to work unpaid overtime.
Run and evaluate a pilot
Choose a repository with stable traffic, establish a two-week baseline, then enable reminders and rotation by risk tier. Compare waiting distributions, merge cycle, author satisfaction, reviewer load, and quality guardrails. Use a control repository or staggered rollout so seasonality is not mistaken for impact.
Roll back and govern
If lower breaches coincide with more rollbacks or defects, stop expansion, disable individual rankings and forced escalation, and retain the team target for review. Revisit tiers, windows, leave policy, and quality weights quarterly; recalibrate when repository scale, time zones, or compliance changes.
Model high-quality answer
“I would make the SLO a team service contract: measure first useful feedback, blocker handling, and final merge separately, segmented by risk, size, and dependency. Rotation, suggestions, and escalation reduce waiting; deferrals record structured reasons; individuals are not ranked by one timeout. A pilot tracks P50/P95 waiting, author experience, reviewer load, rollbacks, defects, rework, and security misses. If speed improves while quality worsens, pause expansion and fix segmentation, ownership, or CI bottlenecks.”
Common mistakes
- One 24-hour target for every MR → large and secure changes are rushed → segment by risk and size.
- Ranking individual breaches → reviewers race or rubber-stamp → measure team queues and quality outcomes.
- Reporting only average wait → P95 tail is hidden → report segmented P50/P90/P95.
- Treating reminders as governance → queues still lack duty coverage → add ownership, rotation, and context.
- Optimizing merge speed alone → defects and rollbacks rise → include quality guardrails.
- Banning every deferral → time-zone and compliance work is punished → allow explainable deferral and next steps.
Follow-up questions and answers
Follow-up 1: Why not use total cycle time as the SLO?
Total cycle mixes author readiness, CI, external dependencies, and review, so ownership is not actionable. Segments locate bottlenecks; total cycle can remain an outcome metric.
Follow-up 2: Can urgent fixes skip the SLO?
Use an explicit urgent path with minimum safety checks and a follow-up review. If the label is abused, audit its source and later defects instead of removing every exception.
Follow-up 3: How do you prove speed did not hurt quality?
Compare rollback, defect, rework, security-miss, and comment-coverage signals by risk tier for a stable period. One successful release is not causal evidence; use a control or staggered experiment.
Follow-up 4: Who owns an SLO breach?
The team owns queue, rotation, and tooling; the author owns context; the reviewer owns timely, reasoned feedback; the maintainer owns the final decision. Systemic gaps should not become personal punishment.