How to Pass the Product Manager Interview
medium.com> Prove you can prioritise
Of all the PMs I've worked with personally, this has been the single largest problem. A PM that has patience and knows how to pick and stick to the most important thing until it's done is worth their weight in gold. It takes balls, because priorities always seem to change from day to day, management applies pressure to the PMs to get more done than is realistic, and engineers are fickle and perfectionist and usually slower than they predict. I've seen a good PM walk this line, but people who can do it are rare. I'll take someone who really can do the job of prioritizing well over someone who knows a lot any day.
Having worked in a couple, maybe even a few hundred RFP type B2B submissions as the Proposal Writer (aka RFP PM) the one thing that was out of my control and was most frequently the last thing completed was the actual price to put on the submission. So many stakeholders. So much drama. So many times of saying "I understand this needs to be the right price but if you miss the deadline then WE LOSE 100% of possible revenue. SEND IT TO ME NOW...please Sir/Madam..."
Comparatively speaking, the lower on the totem pole, the easier it is to get compliance. It's the higher-ups of the world who, in my opinion, tend to think of themselves as exempt from "getting with the program" until somebody pulls rank. I hate pulling rank but if the chain needs a yank, it's for the project and company, not me.
Speaking as a PM, you've basically highlighted the most important part: management.
The job of a PM isn't to translate fickle external whims into a constantly churning set of priorities. That isn't management. It's reaction. And it's worthless.
A real product manager manages those competing interests and influences, and translates that into a focused, steady set of priorities and an overall direction. And if priorities must change or direction must move, that PM must make those decisions carefully, and must exude a sense of focus and control when doing so.
This is really true for all jobs, especially as you start managing things.
As a PM I almost totally agree with you. There's a caveat, though. I know what I want, and in general, I want everything well done and polished.
But the right question is not "What do I want?" but "What need to be done?". That means having different priorities than my wishes and understanding the work on some non-sexy features that will make the product stronger in the long run.
One thing I noticed, though, is that what needs to be done could change, in a startup environment pretty quickly, and having been on the other side, it is pretty difficult to understand. So you need to communicate clearly why priorities are shifting, and you need to be able to take the blame if they are shifting due to a mistake you have done.
Anyway, my suggestion to any wannabe PM: Thinks of what is important for the product, not what you (or the stakeholders) want in the product. Second, be clear in your communication.
Brain teaser questions don't perform well in studies and should be avoided: http://qz.com/378228/google-is-over-those-ridiculous-brainte...
Google suggests doing behavioral interviews instead (which I've also been trained to do and have gotten good results). Technical interviews and such may be necessary as well, of course.
When I was interviewing, I loved brain teaser/market sizing questions because they were completely formulaic and easy to ace. They test nothing but "does this person know how to answer this type of question": take your time, think out loud, come up with some type of structure, try not to screw up any basic math.
Now that I'm an interviewer, I stay away from them completely. :)
I would say I would -never- base a hiring decision on someone who was poor at answering a market sizing or logic question. However, I do like to see candidates with determination to try and answer, explore multiple possible answers, and remain cool during their reasoning. To me, it’s reflective of your working style and PM’s must remain calm, rational, constantly thinking of all possible options to solve a working challenge.
But is there data to support that these questions are effective in finding the types of people that you want? Without concrete and consistent answers to questions, you'll be exposing yourself to bias (subconsciously encouraging people like yourself or seeing their vague answers in a more positive light). You'll also make more of the interviewing experience dependent on what you happen to think of and the mood you're in at the time, increasing the inconsistency of your interviews.
I know the intuitive idea is that you'll get to see how the candidate reacts, but that can be done in a less arbitrary way (and in a job-dependent context) through behavioral interviews and the like. Brain teasers are also often poor candidate experience, since they can feel unfair and unrelated to the work. If estimation is a key feature for PMs, it should be part of the interview process with well-defined procedures.
How does one train in behavioral interviews? Is there a methodology around it that can be adopted by someone who wants to build it into his startup's hiring process?
You could adapt something like this to fit your needs: http://www.businessinsider.com/google-laszlo-bock-interview-...
This will give you the general idea of how they work. I'm sure there's classes and other resources, but we already have a training program at work so I haven't delved into them as much.
I do a lot of PM phone screens. I don't ask brain teasers but I do ask basic math problems (i.e. drake's equation type problems). They are very good for screening out candidates who won't be able to do the analytical part of the job.
1) That's not a "basic math problem", it's exactly the kind of brain teaser/gross estimation problem this thread is saying doesn't work. 2) You're going to need to explain to me how estimating the number of communicative extraterrestrial civilizations in the galaxy (or a similar question) is an indicator of how well a person can understand a product's features, tech stack, and customer needs. Unless your product is something related to statistics, you're just screening out people who aren't like you.
One variant I ask is 'estimate the number of delivery drivers needed to start a same day delivery service in a city'. Do you think this is a brain teaser or not? This is clearly not a statistics product...
I find PMs need the ability to break down problems into manageable pieces to calculate, and estimate things with lots of ambiguity. How else do figure out whether an idea is viable or not, and worth spending more time on going deeper on?
And I meant to say fermi problems, not drake's equation.
Yes, that's an interview brain teaser of the exact variety Google and others have found doesn't indicate much in the way of actual job capability/fit. As someone else in the thread pointed out, anyone can look up the methodology for answering these types of questions in about a minute, and be able to tackle all of the variants easily with little actual thinking.
I agree that product managers need the ability to break down big problems (or requirements/client requests/company direction) into manageable pieces for their team to work on. However, there are better ways to gauge this ability, such as...
- Ask directly for an example of how they have taken a big problem or assignment and broken it down in the past
- Give them a real-world big problem you've had recently and ask them how they would break it up into team tasks/user stories/whatever you use
- Ask them to explain their methodology for determining how long something will take to build or test (ex. some people love planning poker, other people love logarithmic buckets, other people base estimates on experience, and others do something completely different)
Basically you'll get a lot more value out of interviews if you ask directly for experience or process they'll be using rather than trying to back into a skill estimate using a brain game.
> They are very good for screening out candidates who won't be able to do the analytical part of the job.
It's very unlikely that you have any way of knowing that, since you don't know how good people who fail would have been at doing the analytical part of the job.
"...what the product is, what it’s used for, what problem it solves and how it solves it"
Have you seen some tech websites? I used to research competitors as part of my prior job and some of the tech websites out there do a really bad job of explaining what their product IS, much less what it DOES.
For those of you here on the flipside, make sure your website explains WHAT you do, and more importantly, WHY I should care enough to call you and give you money. When I'm dealing with potential vendors/technology partners I am 100% more likely to call a company that tells me why I should care up front than a company that's blowing smoke on their website and doesn't want to tell me why I should care until I call them and talk to a sales rep.
Good PM interviews I've been in use that as part of the discussion. Discuss the issues with the messaging on the website, ask for clarification where needed to understand the customer and problem, and go from there. You shouldn't just focus on the current as currently exists, but the core problem/vision they're going for.
> Don’t bullshit
If someone simply abruptly said "I don't know" without any follow up, then it would give me serious pause for concern.
By all means, be succinct. Admit you don't know. Ask if the interviewer wants to hear your methodology you would use to get to an answer.
A good PM tailors the message for their audience. My experience set is different from OP, I interview product managers in the non-technical B2B space.
> I like to throw in market estimation ... questions
FYI, this is known as a Fermi problem, named after the famous physicist Enrico Fermi. The classic Fermi problem is, "How many piano tuners are there in Chicago?" [1]
Every company will want a PM that understands their vertical. This isn't as simple as researching, a PM should never interview without using the product and using as many of the competitors products as possible.
Every company wants a PM that is a jack-of-all-trades. This could be any degree of technicality, UX skills, marketing skills, developer skills, design skills, customer success skills, sales skills, and PM skills (prioritization, specs / user stories / strategy / go-to-market / scoping / shipping etc). If you aren't a jack-of-all-trades, pick up some hobbies / books / go to meetups to make yourself as well-rounded as possible.
Every company wants someone that is deep in one of the areas above.
Commonalities between companies are they want someone that is a foot deep across every skill set, and a mile deep on one skill set.
Figuring out where you fall on the scale of things and make sure you find a company that is looking for your exact strengths is the most important thing to pass a PM interview. Screen the company as they would screen you. Once there is a match, then Sam's advice kicks in if they are looking for a Technical Product Manager.
For aspiring PMs, I highly recommend taking a job in customer success as a gateway into product management. You learn a lot about working with customers, prioritization, and should be aligned with seasoned PM's at the company for advisement and mentorship possibilities.
As someone else who interviews a lot of PM candidates, I have to admit that my process is quite different.
- Understand the product, target audience, competition
I don’t really care if they understand the product during the interview process.
The purpose of the interview, in my opinion, is to see if they have good product intuition, a well reasoned problem solving framework, strategic insight, leadership qualities, mental horsepower, etc. If these things exist, they can learn about my product, target audience, and competition.
In fact, I actively prefer to not talk about the products I work on because it leads to a biased and loaded conversation. It’s a lot harder to impress me when it comes to something I think about every single day, especially when you’ve only had 3 days to think about it. However, if we both talk about Medium, for example, the playing field is leveled and the candidate will feel more comfortable.
- Metrics
Metrics absolutely matter. But if you’re letting them lead the conversation based on projects they’ve worked on and just talking about metrics they measured, your results will obviously not be calibrated.
I much prefer to ask a calibrated question that allows me to compare candidates to each other. Ideal questions walk through defining metrics that would dictate success for a certain product, outlining how to run experiments, and then walking through a fictitious metric drop to get an understanding of how they would decompose the problem.
- Don’t bullshit
Agreed. But I would prefer “I don’t know, <insert follow up questions to get to an answer>” when possible.
- Prioritization
Agreed, they should have a good framework for prioritization. I like to couple this with a product intuition question where we’re riffing off of each other to come up with solutions to a problem.
- Engineering Divide
Sure. I think it depends on the role, and if this is ideal for you then that’s reasonable.
- Brainteasers
Brainteasers are easy to game and don’t mean anything. Google famously published that brainteasers are not effective at predicting outcomes.
You can test their ability to make assumptions, tackle a problem, etc without giving brainteasers.
Are there any other must-read/watch resources for first-time PMs?
Start with this list: https://medium.com/@noah_weiss/50-articles-and-books-that-wi...
Haha this is a funny little idealistic article. If any company actually hires like this I'd like to know.
Want the job? This is the real selection criteria at west coast startups:
1) Went to interviewer's school and/or worked at my buddy's startup
2) Drinks the kool-aid? i.e. willing to work 60+ hrs/week below market
3) Previously held self titled "Chief Product Officer" position at "startup" that failed after 3 months
Please don't post substanceless, snarky dismissals like this to HN. If you have concrete experiences that are relevant, those would be a basis for a much better comment. But rage-driven overgeneralization is something we want less of here.
I am not sure you are moderating this right.
That comment was very insightful. People hiring product managers would now know how some others in the company think if they brought in friends or candidates with inflated titles.
One of my very talented friends quit his job for the exact reason. There are CTOs who do not know the difference between java and javascript. We tried to hire an accountant who had a title "Advisor to startups" after talking to her for few minutes we had to rethink hiring.
I disagree that it was insightful; it's a collection of clichés that appear here frequently. The phrase "west coast startups" is particularly spurious, putting down a specific region. Generic comments about idiots are bad enough, but provocations about idiot distribution are worse.
The specific experiences you describe in your comment are another matter. That kind of thing is substantive and can be the basis of a thoughtful comment.
Sure - that's how most places usually hire their first product manager, if they're not just promoting from within. Honestly, that's how most early-stage startups hire pretty much anybody.
If the company continues to succeed in spite of itself, eventually that guy (it's almost always a guy) gets sacked and they bring on someone who's at least managed a team of product managers elsewhere. The new person almost always has a hiring process similar to the one in the post, having either figured it out from experience or from reading one of the many articles very very very similar to this one.