
I don't get the product manager hiring process - BrightlyAbsurd
I started as a technical project manager over 10 years ago and slowly moved into product management in my last job almost 5 years ago. Cannot say it is a very successful product (due to the technology and market choices, both made without me at the very early stage of the product).<p>But the reason I&#x27;m writing this post is to say I don&#x27;t get the hiring process for product managers. And before I go ahead, I accept that the problem can be with me and not the process. But the process feels entirely superficial and arbitrary to me. The typical problem given at the interview is like &#x27;Design a solution to the problem X&#x27;. What exactly to do next is an entirely subjective choice. I&#x27;ve read the famous &quot;Decode and Conquer&quot;, but even then it leaves a lot to be answered. In the end you are not really solving the problem, you need to please the interviewer instead. Do they want you to challenge the problem first? Do they want you to challenge the suggested technology to solve it (why do we want to build a bot and not a mobile app?) ? Do they want me to dive straight into making hypotheses? Design solutions?<p>It feels that the key to pass a product manager interview is to find an interviewer on the same wavelength with you. Probably I&#x27;m just venting, but not sure if anyone else feels the same or maybe you have any tips (including &#x27;change your job!&#x27; haha)
======
vii
This is the paradox of interviewing for senior roles of all kinds: the real
work is long term over years and needs careful decision making, but the
interview is under an hour.

Well structured thought and the ability to communicate and adjust priorities
are key skills for PMs, whereas the actual design of the solution, defined by
input from experts across disciplines, is less important. Pleasing the
interviewer as the main objective may actually be a good way to demonstrate
capability for this role of PM (distinct from subject matter expert roles).

------
Jugurtha
> _Do they want you to challenge the problem first? Do they want you to
> challenge the suggested technology to solve it (why do we want to build a
> bot and not a mobile app?) ? Do they want me to dive straight into making
> hypotheses? Design solutions?_

Not your interviewer, but all of the above. There are very few cases where one
is looking for _the right answer_ when it exists, but for open questions like
these, you're hiring for _thought process_ , _problem solving methodology_ ,
_nuance_ , an awareness for _tradeoffs_ , and the ability to make decisions
while aware of the hypotheses that led to that decision. The answer to the
question X is _it depends, [and then methodically giving the branches of
reality and their assumptions and how the tradeoffs play with each other]_.
That's valid for individual contributors. The last thing one wants to hear
"Scala is the best, and I'll write the front with React because it solves
everything". One might accept the "I'll write it in Scala because that is what
_I_ know, unless the team uses something else which I'll have to pick up, but
I'll need time to be proficient in."

This is elicited with questions to figure out: is this a problem? why is it a
problem? what's the desired state? can we arrive at that state by not solving
this problem [i.e: not swimming across the river, but simply taking the
bridge]?

There may of course be people who'll ask you a question for which they figured
out the answer the day before the interview after a year and a team iterating
over it. There are people who'll ask you questions about some flag you must
set when compiling a database from source for some obscure optimization
problem they had hit developing the product, and we're not talking about these
people.

You have a lot of experience in projects, and the interviewer wants you to
demonstrate all that experience, the awareness of tradeoffs and _pitfalls_ ,
and walk them through the design process of a hypothetical or actual product.
Similar to when you ask someone who spent a lot of time on the road "What's
the best route from point A to point B"? and getting "It depends. If you're
coming from X at 9, forget it because construction workers start at that time,
but you can take an alley if the burger truck isn't there yet. Fridays it
comes in a bit late.".

An interview could actually be implementing something for real. As in, chat
with the candidate about things they find interesting or cool, or things
they've workd on before, and then deciding "let's do it" on the spot and set
up a repository and start working on it, as in create the issue, specifying
it, and then implementing it. Sometimes you'll do different parts of it.

In other words, you seem you have the capability to zoom out and zoom in on
details, and people want to see you do this.

> _It feels that the key to pass a product manager interview is to find an
> interviewer on the same wavelength with you._

It doesn't hurt, but it's mostly "Can I trust this person to lead the team and
product effort and be independent and figure out proper solutions at different
times for different problems, and do whatever it takes to make this a success
and groom people and encourage them and help them get back on track if they
fall off, and listen to different objectsions and inform me of problems we
might hit". Basically, can I hire this person and "sort of" forget about them.
There is a kind of people that, when you know are on a problem, you can sleep
well because they'll only come to you when you are really needed, and they can
tell when you are and when you are not needed.

One book by Belkiov, entitled "General Methods for Solving Physics Problems",
is really interesting, because one spends many years solving physics problems
and beeing "zoomed in", and it is such a pleasure when one reads something
from an author who has a big picture and shows you "Here's physics, and here's
how to solve problems in physics". Just the way he formulates what a physics
problem is amazed me.

Other books:

\- "The Complete Problem Solver" by John R. Hayes

\- "How to Solve It", George Polya

