Updated by Uber candidates
Senior Product Manager (5A) Interview Experience
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.
- Recruiter screen
- Phone interview
- Final round
- Take-home project
Interview tips
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.
Questions asked
Overview
The 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.
Question types asked
Specific questions asked
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?
This 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.
This 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.
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?
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?
I 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.
If a very senior stakeholder tells you, 'I need you to fix this,' how would you respond?
What if they say, 'No, I want you to look at it'?
I 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.
This 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.
Get full access with a membership, or share your experience to try it free.
