PM interviews are inconsistent. Ask ten hiring managers how they interview PMs and you'll get ten different answers — and most of them are wrong. Too many PM interviews test for fluency in product vocabulary rather than evidence of actual product thinking.
This guide gives you 30 questions across five categories, with notes on what a strong answer actually looks like. Use it to structure a 90-minute technical interview, or as a reference to build your own question bank.
How to use this guide
Pick 5–8 questions per interview — don't try to cover all 30. Go deep rather than wide. A candidate who gives three exceptional answers tells you more than one who gives 30 average ones.
For each question, the Look for: note describes what distinguishes a strong answer from a surface-level one. If you're not getting that depth, probe: "Can you give me a specific example?" and "What was the outcome?"
1. Product sense and discovery
These questions test whether a candidate can identify real problems, prioritise them correctly, and turn ambiguous inputs into clear direction.
1. Walk me through a product decision you made that you're proud of. What was the problem, how did you decide, and what happened? Look for: A specific example with clear problem framing, explicit trade-offs considered, a real decision made (not just a consensus achieved), and an outcome they can quantify or describe concretely. Strong candidates can say what they'd do differently. Weak candidates describe a process without a decision.
2. Tell me about a time you killed a feature or said no to a stakeholder request. How did you handle it? Look for: Evidence that the candidate can hold a position with data and reasoning, not just yield to whoever shouts loudest. Strong candidates name who they said no to, what their reasoning was, and how they communicated it. Watch for candidates who never say no — that's a red flag.
3. You've just joined a team with an existing product. How do you figure out what to work on first? Look for: A structured discovery approach: talk to users, review metrics, map current pain points, understand the business context. Strong candidates sequence their activities (don't start building in week one), separate what they observe from what they're told, and resist the urge to immediately fix things that look broken.
4. How do you decide what NOT to build? Look for: An explicit prioritisation framework (ICE, RICE, opportunity scoring, or their own) applied with judgment. Strong candidates can describe the cost of building the wrong thing — engineering time, opportunity cost, product complexity — not just the benefit of building the right one.
5. Describe a product you use every day and one thing you'd change about it. Look for: Genuine product curiosity, not a rehearsed answer. The change should be grounded in an assumed user problem, not personal preference. Strong candidates can articulate who the change would help and what metric it would move. "I'd make the font bigger" is not a product answer.
6. How do you validate a product idea before committing engineering resources to it? Look for: A range of validation methods: user interviews, fake door tests, prototypes, competitive research. Strong candidates calibrate the depth of validation to the cost of being wrong — they don't run a 3-month research sprint for a two-day feature. They also distinguish between desirability (do users want it?), feasibility (can we build it?), and viability (should we build it?).
2. Execution and delivery
These questions test the day-to-day reality of working with engineering and design, writing specs, and shipping things.
7. Walk me through how you write a product specification. What does a good one look like? Look for: A clear structure: problem statement, user context, acceptance criteria, out-of-scope decisions, and open questions. Strong candidates emphasise that a spec is a communication tool, not a contract — its job is to give engineers enough clarity to make good decisions without asking permission for every micro-choice. Bonus: they can describe a spec they wrote that saved an engineering team from building the wrong thing.
8. How do you handle a situation where engineering says something will take three times longer than you expected? Look for: A collaborative approach, not defensiveness or capitulation. Strong candidates ask what the complexity is (they might find a simpler path), scope down to the core of the requirement, and communicate the change in timeline to stakeholders without blaming engineering. They don't say "I just trusted the engineers."
9. A feature ships but users aren't adopting it the way you expected. What do you do? Look for: Structured diagnosis: is it discovery (users don't know it exists?), usability (users find it confusing?), or value (users tried it and didn't find it useful?). Strong candidates run experiments to separate these before jumping to solutions. They don't immediately add a tooltip and call it done.
10. Tell me about the last time something you shipped failed. What happened and what did you do? Look for: Honesty and ownership, not blame-shifting. Strong candidates can describe a specific failure, name what they got wrong (in problem framing, user understanding, or execution), and explain what changed as a result. "We just didn't have enough data" is not a reflection — it's an excuse.
11. How do you manage a backlog when everything feels equally important? Look for: A practical approach to prioritisation under real-world constraints, including political ones. Strong candidates acknowledge that some things get prioritised for strategic reasons that aren't purely impact-driven — a key customer request, a competitive threat — and describe how they make those trade-offs transparent rather than pretending the process is purely analytical.
12. How do you work with designers? At what point in the process do you bring them in? Look for: Genuine respect for design as a thinking partner, not a deliverable factory. Strong candidates bring design in at the problem-definition stage, not the spec-complete stage. They can describe a time when a designer's perspective changed their understanding of the problem.
3. Strategy and metrics
These questions test whether a candidate can connect product decisions to business outcomes and think beyond the immediate feature.
13. What metrics would you use to measure the health of a product you're responsible for? Look for: A layered answer: a primary metric (the one number that tells you the product is working), supporting metrics that explain why it's moving, and guardrail metrics that tell you when you're trading off something important. Strong candidates avoid vanity metrics (page views, registered users) unless they can explain why those metrics specifically predict business value in this context.
14. You're three months from launch and your primary metric is flat. What do you do? Look for: A systematic diagnostic approach before jumping to solutions. Is the metric flat because of acquisition, activation, retention, or monetisation? Strong candidates run the funnel diagnosis, form a hypothesis about the biggest lever, and describe how they'd test it quickly. They don't immediately propose a big new feature.
15. How do you think about the relationship between user goals and business goals? When do they conflict? Look for: Nuanced thinking about alignment and tension. Strong candidates can give a specific example of a real conflict (e.g., a feature that drives engagement but reduces revenue, or pricing that maximises revenue but hurts activation) and explain how they resolved it. Candidates who say "user goals and business goals are always aligned" haven't worked on a real product.
16. How do you build a product roadmap, and how do you communicate it to stakeholders? Look for: A roadmap that's a prioritised set of bets, not a promise of delivery dates. Strong candidates describe a now/next/later structure, or themes, rather than a Gantt chart — because roadmaps that look like Gantt charts become commitment documents that punish discovery. They also describe how they communicate uncertainty without losing stakeholder confidence.
17. How would you evaluate whether your company should build, buy, or partner for a specific capability? Look for: A framework covering: strategic importance (is this core or commodity?), time-to-value (how fast do we need it?), build cost vs buy cost (including maintenance and switching costs), and competitive differentiation (does owning this give us an advantage?). Strong candidates can apply this to a specific scenario, not just describe the framework abstractly.
18. Tell me about a time you used competitive intelligence to inform a product decision. Look for: Specific examples of how the candidate monitors competitors — not just G2 review comparisons, but user research with churned customers, feature gap analysis, pricing experiments. Strong candidates can describe a decision they made or changed because of competitive context, and what they did to validate that the competitive move mattered to their users.
4. Data and experimentation
19. Walk me through a hypothesis you formed, tested, and either confirmed or disproved. Look for: A real experiment with a specific hypothesis (not "we thought users would like it"), a valid test design, a result, and a clear decision made from the result. Strong candidates can describe what they expected, what they found, and how those differed. Bonus: they can describe the confounding variables they had to control for.
20. How do you run A/B tests, and what are the most common mistakes teams make when running them? Look for: Statistical literacy: sample size calculation, significance thresholds, novelty effects, and the dangers of stopping experiments early when results look good. Strong candidates have real opinions about common mistakes — running tests too short, testing too many things simultaneously, not accounting for seasonal effects — drawn from real experience.
21. A stakeholder shows you data that contradicts your product direction. How do you respond? Look for: Intellectual honesty. Strong candidates take the data seriously, ask questions about how it was collected and what it actually measures, and update their view if the evidence is valid. They don't defend their position reflexively, but they also don't immediately capitulate to whoever holds the data. They ask: does this data measure what we think it measures?
22. How do you make product decisions in the absence of data? Look for: A practical answer, not an idealistic one. In the real world, many decisions are made with incomplete data. Strong candidates describe how they assess the cost of being wrong, how they use analogues (what do similar products or markets suggest?), and how they frame the decision as a reversible experiment where possible. They don't say "I always wait for data."
5. Stakeholder management and leadership
23. How do you manage a situation where engineering, design, and sales all want different things? Look for: Conflict resolution grounded in first principles (user need + business outcome), not politics. Strong candidates name how they facilitate alignment without just averaging everyone's preferences — which usually produces no one's preference. They describe a specific example, not a generic answer about "bringing everyone to the table."
24. How do you build credibility with an engineering team when you're new? Look for: Humility combined with specific actions: learning the system before changing it, writing specs that actually help rather than constrain, following through on commitments, and never throwing engineers under the bus in stakeholder conversations. Strong candidates can describe what they did in their first 30–60 days at a new company that built trust with engineering.
25. Describe a time you had to deliver bad news to a stakeholder — a feature delayed, a bet that didn't pay off, or a decision reversed. How did you handle it? Look for: Direct communication with context. Strong candidates communicate early (not the day before a deadline), explain the root cause clearly, and come with a proposal rather than just the problem. They don't hide bad news or use passive language to obscure accountability.
26. How do you handle a founder or CEO who wants to override your product prioritisation? Look for: A relationship-based, not confrontational, approach. Strong candidates describe how they make their prioritisation reasoning visible (so overrides are explicit, not implicit), how they document disagreements and outcomes, and how they pick their battles. They don't say "I just do what the CEO says" — that's not a PM, that's a project manager. But they also don't treat every founder override as a failure.
6. Role-specific and scenario questions
27. We're considering building [a specific feature from your product]. How would you evaluate whether to build it? Look for: Application of the build/prioritise framework to your specific context. Adapt this question to your actual roadmap. The value is in seeing how the candidate reasons about your real problem, not a hypothetical one.
28. What's the most common mistake junior PMs make? Look for: Genuine perspective drawn from experience, not a textbook answer. Strong candidates name a specific mistake with a specific example of what it looks like and why it happens. Common answers: shipping features without defined success metrics, optimising for stakeholder happiness instead of user outcomes, writing specs before understanding the problem.
29. How do you stay current on the product and technology landscape? Look for: Specific sources, not general answers ("I read product blogs"). Strong candidates name specific newsletters, communities, or products they pay attention to, and can describe something they learned recently that changed how they think about a product problem. Curiosity is a trait — you can hear it.
30. What does a great PM look like at this company, one year from now? Look for: Adaptability and self-awareness. Strong candidates use this question to clarify what success looks like before committing to a direction, and to check whether the role matches what they're looking for. A candidate who gives a fully formed answer without asking any clarifying questions may be telling you what they think you want to hear.
Interviewing tips for hiring teams
Run the same questions with every candidate. It's the only way to compare fairly. A candidate who gets an easy scenario and a hard candidate who gets a hard one cannot be compared on the output.
Score before discussing. After the interview, each interviewer should write their assessment independently before the debrief. Group debriefs tend to anchor on the first opinion expressed.
Reference checks are not optional for PM roles. A PM who is bad at their job can hide it for months behind process and vocabulary. Talk to their previous engineering and design partners — not just their manager.
Looking for a job description template to attract the right PM candidates? See the Product Manager Job Description Template.
Ready to screen PM applicants? Upload CVs to Rekvo and run an AI match against your job description — results in under 2 minutes.