Interview Prep

Why this category is organised by skill, not by job title

Two people preparing for the same job title get asked different questions, and two people with different titles get asked the same ones. A product manager interviewing at a ten-person company and a senior product manager at a ten-thousand-person one both face discovery, prioritisation and metrics — at different depth, with different stakes, in a different order. Organising a question bank by title would mean writing the same discovery question four times over and then keeping four copies of it correct.

So the banks here are domains. A domain is a body of knowledge an interviewer can probe for forty minutes without running out of ground: product discovery, prioritisation, experimentation, pricing. Seniority is not a separate page — it is the difficulty band on the question. The same domain carries recall questions for someone entering the field and judgement questions for someone who will be asked to defend a decision that cost real money.

That has one practical consequence worth knowing before you start. The fastest way to find your gaps is to take a domain you are confident you already own. Confidence is where the unexamined beliefs live, and an interview is precisely the situation that finds them.

What is here now, and what is coming

This category is being built one domain at a time rather than released half-finished across every discipline at once.

Product management is first, because it is the ground where the writing is strongest and the reasoning easiest to defend. Product discovery and user research is live now. The remaining seven product domains follow it: prioritisation and roadmapping; metrics and analytics; experimentation and A/B testing; technical fundamentals; stakeholder and executive communication; pricing, packaging and monetisation; and product strategy and positioning.

After product come data and analytics, then engineering, then design, business and operations — twenty-seven domains in all, sequenced so that the ones we can defend hardest ship earliest.

Each domain arrives as a complete bank of forty questions split into four tests of ten, never as a placeholder. Nothing appears on this page before its questions exist, because a page that advertises a bank it does not have is worse than an absent page.

How to use multiple choice for an interview you will answer out loud

Multiple choice cannot rehearse the part of an interview that matters most — the part where you reason aloud, get interrupted halfway, and revise your answer in front of someone who is judging how you revise it. It is very good at something else: finding, in about twenty minutes, which parts of your mental model are held together by habit rather than by understanding.

So use it diagnostically. Take a set and pay as much attention to the questions you got right slowly as to the ones you got wrong; both are telling you where to read next.

Then use the wrong answers. In a well-built question every distractor is a position that a real practitioner holds and would defend. When you pick one, the useful question is not "what was the right answer" but "why did the wrong one look right to me" — because that is the belief that will surface under pressure in the room, and it will surface as a confident sentence rather than as a doubt.

What a question here has to earn

Every question is written against a source we can point at, and its explanation names that source rather than gesturing at it. Where a fact can move — a framework's current definition, a practice that has shifted in the last two years — the question carries a review date and the source is read again on a schedule instead of being assumed still true.

The harder requirement is the one no script can check: a question earns its place only if answering it would help you solve a real problem the following day. Trivia that happens to be well documented does not qualify, and neither does a definition with no consequence attached to getting it wrong.