How to Actually Interview Product Managers

Most PM interview processes test one thing: how well the candidate interviews.

Not how well they'll do the job. Not how well they think about product problems. Not how well they work with engineers, designers, or stakeholders. Just how well they perform in a conference room for four hours.

That's a casting call, not an interview.

I've been on both sides of PM interviews — as a candidate, as a hiring manager, and as a consultant helping teams redesign their processes. The pattern is always the same: teams that interview badly hire badly. And teams that hire badly spend the next year wondering why their new PM "just doesn't get it."

The PM "gets it" fine. Your interview didn't test for "it."

What PM Interviews Actually Test

Let's be honest about what standard PM interviews select for:

• Verbal fluency. Can they talk confidently for 45 minutes? Great. But product management is mostly listening, writing, and facilitating — not presenting.
• Pattern matching. Does their answer sound like what a "good PM" says? That means they've either done the job before or they've read Cracking the PM Interview. Both are fine, but neither predicts performance in your organization.
• Cultural similarity. Do they "feel" like a fit? As I've written before, "culture fit" is usually similarity bias wearing a corporate label.

None of these are terrible signals. But they're not sufficient. And when they're the only signals, you're hiring performers — people who are good at the interview, not necessarily good at the job.

The Gap Between Interview and Role

The core problem is misalignment between what the interview tests and what the role requires.

Product management requires different things at different companies. At a startup, you need someone who can do research, write specs, manage projects, and talk to customers — often in the same day. At an enterprise company, you need someone who can navigate politics, manage stakeholders, and align teams with competing priorities.

But the interview process is almost always the same: behavioral questions, a product design exercise, maybe a case study. The same loop for every company, every role, every context.

This is like using one test for every sport. A sprinter and a chess player both need to "perform under pressure," but the test should look radically different.

How to Interview PMs Better

Here's what works — and more importantly, why it works.

1. Define the role before the interview

Sounds obvious. Almost nobody does it well.

"We need a PM who can drive strategy and execution." That's not a role definition — that's a wish list. Every PM is supposed to do strategy and execution. The question is: what specific decisions will this PM make in their first 90 days? What specific problems are they solving? What specific team are they working with?

Write down the five most important things this PM will do in their first six months. Not platitudes — actual work. "Lead the migration from monolith to microservices pricing model" is a role. "Drive product strategy" is a bumper sticker.

Then design every interview question to test for those five things. Nothing else.

2. Use real problems, not hypotheticals

"How would you build a product for blind people?" is a real interview question I've heard. It tests compassion, maybe. It tests nothing about how the candidate would perform in the actual role.

Instead: give the candidate a real problem your team faced. Sanitize it if needed, but keep the constraints real. "Here's a situation we dealt with last quarter. Here's the data we had. Here's the team structure. Walk me through how you'd approach it."

This tests actual problem-solving, not performance art. And it gives you a direct comparison: how does their approach compare to what your team actually did? That's a useful signal. "How would you design a parking lot?" is not.

3. Score before you discuss

After each interview, every interviewer should submit their scores independently before the debrief. This is the single most impactful change you can make.

Why? Because debriefs are anchoring machines. The first person to speak sets the frame. If the hiring manager says "I liked them," every subsequent opinion shifts toward agreement. If the most senior person says "I'm not sure," everyone finds reasons to be unsure.

Cognitive bias doesn't disappear because you're aware of it. Independent scoring before discussion is a structural fix — it works regardless of whether individuals are aware of their biases.

4. Test for learning, not knowing

The best PMs aren't the ones who walk in with the right answer. They're the ones who figure out the right questions to ask.

Design at least one interview round that gives the candidate new information mid-conversation. Present a problem. Let them start solving it. Then introduce a constraint they didn't know about — a technical limitation, a stakeholder requirement, a budget cut.

Watch what happens. Do they integrate the new information or defend their original answer? Do they ask clarifying questions or push forward with assumptions? Do they adjust or anchor?

How someone adapts to new information is a better predictor of PM performance than how well they answer static questions. Product management is constant adaptation. Your interview should test for it.

The Take-Home Exercise Question

Take-home exercises are controversial. Some candidates hate them. Some companies overdo them. But done right, they're the highest-signal part of the process.

The key: keep it short, keep it real, and respect the candidate's time.

• Short: Two hours maximum. Anything longer and you're selecting for candidates with free time, not candidates with talent.
• Real: Based on an actual problem, with actual data or context. Not a clean textbook problem — a messy, ambiguous one.
• Respectful: Pay candidates for their time, or use a problem your team has already solved (so you're not getting free consulting).

The exercise reveals things the interview can't: how they structure their thinking when they have time to think, how they communicate in writing, how they prioritize when nobody's watching. These are all things PMs do daily. A 2-hour exercise tests them better than a 45-minute conversation ever will.

Interviewing as Product Work

Here's the meta-lesson: your interview process is a product.

It has users (candidates), stakeholders (hiring managers), and outcomes (quality of hire). It should be researched, tested, measured, and iterated on — just like any other product.

How many companies track the correlation between interview scores and actual performance at 6 or 12 months? Almost none. How many companies A/B test different interview formats? Almost none. How many companies ask rejected candidates for feedback on the process? Almost none.

You wouldn't ship a product without user research, metrics, or iteration. But you ship a hiring process this way every day. And then you wonder why your PMs aren't working out.

Start Here

Pull up your current PM interview guide. For each question, answer two things:

1. What specific, observable behavior does this question test for?
2. Does this behavior directly map to something the PM will do in their first 90 days?

If either answer is vague — "tests product thinking" or "maps to general PM skills" — the question isn't earning its place. Replace it with something that tests for what you actually need.

Better interviews don't start with better questions. They start with a clear definition of what you're hiring for — and the discipline to test for only that.

Need to redesign your PM hiring process?

I help product teams build interview processes that actually predict performance — with rubrics, real problems, and structured evaluation. The goal isn't more interviews. It's better signal from fewer rounds.

Book a Clarity Call — 30 minutes, no pitch. Just clarity on whether your interview process is finding the PMs you actually need.

Not ready for a call? Subscribe to The Adam Thomas for frameworks and honest takes on product leadership, delivered biweekly.