Uber

What they grade on

• Realistic geo reasoning — H3, quad-trees, geohashing
• Explicit surge / matching logic with market clearing dynamics
• Consistency vs latency trade-offs at the rider-driver boundary
• Cost-aware decisions on maps and routing
• Operational awareness — driver + rider + city-level failure isolation

Deal breakers

• No geo-indexing plan — trying to naively query all drivers within 5km
• Ignoring driver-state fan-out at scale (100K drivers → matcher must not scan all)
• Silence on multi-city (multi-region) partition strategy
• No surge / matching feedback loop — treating it as a pure optimization problem

Super helpful signals

• Naming H3 or DISCO with the right property (H3 = hexagonal hierarchical, DISCO = old batch matcher)
• Discussing eventual consistency for driver-state fan-out — write-heavy vs read-heavy separation
• Referencing the 2015 microservices rewrite as a real migration case study
• Bringing up city-sharded architecture as a natural boundary

Delivery advice

• Ground the design in a rider journey — 'so a user opens the app, taps request…'
• Discuss geo-indexing early (H3 or geohashing). Don't handwave it.
• Reason about eventual vs strong consistency at the matching boundary — riders can tolerate 2s driver-state staleness; payments cannot.
• Talk about city-sharded architecture — each city is essentially its own service instance.
• Sprinkle a driver-side + rider-side trade-off explicitly. Both sides matter to matching quality.

Red flags to avoid

• No geo indexing plan
• Ignoring driver-state fan-out
• Global consistency assumption where eventual works
• No fraud / abuse consideration for surge