Updated by Google candidates
Product Manager, Gemini Interview Experience
I’d never had to do vibe coding live before. In the product design interview, they gave me 10 to 15 minutes to actually build a rough prototype, and most of what they were probing on was how I prompted and reprompted the tool.
Interview process
I got in through a referral for an L7 PM role on NotebookLM inside Gemini. The process included a recruiter screen, a conversational hiring manager deep dive, and an on-site split into two phases: first, product design and execution; then, technical system design and a leadership behavioral. The unusual part was a live-coding section during the product design round, where I had to prototype the thing I had just proposed, and most of the pushback was about how I prompted and reprompted. Overall, it was one of the most practical AI PM loops I have done, and it matched what the recruiter told me almost exactly. I made it to the final round but did not get the offer.
- Recruiter screen
- Phone interview
- Final round
- Technical interview
Interview tips
I would go in already using these tools a lot. If you are not actively using AI tools in your day to day, it is hard to fake the fluency because it shows up across product sense, execution, and technical, not just in the vibe coding part. For the live build, I would have a really simple prompt template ready so I can turn my product sense notes straight into a first prompt and spend less time waiting on generation. I would also show up with actual opinions on the space, because they will ask strategy questions like how Gemini or NotebookLM should position against competitors.
Company culture
My read was that Gemini is very engineering- and research-driven, to the point that the product can feel a bit in the back seat compared with researchers, tech leads, and LLM engineers. They also seem very explicit that PMs are expected to be hands-on with AI tools, including vibe coding, and the interview process enforces that. At the same time, the process itself felt really well run: standardized, accurate to recruiter prep, yet still conversational and collaborative rather than robotic. It also felt a little Google-y to me, in that engineering really seems to run the show, just much more focused on AI work.
Questions asked
Overview
My first onsite block was two very practical rounds, product design with a live vibe coding section and then an execution case, and both felt collaborative and very tied to the actual job.
Question types asked
Specific questions asked
Build a prototype or MVP for the solution you just described.
Why did you prompt it this way?
Are there other ways you could prompt it, or is there something missing?
I approached it like a normal product sense question first, using a mission, users, pain points, solution flow, then narrowed to something I could actually prototype. In the last 10 to 15 minutes I had to live build a rough UX prototype with whatever tool I wanted. The interviewer mostly poked at my prompting, why I phrased things a certain way, what I would reprompt, and what I might be missing. It felt less like coding and more like showing that I can prompt and reprompt effectively under time pressure.
How would you define goals and measure success?
How would you distinguish between model issues and user experience issues?
How would you A/B test a fix?
When would you roll back the model versus iterate on it?
I treated this like an execution and debugging problem, not a product design question. I framed the problem, defined what success would actually look like, and laid out a north star, leading metrics, and guardrails. A big part of my answer was how to separate model capability problems from UX problems using both qualitative and quantitative signals. They explicitly told me not to design a fix, so the whole conversation was really about structured measurement, experimentation, and tradeoffs.
Get full access with a membership, or share your experience to try it free.
