Design the Rider-Matching Logic Behind Uber Pool Shared Rides

Uber Pool is a ride option in which one person's trip is shared with other passengers going a similar way, usually in exchange for a cheaper fare. You are the product manager, and the interviewer wants to hear how the algorithm that decides who rides together could work so that the product meets its goals. Walk through the goals, the matching logic, the factors it takes into account and the metrics that would show it is succeeding. ### Clarifying Questions - Can a new rider be added to a car that is already carrying someone, or are groups formed only before the first pickup? - Is the rider quoted a fixed fare up front, regardless of whether a co-rider is found? - How many pooled passengers can one car take, and can a single request include more than one seat? - Is the car expected to come to each rider's exact location, or may riders walk a short distance to a shared pickup spot? ### Part 1 — Goals the matching must serve State what the algorithm is trying to achieve for riders, drivers and the company, and say where those goals collide. ```hint Three scorecards Write down what a good pooled trip looks like from each party's seat, then pick out the pairs of goals that cannot both be maximized. ``` #### What This Part Should Cover - Goals for riders, drivers and the business, stated concretely enough to optimize. - The main tensions, such as more sharing versus longer trips for the people sharing. - One primary objective, with the other goals turned into limits or guardrails. ### Part 2 — Matching logic and the factors it weighs Describe, step by step, how an incoming pool request is matched with a car or with other riders, and list the factors the decision uses. ```hint Filter, then rank Separate "is this pairing allowed at all?" from "which allowed pairing is best?", and think about when the decision should be made. ``` #### What This Part Should Cover - How candidate cars or riders are found, and how hard limits such as pickup wait, detour and seats filter them. - How the remaining options are scored, and whether each request is decided immediately or together with others. - The full set of factors, including traffic, route overlap and demand expected in the next few minutes. - What happens when no acceptable match exists or a rider cancels after being matched. ### Part 3 — Success metrics Explain how you would know the algorithm is achieving the goals from Part 1, and how you would test a change to it. ```hint Efficiency has a price The riders who get matched pay for the efficiency with their time. Pick a measure for each side of that exchange. ``` #### What This Part Should Cover - A primary metric that reflects the objective chosen in Part 1. - Rider, driver and business guardrails. - An experiment design that accounts for riders and drivers in a shared marketplace affecting each other. ### What a Strong Answer Covers - Goals, scoring rule and metrics that line up with each other, rather than three unrelated lists. - Tunable parameters (maximum detour, wait limits) with reasoning on how to set them by city and time of day. - Awareness that decisions are made in real time over a pool of requests and cars that keeps changing. - Fairness and predictability for riders: no one absorbs all the detour, and promised times are kept. ### Follow-up Questions - At night in a low-density suburb, few requests overlap. Would you still offer pooling there, and how would the logic adapt? - How would you stop a rider who was matched early from being repeatedly delayed by new pickups added to their trip? - How would the logic change if riders were asked to walk to a nearby pickup point?