A lot of companies have adopted FAANG-style interviews. Alternatively, they require applicants to explain their 0-1 process or how to run a SQL query.
All of those are acceptable if they review PM tasks at your workplace. If not, question and test about abilities and behavior that are actually used at work.
To be honest, STAR is probably the best undesirable choice.
Outside of genuinely discussing your prior experiences, PM interviews are some kinds of a joke.
You know what, last time I had to conduct a market analysis, identify target markets, design a product strategy, construct a story map, and provide a GTM plan in less than 15 minutes for a fictitious sector of the economy that I was unfamiliar with?
Thought experiments and hypotheses reveal more about a candidate’s ability to think quickly than their capacity to apply a memorized procedure under time pressure.
In one of my favorite interviews, I was given a hypothetical situation based on product usage data and asked to provide explanations for why it might be happening and possible solutions.
I’ll admit that years ago, when engagement decreased 10%, I utilised this for an analytical inquiry. The boxes for external influences, internal factors, product changes, etc., were things I wanted to check.
It used to be a well-known interview question type that provided some insight into the candidates’ thinking; however, these days it’s more of a test of whether they’ve watched the framework on YouTube and a less reliable indication of whether they will ask the right questions, put on their boots and dig through the data (or persuade someone else to), or carry out the actual task.
If you inquire about experience, at least, they will either have had to do it or they will be a very good liar (and a couple of thoughtful follow up questions exposes that a lot).
These interviews, in my opinion, are entirely focused on the follow-up inquiries. Knowing the framework and being able to start out well are sort of pre-requisites, but if the interviewer is skilled, you will eventually need to think on your feet.
The hiring tactics at some larger companies, which were copied by the minions of the gig economy, have turned the PM job category into a non-contact professional sport. An entire cottage industry has now emerged to assist candidates in preparing for these messed-up interviews, which have completely altered the recruiting procedures of the traditional companies.
The job description is a wordy mess. An environment that was perfectly balanced was completely destroyed by the glorification of the PM role. Some big company (don’t want to name them) messed up the dynamics of the industry, not raised the bar. A whole generation of recent college graduates who were training for the PM post were destroyed by another giant. In an attempt to outdo this giant, another big company managed to destroy both the hiring process and the pay scale.
In the past, a PM was also the PMM, who was knowledgeable in the sector. i.e., they spent a number of years in a non-marketing position, such as engineer, before switching to a product role. They therefore had a strong base, whether it was technical or a general awareness of the value chain of the industry in which their particular product fell. The standard 3C’s, 4P’s, STP, and Five Forces analyses were performed as part of the detailed market analysis that was a key component of the job description for GTM. Everything they did was governed by this structure and philosophy. In order to carry out a program, they wrote MRDs and PRDs and collaborated with Tech Leads and Program Managers as the three equal legs of a coffee table.
They would find the job descriptions of the present crop of PMs unrecognizable if you brought someone back from retirement who was the product manager for the original Sun OS, Mac OS, Windows OS, or Pentium CPU.
There are two elements that, in my opinion, seem to be the best predictors of performance, even though I redesigned our interview process about two years ago, even though some of it is still the traditional stuff about behavioral and STAR style.
Obviously, a lot depends on the level at which you’re recruiting them. If they are an IC, you really only want to concentrate on how well they can PM the task that is allocated. If they are a manager, you’ll want to assess how adept they are at creating and changing processes.
Going deep on their current product:
What problem is it solving and how does it do that?
Who are the buyers and who are the users?
Why is your product superior to the competition?
How do they know the product is providing value to their customers? How do customers know this?
What metrics do they track for this product?
What was the most impactful feature they delivered/launched in the last year for this product?
Each of these questions is not a standalone and will result in 1 or 2 follow up questions to dive deeper, but these can’t really be predicted as it will be very specific based on their answers. This truly gets to how well do they understand their product, market, customers, etc.
The other element I included was comparable to a sales engineer’s fake presentation or an engineer’s coding interview. They are required to create a mock epic or user story and participate in a mock stand-up with two engineers (which might be two developers or a developer and a development manager). We are normally quite accommodating with what they select and tell them that it can even be something from their current or prior employment as long as they aren’t giving us access to any sensitive information.
Just like with our PI planning approach, the developers receive it in advance. They have the option of role-playing to observe the PM’s reaction (they can explain to the PM why the future is absurd or invalid, they’ll try to overengineer and complicate the solution, they’ll adore the feature and add a ton of additional capabilities to it, resulting in a significant scope creep). They may be acting or they may actually be feeling these things after reading the epic or novel.
We can first judge their writing and asynchronous communication skills. There can’t be a meeting for every feature because we have developers all around the world.
Then, we get to observe how effectively they can handle disagreement and function as a team. You’d be astonished to learn that even during an interview, some of them will assert that since they are the prime minister, their decisions are definitive and they must be followed.
Depending on the questions that engineers ask, this might also give a sense of how deep their technical knowledge is. Can an engineer decide which of two proposed designs is best for a user if they are presented with the tradeoffs between them?
The majority of candidates have found this to be the most favourable aspect of our interview process. Our engineers are eager to join us because we provide them the chance to showcase their skills. They love how it feels like an actual test of their skills in the work we’ve been doing. Because they are excellent interviewers, some applicants have otherwise seemed like a fantastic fit, but when it comes down to it, we can tell that their actual PM skills are seriously inadequate. It also demonstrates a little bit our creativity and willingness to attempt new things in our processes in order to achieve superior results.
@MichaelYoffe, I admire how carefully you matched the technical/on-site interview to a real-life scenario.
It can be quite challenging for candidates, particularly women, to choose how assertive to be in a high-stakes interview. PMs are constantly reminded that while we must work together, we also have to make difficult decisions and stand up to the HiPPO in the room.
But it’s true that saying “Because I’m PM and I said so!” is never a wise move.
Although I am aware that this is probably unattainable, I am hoping that the degree of assertiveness would be comparable to how you would react in a situation like this in the real world. When an engineer makes a suggestion, it generally falls into one of two categories: either it’s good or bad (sure it might be one that needs more research as well). If the situation is awful, you will know it as the project manager because you have more information, context, or understanding than they do. You will likely be able to communicate these additional details in a way that will have them nodding and agreeing. If it’s an excellent idea but expands scope, it’s up to you as the project manager to accept it and postpone the feature.
Unfortunately, the culture of many (perhaps even the majority) businesses does not encourage women in tech as much or even calls for them to adhere to different standards, which is unfair. One of two things will happen if you behave with the aggressiveness you would in the actual situation:
If you do it well, you’ll get an offer, and they won’t object or find it lacking.
Even in circumstances when they would have tolerated it from a male candidate, they will be turned off by it, and you won’t receive an offer. Even though this is undoubtedly terrible, you will at least have avoided a catastrophe because, in my opinion, working for that company would have been even worse.
This works out OK if you have the freedom to pick and choose and look for the ideal opportunity, but it truly stinks if you’re more in need of a job to support your family.
@MichaelYoffe, for all the reasons you list, the way you present the second component is brilliant. I never would have thought to approach it that way.
Gratitude for this. I adore how straightforward the task is, giving the candidate flexibility while also giving everyone a taste of what it would be like to collaborate in real life. Very astute!
The risk I encountered by just inquiring too much about their current offering is that I may receive false positives as a result of having worked under a capable manager or leader in the past. In other words, they are repeating prepared talking points. Did you experience this?
@AnaRodriguez, Because of the follow-up inquiries, I still believe that this can be determined effectively. They might be familiar with the top-level solutions if they had someone else perform their work, but they would struggle with the drill down. If they can answer the drill-down questions, it probably suggests that they took the time to actually understand it themselves even though it was on their radar because of a former manager or leader, and hopefully it means they learned more other things from that amazing leader.
Keep in touch with those who will be collaborating with the applicant. The PM leader, the engineering manager, the designer, and possibly a few other stakeholders. Allow them to ask whatever they want. FAANG interviews are crazy since you frequently meet a lot of individuals there that you might or might not ever see again.
No insane FAANG-style queries. Simply inquire about prior experience and how it relates to the position. Describe the product in detail and the problems you would solve with it. If someone can offer value to the team and the culture, it is something you want to know.
Be honest, fair, and kind to everyone. Allow them to ask questions and learn a lot about your business and goods throughout this extended period of time.
Move swiftly. Make the procedure painless and shirt. Don’t make qualified applicants wait. Give them a firm “no” or make them an offer.