Just finished my Uber loop last month. Targeting L5 backend. Sharing notes because I spent two weeks Googling this and got mostly outdated stuff.
The system design round was 60 minutes, one interviewer, no co-interviewer observing. They send you a Coderpad-like shared doc, but you're mostly drawing boxes and talking.
My prompt was something in the rides/logistics space (won't get too specific). The setup was: design a core dispatcher component that handles real-time assignment at scale. Think about it from their business lens, Uber's interview prompts are almost always grounded in something their actual systems do.
What they actually cared about: Estimations early. Not precise math, but "how many ride requests per second in SF at 5pm Friday?" before you start designing. Data model. They want to see how you think about entities. Driver state, rider state, trip state, time to live. Bottlenecks called out proactively. Don't wait for them to ask "where does this fall over?" Horizontal scaling: partitioning strategy for your queue or store. Geohashing came up, which makes sense for location-based work. Failure modes. What happens if the dispatcher crashes mid-assignment? At-least-once vs at-most-once semantics.
I came in having done the standard "design Uber" Leetcode question, and I'll be honest, that helped with vocabulary but the real interview goes deeper on exactly one piece rather than the whole surface.
Round felt collaborative. Interviewer pushed back twice when I over-engineered, which was fair. Good signal to not gold-plate immediately, show you know when to stop.
Total loop was 5 rounds: coding x2, system design x1, behavioral x1, hiring manager x1. HM round was surprisingly technical. He asked about trade-offs I'd made in past projects, not just the STAR-method stuff.
If you're targeting L5 SWE, budget 3-4 weeks of system design prep. I used a mix of Donne Martin's system design primer and Uber's engineering blog. The blog is actually useful here, they've written about their dispatch stack and Kafka usage.