Product interviews are mostly about how you decide. Almost every question is a disguised way of asking what you cut and why.
What this role is actually evaluated on
- Whether you can say no and survive it. The job is mostly declining things.
- Whether you decide with incomplete information. Describing a process instead of a decision is the most common failure mode.
- Whether you own outcomes rather than output. “We shipped it” is not a result.
- Whether you can be specific about a trade-off. Naming what you gave up is the whole signal.
Questions you should be able to answer out loud
Not a bank to memorise. These are the shapes the real questions take, and if you can answer these you can answer most of what comes.
- Tell me about something you decided not to build. Who was unhappy and what did you tell them?
- Tell me about a feature you shipped that did not work. When did you know, and what did you do?
- How did you prioritise when engineering capacity halved?
- Tell me about a time you disagreed with a senior stakeholder about direction.
- Walk me through a decision you made without enough data. What would have changed your mind?
- What is something you shipped deliberately unfinished, and why was that right?
The mistakes that cost candidates this job
- Describing a framework instead of a decision. RICE is not an answer. What you cut is.
- Taking credit for the team’s work. And its mirror image — saying “we” so consistently that your own contribution disappears.
- A failure story with no real failure in it. “We shipped two weeks late” is not the one they are hoping for.
- Metrics with no baseline. “Engagement went up 40%” means nothing without what it was before.
Preparing for it
Have one story ready where you were clearly wrong and it cost something. Candidates avoid these and they are the answers that build the most trust — provided the story ends with what you changed afterwards.