Updated by Uber candidates
Senior Product Manager Interview Experience
Rehearsing your take-home top-down isn't actually that helpful. There were so many curveballs thrown in the middle of the jam session that it would be almost impossible to just read a script and go slide to slide — you need to be on the tip of your toes.
Interview process
The process was a short recruiter screen, then a hiring manager round that spent way more time on an older role on my resume than on my current job, plus a rushed mini jam at the end. After that I had to do a take-home deck for an events marketplace prompt and present it in a one-hour jam panel, then go through three more final interviews spread across three days. The loop felt inconsistent because nobody besides the hiring manager was actually from the team, and each interviewer had a completely different style, from rapid-fire generic PM questions to aggressive marketplace probing to a bizarre senior director case. I got rejected, but Uber did send unusually detailed written feedback afterward, which almost made it more frustrating because the strengths section was so strong and the main ding was marketplace economics that felt very insider-specific.
- Recruiter screen
- Phone interview
- Take-home project
- Final round
Interview tips
Do not only prep stories from your current job. They went straight to the most relevant experience on my resume even though it was old, and I had to reconstruct results live. For the jam, know your framework but do not cling to it too hard, because if you stay in clarifiers too long they may cut you off and ask for the actual solution. If the prompt smells like marketplace, be ready for repeated pushback on driver incentives, earnings, ops, and support consequences. Also prep experimentation more deeply than just naming metrics. Think pilots, A/B tests, cohorts, and explicit launch criteria.
Company culture
Outside of the hiring manager, I did not meet with the actual team, so the loop felt like a generic Uber PM loop more than a targeted team match. The interview prep docs and labels did not line up that well with what I actually got. Several rounds were much more probe-heavy and adversarial than advertised. The one positive was that they did give real written feedback afterward, which is rare.
Questions asked
Overview
The final round was spread across three days and felt like three straight days of getting grilled. It started with the one-hour jam panel, then a PM round, then a technical round and a senior product leadership round. What stood out was that none of these people were from the actual team, so every interviewer brought a totally different style and set of assumptions.
Question types asked
Specific questions asked
Why did you choose dedicated pickup zones for the event experience, and why not a different solution?
How would this affect driver earnings?
Are you penalizing drivers with this flow?
How would support handle this operationally?
What other marketplace problems could this create across riders, drivers, and support?
From my title slide they were already interrupting, so it turned into a rapid-fire defense instead of a presentation. I explained the dedicated pickup zones, rider credits for walking there, and the FIFO driver queue as a way to reduce cancellations and chaos. The toughest pushback kept coming back to driver earnings and whether I was hurting drivers with extra wait time or constraints. I tried to talk through tradeoffs across riders, drivers, and the support center, but it definitely felt adversarial and pretty brutal.
This round was basically generic PM essentials asked one after another. I answered with examples about cross-functional alignment, unblocking engineering, and how I prioritize, and I tried to inject data and outcomes even when the questions were broad. The weird part was there were almost no follow-ups at all. It was just me answering, hearing 'okay,' and then getting the next question, so it felt more like surviving a queue than having a real conversation.
How do you work with data scientists and engineers?
I thought this part actually went well as I frequently partner with data science and engineering already.
I walked through how I think about balancing new features against tech debt, using examples of how I trade off speed, risk, and longer-term platform health. It felt straightforward in the room, which is why I was surprised later that I still got flagged on technical experimentation nuance.
How would you structure the experiment?
What A/B tests would you run?
How would you use cohort analysis?
He wanted an experimentation framework more than a product idea. I talked through launch criteria, success metrics, and how I would compare autonomous and human-driven experiences, then he kept drilling into A/B testing and cohort design from a data science angle. I was not really expecting that level of experimentation depth from the prompt, so I had to pivot into methodology mode pretty quickly. In hindsight I should have gone deeper on experimental design earlier instead of treating it like a normal metrics question.
In the Netherlands, if couriers are employees instead of contractors and you cannot require certain hours or penalize missed shifts, how would you improve meeting the delivery promise window?
Would you use in-app guidance?
Would you add an achievement bar or rewards?
How much would you pay people to change behavior?
This one completely threw me. I understood it as a regulatory and incentives problem where supply was not matching demand, but you also could not force behavior the usual way. I started brainstorming things like in-app guidance, rewards, and achievement-style incentives to nudge people into taking more shifts or blocks, but I was fumbling for most of it. The interviewer was very senior, pretty cocky, and I could tell he knew I was struggling, which made the whole thing feel even more unhinged.
Get full access with a membership, or share your experience to try it free.
