Uber PM Interview: Product Sense Round for Mobility vs Delivery Teams

The product sense round in Uber’s PM interview is not a test of creativity—it’s a stress test of judgment under constraints. Mobility and Delivery teams evaluate the same core skill differently: one prioritizes system-wide efficiency under volatility, the other demands unit economics precision at hyperlocal scale. Candidates fail not because they lack ideas, but because they misread which variables matter to which team.

TL;DR

Uber’s product sense round separates PMs who optimize for user stories from those who optimize for system constraints. Mobility interviews focus on network effects, supply volatility, and real-time matching. Delivery interviews emphasize margin pressure, dark store logistics, and last-mile unit economics. The difference isn’t in the format—it’s in what the team rewards. Most candidates prepare generically and get rejected because they answer the wrong problem.

Who This Is For

This is for senior associate to L5 PM candidates targeting product roles at Uber, specifically those choosing between Mobility (Rides, Express, Transit) and Delivery (Uber Eats, Grocery, Local). You’ve passed the recruiter screen, have 3–8 years of product experience, and are preparing for a 45-minute product sense case. You need to know how judgment is evaluated differently across domains—not just what to study, but how to frame trade-offs.

How does Uber’s product sense round differ between Mobility and Delivery?

Uber’s product sense round is identical in structure—45 minutes, one open-ended problem—but diverges sharply in evaluation criteria based on team context. In a Q3 2023 debrief for the Sydney Mobility team, the hiring manager rejected a candidate who proposed surge pricing tweaks because they ignored driver repositioning incentives. The same answer would have passed in Delivery if tied to courier wait time reduction.

Mobility evaluates how well you model dynamic supply-demand imbalance. The system is probabilistic: drivers move, traffic shifts, weather disrupts. Your solution must show awareness of second-order effects—adding a pickup radius filter might improve match rates but hurt driver utilization. The insight layer here is queuing theory under uncertainty: time-in-system matters more than volume.

Delivery, by contrast, operates under deterministic constraints. A courier can only carry three bags. A restaurant has five-minute buffer before food degrades. The evaluation focuses on cost-per-delivery, incremental margin, and operational thresholds. In a debrief for the Berlin Eats team, a candidate proposed AI-driven kitchen prep time prediction—strong technically—but was dinged because they didn’t quantify impact on courier idle time or dark store density.

Not creativity, but constraint mapping.

Not feature ideation, but system boundary definition.

Not user pain points, but operational chokepoints.

What do interviewers actually listen for in the first 90 seconds?

The first 90 seconds determine whether the interviewer leans pass or no-pass. In a Mountain View HC meeting, a slate of six candidates was reduced to two based solely on scoping precision in the opener. Interviewers don’t listen for empathy statements like “I’d start by understanding user needs”—they listen for problem framing that surfaces the right variables.

For Mobility, strong openers name the system’s scarce resource: driver supply in low-density zones, rebalance efficiency, or average time-to-pickup. A candidate who says, “Let me first clarify whether we’re optimizing for rider wait time or driver utilization” signals they understand the core trade-off.

For Delivery, interviewers wait for margin-aware framing. A candidate who opens with, “Is this about reducing delivery time or improving restaurant throughput?” misses the point. One who asks, “Are we optimizing for delivery margin or marketplace liquidity?” shows grasp of the business model.

The insight layer is attention allocation: your opening question reveals where you believe the leverage lies. Most candidates waste 60 seconds reciting frameworks. The ones who pass skip frameworks and go straight to variable selection.

Not “I’d do user research,” but “Let me define what success looks like.”

Not “let’s brainstorm solutions,” but “What’s the bottleneck?”

Not empathy laundering, but constraint signaling.

How should you structure your answer for Mobility vs Delivery?

Structure isn’t about memorized frameworks—it’s about signaling judgment flow. The Seattle Mobility team uses a silent rubric during interviews: does the candidate move from user problem → system impact → trade-off analysis → metric definition? If they jump to solutions before naming the primary constraint, they fail.

In Mobility, structure must reflect dynamic systems thinking. A strong answer flows:

Define the operational bottleneck (e.g., low driver supply in outer boroughs)
Model second-order effects (e.g., increasing incentives attracts drivers but may cannibalize adjacent zones)
Propose a feedback loop (e.g., dynamic zoning with spillover penalties)
Define leading and lagging metrics (e.g., driver-hour utilization vs. rider wait time)

In Delivery, the structure must reflect unit economics discipline. A top-scoring answer looks like:

Identify the margin-lever (e.g., courier idle time between deliveries)
Quantify the cost (e.g., $1.20 per idle 10 minutes at peak)
Propose batch optimization with threshold logic (e.g., hold orders 2 mins if next courier is <4 mins away)
Define break-even point (e.g., must increase delivery density by 18% to offset delay penalty)

The organizational psychology principle here is bounded rationality: interviewers assume you can’t solve the whole problem, so they evaluate how you bound it. Candidates fail not by missing solutions, but by bounding too wide.

Not “let’s solve rider dissatisfaction,” but “let’s isolate the supply-side constraint.”

Not “improve delivery speed,” but “reduce cost-per-completed-delivery.”

Not ideation broadness, but scope discipline.

What metrics matter most to each team?

Metrics are not neutral—they’re value statements. In a debrief for the Chicago Delivery team, a candidate proposed a feature to reduce rider complaints about cold food. They suggested tracking NPS and complaint rate. The panel rejected them because they didn’t tie it to cost: every minute of kitchen delay costs $0.83 in courier idling and increases cancellation risk by 7%.

Mobility teams care about:

Driver utilization rate (target: 65–75%)
Rider wait time (P80 under 4.5 mins in urban zones)
Match rate (goal: >88% within 1.2 miles)
Rebroadcast rate (indicator of supply scarcity)

These reflect a system optimized for throughput under variability. A candidate who cites DAU or NPS without linking to supply elasticity will be seen as naive.

Delivery teams care about:

Cost per delivery (target: <$3.20 in Tier 1 cities)
Restaurant throughput (orders per hour per kitchen)
Courier utilization (minutes spent moving vs. waiting)
Order batching rate (target: 32–38% of deliveries)

In a Tokyo HC meeting, a candidate scored top marks not for proposing a new feature, but for calculating that reducing average pickup time by 1.4 minutes would lower cost per delivery by $0.61 at scale—enough to offset a 5% increase in customer dissatisfaction.

Not satisfaction metrics, but cost levers.

Not engagement, but efficiency.

Not what users say, but what the system can sustain.

How do calibration committees evaluate product sense answers?

Calibration isn’t about correctness—it’s about defensibility under pressure. The New York hiring committee once advanced a candidate who proposed eliminating surge pricing despite it contradicting company policy—because they built a simulation model showing how dynamic driver incentives could stabilize supply without pricing volatility.

The committee evaluates three things:

Whether you identified the true constraint (not the surface problem)
Whether your solution has a feedback mechanism (not just a one-off fix)
Whether your success metric is leading, measurable, and tied to business impact

In a 2022 EU Mobility calibration, a candidate failed because they measured success by rider satisfaction despite proposing a driver-focused supply intervention. The committee ruled: “You can’t claim system impact while measuring only one side of the marketplace.”

Another candidate passed Delivery despite a weak UI sketch because they specified the break-even threshold: “This only works if we increase batched deliveries by 22%. Below that, net margin declines.”

The insight layer is institutional risk tolerance: Uber values bets that can be A/B tested and killed fast. Candidates who propose moonshots without kill criteria fail. Those who build guardrails into the solution pass.

Not vision, but testability.

Not scale, but reversibility.

Not inspiration, but iteration design.

Preparation Checklist

Define the core scarce resource for your target team: driver supply for Mobility, delivery margin for Delivery
Practice scoping questions that force constraint naming: “Is our bottleneck supply availability or utilization?”
Build fluency in unit economics: know the average cost components of a delivery ($1.80 labor, $0.90 fuel, $0.50 overhead)
Memorize key operational thresholds: e.g., 4.5-minute wait time P80, 65% driver utilization
Work through a structured preparation system (the PM Interview Playbook covers Uber-specific trade-off frameworks with real debrief examples from Mobility and Delivery HCs)
Run mock interviews with PMs who’ve sat on Uber hiring committees—generic mocks miss calibration nuance
Internalize one full case per domain: one for driver repositioning, one for delivery batching

Mistakes to Avoid

BAD: “I’d start by interviewing 10 riders to understand their pain points.”

This signals you believe the problem is unknown. At Uber, the problems are known; the trade-offs are hard. User research is not a substitute for system analysis.

GOOD: “Let me first confirm whether we’re optimizing for rider wait time or driver utilization—those often move in opposite directions.”

This shows you’re prioritizing constraints, not collecting anecdotes.

BAD: Proposing a feature like “one-tap rerouting” without modeling how it affects driver acceptance rate or total trips per hour.

Mobility systems are zero-sum. Every rider benefit has a driver cost. Ignoring that fails the trade-off test.

GOOD: “If we reduce reroute friction, drivers may accept more trips, but we risk fatigue. I’d cap suggested reroutes at two per hour and measure impact on session length.”

This shows system-aware iteration.

BAD: Measuring success by NPS after proposing a delivery batching delay.

NPS is lagging and noisy. Uber wants to know if the change pays for itself.

GOOD: “We’ll only launch if we reduce cost per delivery by at least $0.50 and keep late deliveries under 8%.”

This sets a business-relevant threshold.

FAQ

Does Uber expect different frameworks for Mobility vs Delivery?

No. The CIRCLES or AARRR frameworks are irrelevant. What changes is the priority stack: Mobility values supply elasticity, Delivery values cost-per-action. Frameworks are window dressing—interviewers look for constraint hierarchy, not model fidelity.

Should I prepare different cases for each team?

Yes. Practice repositioning incentives for Mobility, batching logic for Delivery. A single generic case fails both. Mobility cases should model driver behavior volatility; Delivery cases must include margin math. Your preparation depth should mirror the team’s P&L ownership.

Is the interview format the same across regions?

Yes. A product sense round in Bangalore follows the same structure as in San Francisco. But calibration panels apply local thresholds: Mexico City may accept 60% driver utilization due to traffic, while London expects 68%. Know the regional benchmarks.amazon.com/dp/B0GWWJQ2S3).

Want to systematically prepare for PM interviews?

Read the full playbook on Amazon →

Need the companion prep toolkit? The PM Interview Handbook includes frameworks, mock interview trackers, and a 30-day preparation plan.