Uber Senior Product Manager (5A) Interview Experience
Uber · Senior · Product Manager
The engineering round turned into a straight up 45 minute system design jam on gift card redemption, and when he asked about Kafka I was like, "I know more about Kafka the author than the tech."
Interview process
I interviewed for a specific Senior PM role, not a generalist PM funnel, and that shaped the whole process. After the sourcer screen, I had a hiring manager case, then the Uber Jam take-home deck and presentation, then a five-interview onsite with engineering, data science, product, and design counterparts. The whole loop felt much more practical and Uber-specific than most big tech PM interviews I have done, and almost every round turned into a collaborative case instead of a clean framework exercise. The biggest surprise was how technical the engineering round got, because it was basically a system design discussion around gift card redemption. I ended up getting the offer and accepted it.
Interview rounds · 4
- 1
Recruiter screen
BehavioralI started with the sourcer, and it felt mostly standard except they were very direct about leveling and pretty open about matching me to specific teams instead of a general PM pool.
Q1. Tell me about the highest-impact feature you've shipped.
How they answeredI walked through the biggest launch from my current PM role, and they dug into the metrics I used and who I worked with.
Follow-up questions- What metrics did you use?
- Who did you work with?
- How much product experience do you actually have for this level?
- 2
Phone screen
ExecutionAnalyticalThe hiring manager gave me a quick overview of the role and why they were hiring, then turned almost the whole round into a live case, which was way more than the 'mini case' I had expected.
Q1. The San Francisco office has more employees who want parking than spaces, and it's first come first serve. People aren't happy. What would you do?
How they answeredI tried to structure it like a product sense problem, but it was really an allocation and fairness problem. I set the goal around perceived equity, then talked through segments and pain points, although that got muddy because a lot of the pain was basically the same: if you do not get parking, you pay somewhere else. He was collaborative and kept nudging me on edge cases like disabilities, long commutes, and family constraints. I eventually got to the direction he wanted, but during the round I felt pretty all over the place.
Follow-up questions- What goal would you optimize for?
- How would you segment the users?
- How would you weigh people with disabilities versus people with long commutes or family constraints?
- 3
Final / onsite round
TechnicalSystem DesignAnalyticalBehavioralCross-FunctionalThe onsite was five interviews with people I would actually work with or around, and almost every round was a case with constant back-and-forth instead of me talking uninterrupted for long stretches.
Q1. How would you design the gift card redemption flow?
How they answeredThis was much more technical than I expected. I was very upfront about what I did not know, and that actually helped because the interviewer would fill in gaps and I could reason from there. When we got into synchronous versus asynchronous services, latency, and fraud, I kept bringing it back to customer impact, like sending the user somewhere else in the app to shop while a slow step finishes. For double redemption, I talked about needing transaction IDs, timestamps, and a way to stop later attempts, then asked him to explain what he meant by a lock when he introduced it.
Follow-up questions- Do you know what Kafka is?
- Do you know different types of APIs?
- What is the difference between synchronous and asynchronous services?
- What are the product implications if this takes too long?
- How would you prevent multiple people from redeeming the same gift card at the same time?
Q2. How would you design an A/B test for this?
How they answeredThis one felt pretty classic compared with the rest of the loop. I treated it like a normal experiment design conversation, and because so many other rounds were unusual, this was one of the more straightforward ones for me.
Q3. We have a lot of data on people ordering rides for other people. How would you evaluate whether there is a problem and where would you start?
How they answeredI started from the customer scenario and then worked backward to what data could actually signal pain. I mentioned standard things like ratings, but also more Uber-specific clues, like cases where the booker's current location does not match the pickup location, which can indicate they are ordering for someone else. He kept pushing on what each signal would really mean and whether driver-side or rider-side data was more reliable. It felt like a mix of customer empathy and analytical thinking more than a memorized metrics framework.
Follow-up questions- What would each data point actually tell you?
- Would you trust driver-side signals or rider-side signals more?
- What other concerns would you look into?
Q4. If a very senior stakeholder tells you, 'I need you to fix this,' how would you respond?
How they answeredI said I would not just say yes blindly. I would understand what they were actually optimizing for, and if we decided to prioritize it I would be explicit about what moves below the line. That tradeoff conversation felt like the point of the question. For this role especially, I got the sense they wanted someone who could manage very senior stakeholders without getting steamrolled.
Follow-up questions- What if they say, 'No, I want you to look at it'?
Q5. How have you worked with designers in the past?
How they answeredThis was the most conversational round by far. I talked about how I like to work with design as a real partner, and I used it as a chance to jam a bit on where gifting could go, what felt exciting in the space, and where more user research might be useful. It honestly felt like they were also checking whether I would be easy to work with, not just whether I had the right examples.
- 4
Take-home assignment
Product StrategyPresentationExecutionThe Uber Jam was a take-home deck plus presentation, and for me it was the most time-consuming part because I spent about 15 hours thinking through the problem before I even worried about slide polish.
Q1. How would you 4x adoption of Uber Grocery?
How they answeredI treated it like a strategy problem, not a quick brainstorm. I spent at least half my time just defining the problem and evaluating different big ideas, because if you are saying 4x it has to be meaningful but still tie back to an MLP you can actually test. In the presentation I led with the recommendation, explained why it won, and only briefly covered the other options I considered. My main focus was building a clean narrative instead of dumping every idea into the deck.
Tips from the candidate
I would prep less for canned product sense prompts and more for weird, practical Uber problems. Know your frameworks, but do not get trapped by them because a lot of these cases do not fit neatly and the interviewers will redirect you constantly. Be comfortable saying 'I do not know' when you really do not know, and then reason from first principles, ask clarifying questions, and bring it back to customer impact. Also be ready for the engineering round to get more system-design-y than the recruiter may make it sound, and tie everything back to metrics because they are very data driven.
Company culture
My read was that Uber is hiring very specifically for real team needs, not just building a generic PM bench. The recruiters were actually super transparent about the process, possible teams, and even how different hiring managers run their loops. The interviews felt practical, metrics driven, and very collaborative, with people interrupting, pushing, and jamming with you instead of sitting back silently. I also felt like they cared a lot about whether I could work well with cross-functional partners, not just whether I could recite a framework. Even for a PM role, they were willing to test technical depth if it was relevant to the actual product area.