Uber Engineering Manager Interview Experience — Cart System Design Screen Plus Behavioral

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.