I recently interviewed for a manager position at Uber. Overall the experience was pretty good — both interviewers were easy to talk to and felt pretty nice & chill (not quite what I expected from Uber based on my old stereotype, lol). Writing up the System Design question and what I think you need to prepare for it, as a reference for anyone else interviewing for something similar.
1) System Design: Uber Eats Cart Management
Question: Cart management (the lifecycle from creating a cart all the way to order fulfillment).
It started off very vague — basically no details given, and I had to nail down the requirements, boundaries, and assumptions myself through questions. The interviewer is watching how you "drive" this process, not whether you've memorized a template.
High-level scope
Design the backend for the cart lifecycle: create cart → add/remove/update items → checkout → create order → fulfillment → cart close/expire. The interviewer explicitly said this isn't just for restaurants, it could also be grocery. But the actual discussion mostly stayed on the steps before checkout, and in the follow-up the interviewer asked a few scattered questions about other parts.
Functional Requirements
- Add/remove items, update quantity, delete an item
- Checkout: convert the cart into an order, and make sure it's correct
Non-functional Requirements
What I emphasized most was that consistency matters a lot, especially at checkout. Latency/availability obviously matter too, but for this question the interviewer clearly cared more about correctness + edge cases.
Scalability (the scale the interviewer gave / I assumed)
- 10M concurrent orders
- Based on that number, I set some assumptions myself to get a rough QPS estimate
2) What the interviewer cared about most / what I felt was being tested
(1) User flow / Data flow
The bulk of the discussion on this question was around the user experience workflow and the data: how each request flows, what gets read and written at each step, etc.
(2) Data model + indexes (and why I designed it that way)
I spent time explaining how the data model supports queries and correctness, using a fairly common split:
- cart (cart header): cart_id, user_id, merchant_id, status, version/updated_at, pricing snapshot ref…
- cart_item: cart_id, item_id, quantity, selected_options, price_snapshot…
The typical queries it needs to support:
- Get the active cart quickly by (user_id, merchant_id)
- Pull all items by cart_id
- At checkout, quickly read cart + items and run a consistency check
Indexing approach:
- cart(user_id, merchant_id, status), or cart(user_id, status) depending on whether a user can have multiple active carts
- cart_item(cart_id) is a must
- Then decide on extra indexes/materialized views/caching based on the common queries and hot paths
(3) Concurrency (multiple devices acting on the cart at once)
This was also a big part of the discussion. Common directions:
- Optimistic concurrency control: the cart header keeps a version, and mutations use a conditional write (expected_version) to prevent overwrites
- Finer-grained conflict control: if the interviewer pushes on "can two devices editing different items avoid conflicting," you can bring up item-level version / item-level locks
3) Behavioral (Manager)
This part was a fairly standard manager interview:
- team scope / org goals / metrics ownership
- how to manage a poor performer
- disagreement with your manager
- disagreement with a cross-functional partner (PM/DS/Eng)
My own stories didn't come out very smoothly or concisely — I still need more practice on that.
Discussion
Loading comments…