Product Manager Interview Prep: Questions and a Mock Test

The design round, usually phrased as "design a product for X" or "how would you improve Y", is where most candidates lose the interview in the first two minutes by proposing features.

The structure interviewers are trained to listen for runs: clarify the goal, choose a user segment and say why, identify that segment's specific pain points, prioritise among them with a stated reason, then propose solutions to the top one, and only then say how you would measure whether it worked. Solutions arriving before a user and a problem is the single most common failure, and it is visible immediately.

Segmentation is where good answers separate. "All users" is not a segment, and choosing one narrow enough to have a distinct problem, then saying explicitly why you chose it over the alternatives, demonstrates the judgement being assessed. It is entirely acceptable to say that you are picking the smaller segment because the problem is more acute there and the learning transfers.

Breadth then depth is the pacing that works. Generate several distinct solution directions, not variations of one, then commit to one and go deep on how it works and what could go wrong. Candidates who generate ten shallow ideas read as unable to decide; candidates who commit instantly read as unable to consider alternatives.

Finally, say what would make you wrong. Naming the assumption your idea depends on is the difference between a proposal and a plan.

Marty Cagan's 2014 article Good Product Team, Bad Product Team is quoted often enough in product interviews that its framing is effectively part of the vocabulary, and the contrasts are sharp enough to be worth knowing.

On what teams celebrate: "Good teams celebrate when they achieve a significant impact to the business (outcome). Bad teams celebrate when they finally release something (output)." That distinction underlies a lot of interview scoring. A candidate whose accomplishment stories are lists of shipped features is describing output; a candidate who says what changed for users and for the business is describing outcome.

On planning: "Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps." This is not an argument against roadmaps so much as against treating a prioritised list as evidence.

On the working relationship: "Good teams have product, design and engineering sit side-by-side, and embrace the give and take between the functionality, the user experience and the enabling technology", and they "engage directly with end-users and customers every week".

The practical interview consequence is that discovery questions want you to name the riskiest assumption and the cheapest way to test it. A five-user interview round, a fake door test, a concierge version done by hand, or a prototype are all legitimate, and choosing among them by what risk they retire is the answer that scores.

Prioritisation questions are rarely about the framework. Any of the common ones will do, and reciting one without applying it is a weak answer. What interviewers push on is the input you cannot know precisely.

The strongest structure is to make the comparison explicit: what is the expected impact, on which metric, for how many users, and what is the confidence in that estimate. Scoring frameworks that include a confidence term are useful precisely because they force you to admit that one of your numbers is a guess. Effort belongs in the comparison too, and getting it from engineering rather than inventing it is part of the job.

Expect a scenario where the answer is not to build anything. A request from the largest customer that would serve only that customer, a feature that would raise a metric while damaging trust, an item whose real cost is the maintenance nobody priced. Being willing to say no, and to say it with a reason the requester can understand, is explicitly assessed in most loops.

Technical debt and platform work are a common probe. The weak answer allocates a fixed percentage of capacity because it sounds balanced. The stronger answer treats debt as a set of specific items with specific costs, some of which are worth paying down now because they are slowing delivery measurably, and some of which are fine to leave.

And expect the deadline question. When scope, time and quality cannot all hold, saying which one you would move and who owns that decision is the point.

The analytical round asks you to define success or to explain a movement, and the traps are consistent.

Defining success starts with the decision the metric informs. A metric nobody would act on differently at different values is a report. From there, name a primary metric, guardrails that catch the harm the primary is blind to, and a counter-metric where the obvious way to move the primary is undesirable. Engagement metrics are the classic case: notification opens rise when you send more notifications, so the guardrail is opt-out and uninstall rate.

Be precise about the shape of the metric. A ratio can move because its numerator moved, because its denominator moved, or because the mix underneath shifted while every segment stayed flat. That last case reverses conclusions and is worth naming explicitly.

On experiments, the expectation is that you know what a result does and does not license. A p-value is computed assuming the null is true, so it is not the probability the feature works. Checking daily and stopping at significance inflates false positives. Testing twenty metrics at a five percent threshold produces one significant result by chance. And a non-significant result is not evidence of no effect, particularly at small sample sizes.

The practical answer interviewers like: report the confidence interval and the decision's cost structure, not the verdict. Whether to ship a change whose interval spans a small harm and a meaningful gain depends on how reversible the change is.

The behavioural round is not a formality. In many companies it carries as much weight as the product rounds, and Amazon is the clearest published example of a company that has written down what it assesses.

Amazon publishes sixteen Leadership Principles, and several map directly onto product judgement. Customer Obsession states that "leaders start with the customer and work backwards. They work vigorously to earn and keep customer trust." Dive Deep says leaders "stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ", which is a direct instruction to interrogate a number that disagrees with what users say. Are Right, A Lot asks that leaders "seek diverse perspectives and work to disconfirm their beliefs". And Bias for Action puts the reversibility argument plainly: "Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking."

Whichever company you are interviewing with, the story structure that works is the same: situation, what you specifically did, and a quantified result. The most common defect is the first person plural. "We decided" tells an interviewer nothing about you; "I argued for X against Y because Z" does.

Prepare stories about disagreement and about failure, because both are asked in almost every loop, and the failure story should contain a real failure with a cost, not a disguised strength.