When you request a review from a GitHub team, how does code review assignment decide who is actually asked?
answer
- A team request is a broadcast by default
- Assignment converts it to named humans
- Two routing algorithms are offered
- One counts turns, one counts load
- Members can be excluded from routing
basics
~20 sWithout automatic assignment, GitHub notifies the whole team and anyone may pick it up. With a team's code review assignment enabled, GitHub picks a set number of members using a round robin or load balance algorithm, honouring any exclusions configured for that team.
solid answer
~50 sBy default, requesting review from a GitHub team asks the team as a whole: every member is notified and the request stays open until someone reviews. That works for small teams and produces diffusion of responsibility in large ones. A team can instead enable **code review assignment**, where GitHub selects individuals on the team's behalf. You configure how many members to assign and a **routing algorithm**: **round robin** picks members in rotation regardless of current load, while **load balance** favours members with fewer recent review requests. You can also exclude specific members — people on leave or in a role that should not be routed work — and control whether the whole team is still notified once individuals are chosen. It distributes reviews without a rota spreadsheet, but it assigns by availability, not by knowledge, so path-based ownership routing remains the tool for "the right person must look at this".
go deeper
Know that a review request can go to a team as well as a person, and that a team request may be turned into a request for specific members automatically.
Explain the configuration: number of assignees, round robin versus load balance, exclusions, and whether the whole team is still notified. Say why a broadcast to twenty people stalls.
Show that you know its limits — it distributes by availability rather than expertise, ignores absence unless the exclusion list is maintained, and does not by itself improve review latency.
Own how routing composes across the organization: ownership rules for who must review, automatic assignment for which human inside a team, and explicit turnaround norms that make the assignment binding.
## The default behaviour Request a review from a team on a GitHub pull request and the request is recorded against the **team**, not a person. Every member is notified according to their settings, and the request remains outstanding until somebody reviews. On a team of three this is fine. On a team of twenty it is the classic bystander problem: each member sees a notification, assumes a colleague with more context will take it, and the pull request sits for two days. Team-level review requests are a broadcast, and broadcasts are nobody's responsibility. ## What code review assignment changes A team can turn on **code review assignment**, and GitHub then picks individuals when the team is requested. The settings that matter: **How many members to assign.** Usually one, occasionally two where a second opinion is standard. **Routing algorithm.** **Round robin** cycles through members in order, so over time everyone gets a comparable count regardless of what they are currently holding. **Load balance** takes recent review requests into account and favours members with fewer of them, which spreads work more evenly when the team's members have unequal review activity. **Exclusions.** Specific members can be marked never to be assigned — someone on extended leave, or a member whose role is not code review. **Notification scope.** You can keep notifying the whole team when a request comes in, or narrow notification to the chosen individuals so the rest are not pulled in. The practical effect is that the pull request's reviewer field shows named humans instead of a team handle, and the social contract changes from "someone should look" to "you are on the hook". ## What it does not do **It does not know the code.** Assignment is about distribution, not expertise: the algorithm has no view of who wrote the module or who last touched the file. When a change genuinely needs a specific pair of eyes, path-based ownership routing is the mechanism, and automatic assignment sits underneath it for the ordinary case. **It does not know your calendar.** Round robin will happily assign someone who is on holiday unless they are excluded, which is why teams that rely on it need a habit of maintaining the exclusion list — an operational chore people forget until reviews stall. **It does not make the review happen.** Assignment is a routing decision; latency comes from the assigned person's workload and the team's norms about when review happens. If everyone reviews once a day at 4 p.m., automatic assignment changes who waits, not how long. ## Choosing between the algorithms Round robin gives predictable fairness by count and is easy to reason about. Load balance responds to reality — someone who has absorbed four reviews this week gets skipped — and is the better default on teams with uneven capacity or part-time members. If reviews feel evenly spread but people complain about bursts, load balance is the fix; if reviews cluster on the two most senior members regardless of the setting, the cause is usually manual re-requests, not the algorithm. ## Where this shows up in an interview Rarely as a trivia question, often as part of "how did your team keep review from becoming a bottleneck?" The answer that lands is a chain: ownership routing gets the right people, automatic assignment picks a specific human rather than a crowd, and a team agreement on turnaround time makes the assignment mean something. The mechanism without the norm just relocates the delay.
- What is the difference between the round robin and load balance routing algorithms for a GitHub team?Round robin cycles through team members in order, so counts even out over time regardless of what anyone is currently holding. Load balance takes recent review requests into account and favours members with fewer of them, which distributes better when capacity is uneven — part-time members, or someone already carrying several reviews. Round robin is more predictable; load balance is more responsive.
- Why does automatic assignment not replace path-based ownership routing?Because assignment distributes by availability, not by knowledge — it has no view of who owns or last touched the code. Ownership routing answers "who must look at this", automatic assignment answers "which of the eligible people is asked this time". The two compose: ownership decides the team or individuals required, assignment picks the human inside a team.
- Assignment is enabled and reviews still take days. What do you look at?Assignment only changes who is asked, never how fast they respond. Check whether assignees are excluded when away, whether people re-request review from the same two senior engineers by hand, whether pull requests are large enough that reviewing is a half-day job, and whether the team has an agreed turnaround at all. Routing without a norm just relocates the queue.
saying these in an interview costs you the question
- Thinks team requests always assign an individual
- Believes assignment picks the subject-matter expert
- Assumes it accounts for holidays automatically
- Expects automatic assignment to reduce review latency alone
- Confuses review routing with required approvals