Hah. Clickbait. A lot of hiring in tech is broken. Product management interviews especially so.
Here’s how it goes.
what happens now
The resume looks promising. They’ve been a product manager before, the words are spelled correctly, and - lo, what’s this? - formatting and a hint of design? Sold.
First the phone interview. Ring, hello, here’s my background. Tell me a little about yourself. Tell me a little about a project you’ve worked on. Oh that’s interesting - tell me how you went about delivering that? Now how you balance that against tech debt? Beautiful. Let’s set something up with the team.
Next, the interview with the engineering manager. Oh hello. What’s your process for releasing a feature? Agile?! You don’t say. Now tell me how you balance feature work against tech debt.
Third, perchance with a design lead. What’s your favorite app? My goodness, it’s something I’ve never heard of - you must be sharp. By the way, do you have any thoughts on balancing tech debt vs say I don’t know a new feature? Nice.
Fourth, with a product lead. Pitch me a feature for our product. Wunderbar. Why should we build it? Now what if our biggest customer told you to do this with sinister overtones? Great. Now, the thing is we have some debt, you see, debt of a technical nature..
Now there’s nothing wrong with the nature of the above. Absolutely nothing. All the questions above are indicative of what a product manager does on a daily basis. It covers the following, in order:
- Have you done something meaningful in your current/prior role, and can you communicate that verbally? Do you have a framework for prioritizing work?
- Do you have a process for delivering features? (agile?!)
- Can you tell me what makes a product good or bad or mediocre?
- Have you thought about our industry and our product? Do you have a framework for thinking about what to build?
Here’s what scares me about it.
One, I’ve been at several interviews now where each interview has asked me the same thing - the tech debt vs. feature work trope is exaggerated, but not a far cry from what’s happened to me. What it says to me is that the company doesn’t know what its looking for in a product manager. When all the members of your team are asking the same thing it means no one has sat down and said this is what a product manager does and this is how we’re going to evaluate them. It says to me - as an interviewee - that this role doesn’t matter at this company.
Two, it tests the art of BS more than it tests whether someone is a good prioritizer or communicator. There’s been a lot of hullabaloo about how to interview engineers (rightfully so), but the programming tests / whiteboard sessions do one thing well. They test that you know the basics of the job you’re interviewing for. The bare (bare) basics of do you know how to write some code and can you do it well. (I don’t mean the interviews where you balance a red-black tree with your right hand while simultaneously reversing a linked list with your left. I mean something a few steps above FizzBuzz).
So what is one to do? How can we improve this process? Here are a few suggestions.
Get together as a team to figure out what a product manager does at your company and/or team. There’s no one-size-fits-all PM definition. Do you want them to be the CEO of the product? Is it important that they know how to wrangle a backlog in JIRA? Is the value they bring from talking to customers or do you need them to be more data driven? Put together a list of skills that you as a team/company need.
Now that you have the requirements for the job spelt out, split them up among the interviewers. Make sure you align on the questions so there is no infernal repetition of the same damn tech debt vs feature work god damnit it no calm down. Make sure there are no duplicates, is what I mean.
test the basics
Test the basics! There are some things that all product folk need to do, and do well. Communicate. And. Prioritize.
90% of the way a PM communicates is through writing (slack, email, specs, pleading through JIRA comments). Get them to write something. Anything. A JIRA ticket. A mini-spec. A paragraph on where your industry is headed. An email to a customer. It depends on what you’ve determined the skills are for the job.
Prioritization. This is - I think - half the job. Maybe more than that. No matter the level you’re hiring someone for, you should test how they prioritize a set of features. Put together a pre-filled trello board in front of them, have them sort it an explain why. Ask them their favorite product and how to improve it. Then make them rank their suggestions. It doesn’t matter what it is, but you have to know that they can explain why they’re doing X but not Y. Otherwise - you may end up with a PM leads by fiat because they cannot explain the narrative.
By all means do the rest if you determine that it tests what you need. The estimation questions, the case study, marketing, product metrics. Whatever else, they’re not bad questions. Gayle Laakman has a terrific and popular book on interviewing as a product manager that you can use as a guide.
Technical questions. If you’re at a technical company, then ask them something technical. One of the best places I interviewed at asked a system design interview question. That may seem excessive for a PM, but guess what - you needed to be in order to work there. They asked the question because it fit the role. I do think product folk at tech companies need to be a little technical. If they don’t have an engineering background, I like to ask them to explain how the feature they’ve worked on before works from a backend perspective. Because if you’re eventually going to ask them to prioritize tech debt vs new features, they should know why tech debt sucks.
And that’s it. If you have any questions, comments, or feelings on how to prioritize tech debt, feel free to email me @ this sites url.