>
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