Acing Your Product Manager Interview

I’m a Senior Product Manager at Google and was also a PM at Facebook. I’ve done over 100 product management interviews, shadowed PM hiring committees, and created a class called “The Path to PM: Learning if Product Management is Right for You” through which I’ve shared these thoughts with thousands of Googlers. I’ve mentored a number of folks who have then successfully transitioned into the PM role.

My hope with this article is to give prospective candidates their best shot at showing off their thinking and creativity during a PM interview. Please note that all of the below are my personal opinion and in no way shape or form should be considered official Google guidance. (Other Googlers will likely disagree with all of the points in here.)

Practicing for a PM interview can be a lot of fun and will help develop skills you’ll actually need to use regularly on the job. Most great PMs are made, not born, so the good news is that you can develop many key PM skills if you’re coming up short in an area. Another piece of good news is that there isn’t a singular archetype of successful PM; they come in many different flavors and forms: the Designer PM, The Data PM, The Hacker PM, etc. (Maybe I’ll save a description of these archetypes for a later post.)

Some of what I’m looking for is attitude — a PM not only needs to get along with other PMs, they are the cross-functional glue across Finance, Legal, Marketing, executives, and most critically, Engineering. To have the role work, you probably need someone who is a good mix of friendly, curious, opinionated, engaged, humble, and excited.

The best way to practice for a PM interview is to have a friend (ideally who is themselves a PM) ask you questions of a rough form “How would you design an X [kind of product] for Y [demographic of user]?” Being able to quickly articulate who you’re building it for, why they will care, what the product does functionally and visually, and how you’ll bring it to market. Consider flipping things around and yourself interviewing someone you know is a great PM to observe how they answer questions.

For the actual interview itself, here are my recommendations:

Get comfy. Don’t worry about how you’re dressed. Dress however you feel most comfortable. If you’re in a three piece suit and uncomfortable about it you probably shot yourself in the foot. If you’re at home in T-shirt and jeans, wear that. And itt’s simple, but if you’re thirsty, make sure to grab a bottle of water. If you need to pee, ask to go to the bathroom. You won’t get dinged.

Focus on the user. As a PM, your primary job is to identify a potential user in a clear demographic, empathize with the problem they have today, visualize an improvement to their condition, and spell out the solution in sufficient technical detail to be realizable. The whole experience will need to account for how the user finds out about the solution, what makes it compelling, getting them as quickly as possible to an “AHA!” moment, and the dynamics that would compel them to pull other people in their network into the experience.

Visualize. Once you have an idea for the user story, help me see what you’ve built in your mind. Use a whiteboard, your hands, whatever and walk me through what the user sees, what they need to do in detail. If it’s a mobile app, sketch out the main screens and what someone will see. Make sure that the most important information is most clearly displayed to a user; hide complexity. Infer as much as possible to reduce user load. PMs do not have to be gurus with visual design, but they do need a sense of UX and information theory. Can’t hurt to have read Tufte, either.

Build a business. With a solid user story in hand, you should have an understanding of how the economics of your product are going to work. What is it going to cost you to acquire users? What is your likely lifetime customer value? What will it cost you to support your user? While it is true that “No business plan survives first contact with a customer”, you need to know whether your idea could possibly be economically sound. A simple “LTV > CAC + S” (lifetime value is greater than customer acquisition costs plus support) is a good way to begin the discussion. Finer details like applying an appropriate discount rate to reflect the time value of money can be worked out by your fine peers in Accounting.

Be open to “play”. While you should clearly articulate where your firm knowledge ends and your wild speculation begins, you should also feel comfortable in speculative territory, calling out your assumptions, however feeble they may be. Bullshitting is confidently saying something you’re not sure if is true. Don’t do that. Clamming up is refusing to discuss things you don’t know with certainty. Don’t do that either. ;) If your interviewer hands you new data mid-question that may challenge your assumptions, nimbly incorporate and revise as needed — or, as appropriate, put those data in context and charge ahead!

Give a crude answer quickly. Don’t rathole on fine details; instead, quickly get to a provisional approximately correct answer and then iterate to refine as needed or if in working it out it becomes clear you need to abandon and restart, do that. This is a “breadth first” exploration; go deep where prompted. Your interviewer may be trying to get to 3–5 completely different questions in a 45 minute slot that generally includes a 5 minute warmup at the beginning and a 5 minute “turnaround time” at the end. So it’s really actually just a 35 minute interview! With five questions to ask, that could be 7 minutes per question.

Reason from first principles. During the technical part of the interview in particular, it is always even more impressive to me if someone is unfamiliar with a specific piece of technology but can use their general technical knowledge to correctly infer how it might work. So if someone knows how public key cryptography works but isn’t familiar with the specifics of TLS certificates, they could infer how they might practically work, that is a slam dunk for me.

Don’t just answer with process. Don’t spend all your time describing a process to get to an answer — describe an actual answer. It is understood that an interview is a limited scenario. If someone asks you to design a television for the elderly, don’t say, “well, I’d need to go and spend time with the elderly to begin to know how to answer that.” You can call out that this kind of surface area contact in product development is ideal — even necessary — but it’s obviously something we can’t incorporate into the interview itself. So charge ahead.

Check in. Don’t just monologue and hold forth for half an hour; if you find you’ve been talking with little to no response from your interviewer, pause to do a time check and ensure that you’re spending your time answering what they’re looking for or if they can guide you to spend more time digging in on things they’re interested in. I’ve had candidates hold forth on me without pause and it can be awkward for both parties if the interviewer needs to jump in and interrupt you to get you to move on. That said, don’t just repeat back the question to buy yourself time—while clarifications are fine, stalling is annoying.

Vocalize. It’s better to talk aloud through your thinking and backtrack, even calling out your idea of a minute ago as dumb, than to wait until you’ve got the perfect thing to say. Expose your thinking.

Be pragmatic. Fancy technology should take a backseat to pragmatism — be willing to propose solutions that start off “hand cranked” and then build technology to support them later. You can start a huge number of businesses/products with an Excel spreadsheet, a human with a cell phone and a car, the ability to process a payment, and a mailing list. A great product answer is something that could potentially be tested in a week.

Use tools. ANY tools you bring with you are fair game and you should make use of them if they will help you structure your thought process and argument. If there are post-it notes, feel free to use them. If you brought a notebook, feel free to organize your thoughts there. If there’s a whiteboard in the room, put it to work — I’ll note that every interview I’ve ever done has had a whiteboard on the wall.

Be bold. My favorite interviews are ones where candidates come up with something really specific and zany, to the point of being controversial or shocking. Naturally, a dramatic proposition needs to be coupled with rationale that can be talked through, but this is one of the biggest areas where I see highly polished and experienced professionals bomb a PM interview. They give reasonable answers to questions but lack depth or novel insight. You should have an opinion about what’s wrong with the world around you and how you can help fix it. You should be able to talk about where the industry is going and what its blind spots are. A fantastic candidate will set the interviewer’s mind reeling with an answer they’ve never heard before. So in short, if you have a really out-there concept, don’t bite your tongue and stick to the tried and true! We want to see your crazy side.

At the end of the interview, if you feel like you had a fun and engaging brainstorm with the interviewer and are full of energy to go build something, it probably went well.

The overall process is usually a recruiter phone screen followed by a PM phone screen, followed by an onsite panel of 3–5 back-to-back 45 minute interviews, where each interviewer may have a different “hat” on to assess one aspect or another of PM excellence. After your onsite interviews, the interviewer feedback is collected and sent to a hiring committee (not including anyone you’ve met in the process to date) and a hire/no-hire decision is made.

What not a lot of people realize is that it’s actually much better for your odds if you have two fantastic interviews and one that was only so-so instead of having three good-but-not-amazing interviews. This is why it pays to be bold.

Finally, a lot of the process really is the luck of the draw. A place like Google gets far more excellent applicants than there are available roles to fill, which means that the process knowingly discards a lot of really fantastic folks. Much of it will come down to the people selected to interview you and the personal chemistry you happen to strike with them. Don’t beat yourself up if things don’t work out; I failed my first several Google interviews decades ago!

I wish you the best in your exploration. Let me know how it goes and if these tips were useful to you and how I can improve them.

• David

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!