Product managers have a few different jobs depending on the organization we're working with, but inevitably we find ourselves doing a lot of organizing and a lot of communicating. In the course of my career I've been through all kinds of product interviews - they almost all follow a common pattern: Introduction Call → Fit and/or Tech Interview → Homework → Fit and/or Tech Interviews (repeat) → Senior Manager conversation → Offer → Negotiation
I think that it's important when someone goes through this whole process that a hiring company consider that it's being evaluated by the product manager and that we tend to apply our product-thinking to many situations, especially those related to work. In that vein - the product interview process should identify the acceptance and rejection criteria while wasting the least time. In that vein, reducing the number of conversations between the homework and the offer is an obvious place for optimization.
Every interaction should be an opportunity to evaluate these skills and provide context for fit. In the interest of talking about discrete issues or suggestions, let's dive into the skills I'm looking for when building a product team and good opportunities to evaluate them during the minimal interview process - again in the context of Organization and Communication:
Organization:
- Research and contextualization: this is a natural fit for a homework question - these days evaluating data-sources is a great opportunity to test this
- Understanding dependencies and identifying blockers: The whole interview process is an opportunity to evaluate this - but I think one potential change that I've yet to see is to send either bad credentials or a broken link to a candidate as part of the homework. When the candidate communicates their timeline, seeing how they either take the potential for blockers into account or manage the process after the blocker is discovered is very similar to a common, high-stress task for PMs
- Evaluating choices and making decisions: This is good to evaluate in both the technical interview and in the homework - again evaluating data-sources is a good way to open this conversation
- De-risking processes by identifying weaknesses and strengths of team members and tools: A product manager needs to make decisions, but also identify the right resources to inform us when we're too ignorant to make a good decision
Communication:
- Clarity: part of the homework should ask for or allow for longer-form writing (paragraphs, not necessarily pages-worth), be sure to take notes about clarity during the interviews
- Timeliness: this doesn't necessarily mean things are fast - just that the product manager is communicating how long things will take and communicating their timing needs and respecting both your and their time. The logistics of the homework is a great way to evaluate this especially
- Tech/non-tech translations: It's useful to have non-technical people in the room for evaluating the technical parts of the homework and vice versa - make sure that people feel free to question choices outside of their expertise
- Focusing on important details without losing the thread: This will come up over longer conversations, so it's very important to include a single longer conversation with a consistent interviewer - the review of the homework is a good way to evaluate this
Also, I totally understand that there's no perfect product manager, just great fits for a particular role in a particular team. Specifically, huge tech-companies, engineer-heavy startups, and technical organizations inside non-tech companies may place very different weights on these various skills - and of course each organization will expect different industry and technical knowledge.