
How to Pass the Product Manager Interview - sweaver
https://medium.com/@samuel.james.weaver/how-to-pass-the-product-manager-interview-cf27ee936cb3#.l6fakk6ps
======
dahart
> 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.

~~~
6stringmerc
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.

------
arafa
Brain teaser questions don't perform well in studies and should be avoided:
[http://qz.com/378228/google-is-over-those-ridiculous-
brainte...](http://qz.com/378228/google-is-over-those-ridiculous-brainteasers-
but-some-employees-didnt-get-the-memo/)

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.

~~~
jpadkins
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.

~~~
mdorazio
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.

~~~
jpadkins
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.

~~~
mdorazio
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.

------
sageabilly
"...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.

~~~
cwe
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.

------
nzealand
> 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.

------
n00b101
> 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]

[1]
[https://en.wikipedia.org/wiki/Fermi_problem](https://en.wikipedia.org/wiki/Fermi_problem)

------
omgitstom
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.

------
ffumarola
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.

------
jnpatel
Are there any other must-read/watch resources for first-time PMs?

~~~
kylelibra
Start with this list: [https://medium.com/@noah_weiss/50-articles-and-books-
that-wi...](https://medium.com/@noah_weiss/50-articles-and-books-that-will-
make-you-a-great-product-manager-aad5babee2f7#.pfl5ymn8t)

------
totalrobe
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

~~~
dang
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.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

~~~
yanilkr
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.

~~~
dang
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.

