A successful PM interview doesn’t depend on your background or experience; it depends on how well you’re able to structure your answer and problem solve, and how much you’ve practiced. In this episode of the Product Podcast, Google Product Lead Prashant Nair gives us a crash course on how to do it and excel in our PM interview.
I’m Prashant Nair, I’m a Product Manager with Google. Prior to Google. I worked for eBay, Sony, and a few other companies. I started out my career as a software engineer, did that for several years. And around 12 years back, I moved to Product Management. At Google I regularly interview PM candidates. And I also go out and coach members of the community to be better prepared for PM interviews.
Today we obviously don’t have time to go into the depth of all the topics, but I hope that I can leave you with some high-level pointers that you might find useful. Before we start a quick disclaimer, the content presented here are views and practices of my own and do not represent Google or any of my past employers.
Alright, so you are interested in a PM interview. And this crash course here in today is an no way a substitute for developing proper product thinking. I recommend watching my past content at Product School, where I go through all the building blocks of how to be a better Product Manager by cultivating product thinking. As we go through the content today, we will touch upon some of those points again and will reinforce some of those.
The best way to interview for a PM role is to be an experienced PM. And you might already be in a PM role. And that’s great, but I often get asked the question: What if I’m not currently in a full-on PM role, but I’m interested in making that transition? If you’re not a PM it’s still important to exercise product thinking in your current function, you might be in engineering or analytics or marketing. You should find opportunities to cultivate that deep product thinking and partnering very closely with Product Managers. That way, that way you will learn some of the key aspects of being a good PM.
So, one other thing that you can do is talk to your leaders in product and engineering within your org, and try to find a role either in a part-time or a full-time capacity that will help you exercise those PM skills. But you need to go out and seek those roles that will help you strengthen those PM concepts.
And finally, also try to seek out a PM mentor. As you’re working with the mentor on a weekly/biweekly basis, they might help you understand or point you in the right direction to gain those skills that are required. Overall there are several ways that you can start developing those skills and be better prepared for an eventual PM interview.
Let’s get down to the basics of interviewing for a PM role. There are three things that I want you to remember. The first one is to structure your answers. I find many a time great candidates try to cram in a lot of concepts, or they go in all sorts of different directions while discussing their answers. Although they hit some notes, it doesn’t feel like a solid, thought-out, structured answer. It’s very important that you’re not rambling on and providing a structured answer.
The second key point is throughout the interview, you have to keep moving the problem forward and ultimately arrive at a solution. I see many candidates lean on the frameworks that they have read in different PM interview books. They mostly cling onto that and remain at a high-level conceptual stage and never actually move the specific question forward and arrive at specific solutions.
That’s something that your interviewer would be looking for. And then the last point is to distinguish yourself from the many other candidates who would be interviewing for that role try to see if you can leave the interviewer with an innovative solution. Something that helps them remember you as a candidate who stood out and came up with that 10 X solution, or something truly innovative.
These are the three points that we will try to cover in our PM interviews so that you have a well-rounded interview.
Moving on. For a PM interview. As the field goes, there are several different areas, strategy, design execution, technical analytics, leadership, and several more. Some interviewers try to cover all of these points while other interviewers try to hit on one or two of these.
As the interview progresses, and as questions are presented to you, you need to try and understand what area is the interviewer most interested in, and you have to highlight those areas within your answer. That’s important. If it’s not obvious from the question, what area the interviewer is trying to trying to interview you on, feel free to ask them. There are no negative points in asking that, “Hey, should I cover the strategy aspects of it, or should I cover the design aspects of it?”
It’s a fair question. Go ahead and ask them so that your answers connect better with the interviewer’s intent of the question. These are generally typically the areas that would be covered in a PM interview.
Irrespective of the area, here is my biggest advice. If there’s one thing that you take out of this presentation today, it is this: you always have to zoom out. Many times in an interview, you will be presented with a technology, let’s say, “Hey, let’s talk about crypto or autonomous driving or virtual reality.”
No matter what it is if it starts out at a technology level or a solution level, it is important that you zoom out. You should always zoom out and take it to a level to, who are the users and what are they looking for? Unless we understand the users and their needs, we are not going to arrive at a good solution for those users.
No matter where you’re airdropped into in the interview, try to zoom out and, and talk about the users and how you deeply connect with their needs and separate their needs and wants. Spend some time there, try to go deep once you zoom out into who the users are and what their problems are.
Once you identify the users, you have to talk about how are those needs currently being met, and that will take you to the different competitors. One thing I always advise is to try and find the competitors not through competing companies or competing products, but from a user lens.
Let’s take an example of autonomous driving and let’s take a car company out there, BMW. BMW is wanting to launch an autonomous self-driving car. Who are the competitors? The immediate answer that many times you hear is the competitors of BMWs are the Audi or Toyota, or many other car companies.
But that’s not the competition that we are looking to understand. Level it up to the user: the user is trying to get from point A to point B. In that sense, any solution that can take them from point A to point B is the competition. It could be public transport, it could be getting a ride from a friend. It could be Uber or any other cab service even walking short distances could be a competition.
Ultimately you are trying to understand what are the different solutions that the user has today, and then, what is your solution that can make the situation better? That’s what we are looking for. And once you get to that point, then you can start talking about why this particular company you’re interviewing with is in a position to solve that problem.
If you’re suggesting a solution, make sure that you understand why the solution you are proposing is innovative or differentiated. Me too, products. Sure. They could work. But in an interview call, you’re trying to show them that you’re capable of bringing in that innovation or out-of-the-box thinking. Spend a little bit of time to understand whether the solution you’re proposing is truly differentiated or how does it fundamentally change the game. Is it a 10 X solution? Try arriving at that. Also when you’re proposing some out-of-the-box solution, many times it doesn’t feel real because the candidates haven’t thought through, is it practical? Is the technology there yet to deliver such a solution, or is there even a path to get to such a technology to deliver that solution? Many times it’s in the realm of fairy tales. And you want to avoid that.
You want to come across as a pragmatic PM who, who is capable of thinking of big ideas, but also show a path to get to those solutions. In this area, then you will start hitting on, how are you going to roll out such a solution? Or are you going for a global launch or local launch? Are you going to target specific use cases or go for the broadest available use cases? All of that.
What it helps you do the here, and as I’m talking through this, you would see that zooming out and then systematically diving in structures, your answer. No matter what question is being asked you are able to hit all those points that say, “Hey, look, I understand the user. I understand the market gaps, I understand competitors. I can propose solutions. The solutions are really innovative. I can tell you why we are the best team to deliver it. I can tell you how exactly I’m going to deliver it step by step,” et cetera.
That structure becomes really important, and that’s what you’re trying to nail. So no matter what the question if you practice this, it will make you stand out as a candidate who has provided that structure.
Alright. The second area that I often get asked a lot is how much do I prepare for the technical interview? PMs are often anxious because many of them haven’t touched code in past years, and they’re like, “Hey, look, I’m interviewing with these companies. Do I need to know all the algorithms, do I need to know the code?”
It depends. If you have recently made a switch from engineering to Product Management, you would be expected to know a little bit more, if you have been a PM like myself for several years hopefully they appreciate the fact that what they’re trying to understand is whether this PM can work really well with engineering teams towards a solution. In that capacity, you definitely need to know the base.
You need to understand that, given an area if you want to search through it, I can go step by step linearly. Or if it’s sorted one, I can gain some efficiency. You need to understand some of those basics, not necessarily at the code level. But yes, you need to be technical enough to understand the basics. And the second part of it actually is developing a genuine curiosity about how all these different systems come together to create a good product.
And think of modern solutions. How are notifications pushed to you as soon as it happens? How is it that I type of message and it is delivered almost instantly anywhere in the world? What are those systems that make it happen?
What are the different types of messaging solutions? What are the different types of database solutions? You kind of need to develop an understanding of that. One way to do is to think through, how does Uber work? How does WhatsApp work, how does Google type ahead? Or any of the numerous technologies that you use on a day-to-day basis, just think through it. Go a level deeper as to how is it being delivered to you. What are the systems that would make it happen?
As a starting point, I often recommend this lecture from David Malan to my students. It’s available on YouTube. It provides a good starting point. This lecture is about how would you a build large-scale dynamic website. Use that as a starting point, and it’ll lead you down the rabbit hole of many such topics. And there are several talks, lectures, even mock interviews out there that will help you. That’s how you prepare for the technical interview.
And the area that my students often are anxious about is the analytics interview. You have to pick a framework for structured answering of an analytics question. A framework or any framework out there would cover the business metrics and option metrics, engagement, survey troubleshooting, et cetera. Once you have those metrics down, you need to talk about the dimensions as well. Are you looking at segmenting that metric by the customer type or by the user type or by geo and those dimensions comes in trends over a period of time.
You can have this framework in your mind, but I’ve seen many candidates, they just talk about the framework and they often fail to connect that framework to the specific question at hand. Let’s say you’re talking about a particular solution and you’re asked, what are the metrics for that particular solution. Use that framework as the guardrails, but then connect it specifically to your solution. Let’s say the engagement metrics for self-driving car would be very different from the engagement metrics for work from home suite of product. You always need to connect it back to the specific solution you’re talking about.
Then we come to the leadership aspect. Often these questions come up, if you are applying for a senior enough role. One thing to always keep in mind is more and more we are trying to build responsible products. Responsible product means not just understanding the business metrics and the needs of the immediate user but to think about how does the product impact the community overall? What’s the true impact on the world? Is it positive? Is it negative? Have a sense or start developing a sense of all that.
And then one thing that I often look for in candidates is, are they shy from making bold decisions? certain I bring up certain scenarios where the right answer is actually to shut down the product or shut down a certain aspect of the product. And I see if candidates are bold enough to take that unpopular, but often needed decision. Those are the leadership aspects.
Alright. Hopefully all those pointers help you in preparing for the PM interview. The key thing to do once you have grasp all that is to practice looking at the everyday products around you. I mentioned a few. Think how would you as a PM improve it?
It may not be just technology solutions. Think of how would you improve your microwave, or how would you improve a standup desk or what have you. Look at the products around you every day and go through the process of thinking as a PM, how would I improve this? This automatically puts your brain to start thinking in that structured aspect that we talked about.
The second one is to look at emerging technologies and how could it significantly improve lives. What would cryptocurrencies have an impact on the world, or self-driving cars? How would they impact the world? 5g, how does that improve humanity overall? Keep thinking through all that, as you practice for your interview, practice in front of a mirror, or record yourself. Because you need to be comfortable with your own voice. How do you modulate it? Where do you pause? You need to be really comfortable. Put that practice in.
And finally, do several rounds of mock interviews. Call up a few friends tell them, “Hey, interview me. Talk to me, ask me questions about products,” et cetera. Mock interviews do not mean, let’s get on the phone and chat about a few questions. No, actually do the role play. Through the process of a proper interview, do a 45 minutes interview and 15 minutes of debriefing of what you did well, what could be improved, et cetera.
This could be a key differentiator. Absolutely. I cannot recommend mock interviews enough. Do it. And then when you feel that you have practiced and you are ready, go out and practice them more. This is the opportunity before the interview to keep practicing and be perfect and have most of those things covered. Again, don’t be too rigid. Because in the interview your thoughts and your ideas and how you think on your feet, those things should shine. Many times I’ve seen candidates come in very rigid with a particular framework in their mind.
And if you throw in certain counter questions, it throws them for a task. Know all of that, but again, bring your whole self to the interview and you would do good. There’s no substitute for practicing, there’s no shortcut.
Hopefully you find all these high-level pointers useful. We can engage more deeply through product school. I’m trying to see what courses we can set up so that we can take you deeper into this area. Meanwhile, if you want to reach out feel free to do so on Twitter at @PMtogo and I’ll try to engage with you and help you out in your PM interviews.