Disclaimer: Views expressed here are my personal thoughts.
Anyone who has interviewed Product Managers (PMs) or interviewed for PM roles would tell you that it’s a pretty crazy role to interview for.
You’re expected to be good at a lot of different things and at the same time, you are expected to influence a team of people where everyone is better at their respective functions than you are.
You are expected to ship software even though you can’t write code as well as your engineers can; you are expected to guide the design process even though you can’t play around with pixels as well as your designers do.
You are expected to act as a leader to these teams even though they technically do not report to you.
I recently started a new role as a Product Manager. As I made the leap to product management from being a founder, I went through a set of interviews — some of which worked out and some of which didn’t.
Like anything in life, I learned from the ones that didn’t work and built a set of frameworks that helped me do well in the interviews that mattered.
As I went through this process, I realized that most of the resources around preparing for PM interviews available online, are fairly shallow.
In fact, most of them are really crappy (does the CIRCLES framework really work?). I want to call out Cracking the PM Interview by Gayle Laakmann as an exception because it really is a good book.
That said, I still found it pretty shallow when it comes to areas like Product Design and Data (although it was really helpful in Strategy).
So, I decided to publish a list of missing things I wish someone told me when I was preparing for the interviews.
I also decided to write about this because PM interviews seem fuzzy and daunting at first sight — you’re often told even during interviews that there is no right answer to a question. The set of things mentioned in this post hopefully provide a structure that reduces this fuzziness a little.
In a typical PM interview, you are evaluated on the following areas:
Cracking the PM Interview covers the soft skills and product strategy parts pretty well — so I won’t delve deep into it. In this (rather long) post, I will try expanding on how to answer
For now, I have fleshed out Product Design; will update this post with Product Improvement and Data/Metrics frameworks soon.
(If you are interviewing for a relatively junior role, Strategy rounds may not be present but I have heard that FAANG companies typically focus on Strategy regardless of level of seniority)
You should read this if:
While the hard skills are important, I have seen that many people screw up the soft skills part. This is an unforced error.
Cracking the PM Interview has a set of good tips on how to answer the standard “Tell me about yourself”, “Tell me about a time when…”, “Why this role” kind of questions.
In fact, regardless of the role you are interviewing for, these questions are important and having structured answers for these can come in handy.
A mistake that I see most people make here is relying on just bullets or ‘ideas in their head’ to answer these. That doesn’t work.
You need to write down the entire answers to these questions and rehearse them so that you don’t have to think during the interview itself. I also recommend recording yourself answering these questions and playing them back so that you don’t sound too robotic.
Fun fact — I rehearsed my “Tell me about yourself” about 40 times.
Here are some items that I had fleshed out, written answers to:
No matter your answers to these questions or your proficiency in communication, do not wing this.
Regardless of the level of seniority you are applying for, a PM interview has a product design round. This round is to suss out how you think about products and whether you can structure your answer in a coherent way without going into tangents.
There are a number of frameworks online (like the famous CIRCLES method) but none of them worked for me, so I generated a structure for myself (of course, it’s loosely tied to how the CIRCLES method looks like, but the questions are more specific) — so instead of CIRCLES, it became CIDALDOSI (should ™️ this 😛).
In any product design question, I try to do the following:
This might sound too abstract — so I will try to answer this with an example. Let’s say the question is to Design a parking lot for the future. (If this sounds too esoteric, just wait till you see some of Google’s product questions).
You can find the answer to the question using this framework here.
Although they seem to be lesser asked these days — with interviews turning in favour of product design questions — product improvement questions are still asked. Usually, it takes the form of a follow-up question to the “What’s your favourite product?” question.
As many blog posts note, candidates screw up this questions by mostly rambling about incremental improvements without focusing on a coherent, structured answer.
The framework I use to answer the product improvement question is as follows:
As with the product design question, let me try to explain this with an example. Let’s say the question is — How would you improve Instagram? — our answer using the above framework could be as described here.
Product Metrics questions are a definite feature of any product management interview. People want to assess if you can think in terms of data and numbers.
What they are looking for is not a laundry list of metrics but a neat, concise set of numbers that you as a product manager will be watching on a daily basis, to understand how your product is doing.
This is honestly one of the easiest questions to answer but also pretty easy to screw up if you end up going on a tangent or dive too deep into a metric rabbit hole unnecessarily.
The framework I use to answer this question is as follows:
Continuing with our Instagram example, let’s say we want to define the top metrics for Instagram. We can use the framework mentioned above to answer the question as described here.
As a product manager, you will often have a crisis to solve — your internal dashboard at Uber shows a dip in number of active rides, your internal dashboard at Amazon is showing that product returns are spiking — your job is to quickly get to the root of the problem by digging deeper.
But these are complex systems and so interviewers want to assess whether you can approach the problem in a structured fashion. Root cause analysis problems are usually structured as a follow-up to the metrics question — interviewers typically ask “OK, we know that <metric> has <changed>.
Can you figure out what happened?” This is a bit of a wild goose chase as the interviewer has an answer in mind and wants you to work towards it, but there’s a way to approach it systemically.
The framework I use to approach these questions is as follows:
Make sure you understand how the metric is measured
Eliminate the obvious
Narrow down your scope
Articulate the system and find what changed (change is most likely in one of the following)
Identify root cause and prescribe solution.
This framework might seem a bit ambiguous (it is) and a single question has any number of paths that can lead to any number of answers — it really is at the whim of the interviewer, but by following a skeleton structure, you can avoid going around in circles and make sure that you are not caught in a rabbit hole.
Let’s say you were asked a question like “We know that number of rides with surge on Uber is usually at 30% but it is at 70% now. What could be the reason?”
There could be any number of answers to that question — but using the framework above, we have arrived at one such root cause here.
Preparing for a product management interview can be scary given the ambiguous nature of questions, but I hope the frameworks mentioned above help! Good luck with your interviewers.
You can learn more about Gokul on his blog