interview prep checklist

Most people start interview prep by searching “PM interview questions” and reading Cracking the PM Interview cover to cover. That is the wrong starting point.

The right starting point is your own experience. What have you shipped? What broke? What did you learn? PM interviews are a structured retrieval exercise — you are pulling specific evidence from your career to answer specific types of questions. If you don’t have the evidence organized before you walk in, you will fumble even for questions you know the answer to.

This checklist is organized by timeline. Four weeks of focused work is enough for most people. Six weeks is comfortable. Two weeks is possible but you will feel it in the room.

Before you touch a single framework

Do this first, before anything else on this list.

Audit your experience inventory. For every project or role you have held, write down:

• What was the goal?
• What was your specific contribution?
• What was the result, with a number?
• What did you learn that you would do differently?

This becomes your evidence database. Every behavioral question you will face — “Tell me about a time you failed,” “How did you handle conflict with engineering,” “Describe a data-informed decision” — gets answered by pulling from this database and adapting the story. If the database is thin, you need more stories. If the database is rich but disorganized, you will tell the wrong story at the wrong moment.

Know what type of PM role you are interviewing for. A consumer PM role at a fintech app tests differently than a platform PM role at a B2B SaaS company. The company’s product, user base, and stage shape the interview heavily. A senior PM at Swiggy will be asked different case questions than a PM at Freshworks. Before any prep, figure out which quadrant you are targeting: consumer vs. enterprise, early-stage vs. mature product, user-facing vs. platform/infrastructure.

Week 1: Foundation

[ ] Build your experience inventory

Go through every job on your resume. For each significant project or initiative, write a 4-line entry:

Project: [name]
Goal: [what success looked like]
What I did: [your specific contribution — not the team's]
Result: [number + timeframe]
Lesson: [what you learned]

You should end up with 15–25 entries across your career. These are your raw materials.

[ ] Tag each entry by interview category

Every entry should be tagged with what it demonstrates. Tag categories:

• prioritization — you had to make a hard call about what to build or cut
• stakeholder — you had to navigate conflict, alignment, or a difficult relationship
• data — you used analysis to make or defend a decision
• failure — something did not go as planned and you course-corrected
• user — you directly engaged with users to understand a problem
• strategy — you thought about the market, competitors, or long-term positioning
• execution — you drove a feature or product from idea to launch
• leadership — you influenced without authority or grew someone on the team

Most stories will earn 2–3 tags. A story that earns only one tag is probably too narrow. Develop it further or find a better one.

[ ] Identify gaps in your inventory

After tagging, look at which categories have fewer than 3 stories. Those are your gaps. If you have no strong failure stories, that is a problem — every interview will have at least one behavioral question in this category. If you have no strategy stories, you will struggle in senior PM loops.

Gaps you can fill: think harder about your experience. A “failure” story does not have to be catastrophic — it can be a feature that launched and underperformed, a forecast that missed, a user insight you got wrong. Mine your memory more carefully.

Gaps you cannot fill: be honest about them. If you have not made a data-informed decision in your career, do not fabricate one. Instead, prepare to be transparent: “I haven’t had to do this at the level of complexity you’re describing. Here’s what I’ve done and how I’d approach the next level.”

[ ] Write your “Why PM?” narrative

Every loop starts with “Walk me through your background” or “Why PM?” You need a 90-second answer that covers: where you came from, what drew you to product, what you’ve shipped, and why you want this role specifically. Write it out. Read it aloud. Time it. Cut it if it runs past 2 minutes.

Week 2: Product Sense

Product sense is the one skill you cannot memorize your way into — but you can train it systematically.

[ ] Do one product teardown per day

Pick any app you use. Spend 20 minutes on this structured analysis:

1. Who is the core user? What is their primary job to be done?
2. What is the product’s main metric? What behavior are they optimizing for?
3. What is one thing working well? Why, specifically?
4. What is one thing broken or underserved? Who does it affect, and how often?
5. If you were PM, what would you fix first — and why that over everything else?

The discipline is in the “why.” Anyone can say “the onboarding is confusing.” Only a PM can say “the onboarding asks for 6 fields before showing value, which means users who came from a paid ad with a specific promise never see that promise fulfilled — I’d cut to 2 fields and defer everything else to the activation moment.”

[ ] Study the company’s product before every interview

This is non-negotiable. Download the app. Use it as a user. Look at their App Store reviews (sort by most recent, read the 3-star reviews — they are the most honest). Check their competitors. Know their business model and where they likely make money.

In the interview, when they ask “How would you improve our checkout flow?”, you should already have spent time in that flow. Candidates who say “I haven’t had a chance to use the product” are communicating that they are not curious enough. You do not want to communicate that.

[ ] Practice the product design question format

Product design questions (“Design a feature for X,” “How would you improve Y?”) follow a predictable structure:

1. Clarify the goal and constraints
2. Name the users you are designing for (pick one, be specific)
3. State their top pain points
4. Generate 3–4 solutions
5. Pick one and explain why
6. Define success metrics

Practice this on 10 different questions. The goal is not to memorize the structure — it is to make it so automatic that you can run it under pressure without thinking about the format and just thinking about the problem.

[ ] Prepare your “opinionated product take”

Most interviewers will ask what products you admire and why, or what you think is broken in an industry. Have 3 specific answers ready. Not “I love Notion because it’s flexible” — that is a user opinion, not a PM opinion. A PM opinion sounds like: “Notion’s biggest mistake was not solving mobile-first workflows before Craft and Obsidian entered the market. They own the desktop power user, but they’ve ceded the daily habits use case to apps that load faster and don’t require a laptop.”

Week 3: Analytical and Execution Depth

[ ] Prepare for metric diagnosis questions

“Our DAU dropped 20% last week. How do you investigate?” is a standard analytical question. Prepare a mental framework you can run in real time:

1. Is this a measurement error or real? (Tracking issue, platform glitch, holiday)
2. Segment by: platform, geography, user cohort, feature area
3. Look for correlated events: release, marketing campaign, competitor action, external event
4. Identify the most likely driver and state the next step you would take

Practice this on 5–6 different “metric drop” scenarios. The specific numbers do not matter — the diagnostic process is what they are testing.

[ ] Prepare your prioritization framework

You will be asked to prioritize a backlog, a roadmap, or competing requests. Have a framework you can articulate under pressure. The specific framework matters less than being able to explain your reasoning clearly. “I assess impact against effort, but I weight for strategic fit first — a high-impact, low-effort feature that doesn’t move our north star metric gets deprioritized over a medium-effort feature that directly serves the ICP” is a coherent point of view. “I use RICE” without being able to explain why RICE or when it breaks down is not.

[ ] Prepare 2–3 execution stories

Execution questions test: how you write specs, how you run a sprint, how you communicate with engineering, how you handle slippage. Prepare stories for:

• A launch you drove from 0 to shipped — what did you own, what did you delegate, what broke?
• A sprint that went off-plan — what happened, how did you respond?
• A time you had to push back on a stakeholder or executive — what was the situation, what did you say, what was the outcome?

These should be specific. “We launched the feature in 6 weeks” is not a story. “We were on track for a 6-week launch but discovered in week 4 that our payment partner’s API didn’t support the flow we’d designed. I had two choices: rebuild the flow or negotiate a 3-week slip. I built a decision document overnight, presented two options with tradeoffs to the VP the next morning, and we agreed on a scoped rollout that hit the original date for 80% of users” — that is a story.

[ ] Know your numbers

For every product you’ve worked on, know:

• The core metric (DAU, GMV, conversion rate, NRR — whatever the business lives by)
• Your baseline number when you joined
• Your number when you shipped your main feature
• The delta and your contribution to it

Interviewers ask “what metrics did you move?” If your answer is vague, you signal that you are not metric-driven. Vague metrics answers are one of the most common reasons PM candidates get rejected at the final round.

Week 4: Interview-Specific Prep

[ ] Do 3–5 full mock interviews

Not question-and-answer practice. Full 45–60 minute mocks with someone asking you real questions and you answering in real time. The thing you learn in a mock that you cannot learn any other way is how you perform under the actual conditions. Most people discover that their thinking is fine but their communication collapses — they use the right frameworks but take too long to get to the point, or they jump to solutions before framing the problem.

Find a peer who is also preparing. Trade mocks. If you are in a PM course, use the mock interview feature. If neither is available, record yourself answering questions on video and watch it back. Watching yourself is uncomfortable. Do it anyway.

[ ] Prepare your questions for the interviewer

At the end of every round, you will be asked “Do you have any questions?” Never say no. Prepare 3–4 questions per round. Good questions:

• “What does the first 90 days look like for someone in this role?” (Tests how well the company actually onboards PMs)
• “What does the PM team think about [a specific product decision you noticed]?” (Shows you did your homework)
• “How does the PM team interact with engineering when there is a fundamental disagreement on scope?” (Tests culture, not just process)
• “What is the primary metric this team is accountable to in the next year?” (Tests whether the role has a clear north star)

Avoid questions whose answers are on the company website. Avoid questions about compensation in early rounds. Avoid questions that signal anxiety (“How often do PMs get fired here?”).

[ ] Prepare your close

Before every interview ends, you should close. Not a sales close — a signal that you are genuinely interested and that you understand what you just heard. “Based on what you’ve described, this role is squarely in the area where I’ve done my best work — driving early adoption of a platform product with a clear north star but an ambiguous path. I’m excited about it. What are the next steps?” is a stronger way to exit than “Thank you for your time.”

What to skip

Do not memorize 40 frameworks. You will forget them under pressure and reach for one that doesn’t fit. Know 5 frameworks deeply and be able to explain when each one applies and when it breaks down. That is more impressive than reciting HEART, AARRR, ICE, RICE, OKRs, and Jobs to Be Done in sequence.

Do not read every “PM interview prep” book end to end. Cracking the PM Interview and Decode and Conquer are useful reference texts — use them to find question types you haven’t practiced, not as prep syllabi.

Do not over-index on company-specific prep for first rounds. Recruiters and coordinators run first rounds. They are testing communication, clarity, and baseline competence. Company-specific product depth matters most in final loops with hiring managers and cross-functional partners.

Do not prepare generic stories. Every story you tell should be specific enough that it could only be yours. If someone from a different company could tell the same story with different nouns swapped in, the story is not specific enough.

The checklist at a glance

Foundations (do first, before anything else)

• Build experience inventory (15–25 entries with goal, contribution, result, lesson)
• Tag every entry by interview category
• Identify and address gaps
• Write and time your “Why PM?” narrative (90 seconds)

Product sense (Week 2)

• One product teardown per day for 7 days
• Deep-use the company’s product before each interview
• Practice product design question format on 10 questions
• Prepare 3 opinionated product takes with specific reasoning

Analytical and execution (Week 3)

• Prepare and practice metric diagnosis on 5–6 scenarios
• Articulate your prioritization framework and when it breaks down
• Write out 3 execution stories with specific detail and numbers
• Know your numbers: baseline metric, your feature’s impact, the delta

Interview-specific (Week 4)

• Complete 3–5 full 45–60 minute mock interviews
• Prepare 3–4 questions per interview round
• Prepare your close for each round

On the day of

• Reread your experience inventory — refresh the stories in your memory
• Review the company’s product one more time
• Know the format: how many rounds, who is interviewing you, what each round tests
• Have water. Take pauses. Thinking aloud before answering is a feature, not a bug.

Project: [name]
Goal: [what success looked like]
What I did: [your specific contribution]
Result: [number + timeframe]
Lesson: [one thing you'd do differently]

Related pages

• Your PM Story — how to structure your “Walk me through your background” and “Why PM?” narrative
• Product Sense — the mental models behind strong product teardowns and design answers
• Prioritization Frameworks — the frameworks you should know, when they apply, and when they break
• Metrics and Analytics — how to build the analytical depth that holds up under follow-up questions