Prepare for a product manager role.

Key terms

Product sense question

A question that asks you to design or improve a product for a specific user and problem, like “Design a better way to choose a sofa online.”

Execution question

A question about running the work: setting goals, choosing between priorities, or finding out why a metric moved.

Estimation question

A question that asks for a number you can’t look up, solved by breaking it into parts you can reason about. Also called a guesstimate or a market-sizing question.

Behavioral question

A question about what you actually did in the past, like “Tell me about a time you disagreed with an engineer.”

STAR method

A way to tell a story from your past: Situation, Task, Action, Result.

Mock interview

A practice interview with a partner playing the interviewer, followed straight away by feedback.

Rubric

A short list of what a good answer shows, used to give feedback that’s specific, not just “that was good.”

The idea

Preparing for a product manager interview isn’t like studying for an exam. There’s no syllabus to memorize, and a perfect framework recited from memory usually sounds like exactly that. What interviewers want to see is how you think: about a customer, a number, a trade-off, a time things went wrong.

So the work is practice, not reading. This lesson shows what each interview tests, what to build so you have something real to talk about, and a six-week plan that ends with mock interviews. The earlier lessons in this course are your study material. This one turns them into answers you can give out loud.

The lesson, in seven parts

1. 1Know what each interview tests.

   Companies name and mix their interviews differently, but most product manager interviews draw from the same handful of types. Learn what each one is really testing, and you’ll know what to practice:

   Interview type	A typical question	What it tests	Where to practice in this course
   Product sense (or product design)	“Design a better way to choose a sofa online.”	Picking a user and a problem before a solution; ideas; trade-offs	Lessons 2, 8, and 14
   Metrics and analytics	“How would you know the room planner is working?”	Choosing a goal and the few numbers that show progress	Lessons 4 and 6
   Estimation	“How many sofas are bought in the US each year?”	Breaking a big unknown into parts; stating assumptions; checking	Lesson 13
   Execution	“Orders dropped 10% last week. What do you do?”	Priorities, diagnosis, and calm structure under pressure	Lessons 3, 5, and 7
   Technical	“What happens when a shopper taps Buy?”	Enough understanding to talk trade-offs with engineers	Lesson 9
   Behavioral	“Tell me about a time you changed someone’s mind.”	What you actually did, and why: ownership, judgment, working with others	Lesson 15

   The questions are made-up examples. Names and the mix of interviews vary by company and level; always check the company’s own careers pages and ask your recruiter.

   Here’s one company that publishes its process. Amazon’s product manager interview prep page says the first call, the phone screen, is 60 minutes, half behavioral questions on its Leadership Principles and half functional questions about your product management experience. After that comes the loop, the main round: five 55-minute interviews, with a writing assessment before it. It also says: “We won’t ask brain teasers” (and its interview guide counts estimation puzzles among them). Other companies differ, which is why this step matters. Before you practice anything, find out what you’re practicing for.

2. 2Do you need to code?

   Here’s the honest answer: usually not, but you do need to understand how software gets built. Most product manager interviews don’t ask you to write code. They do expect you to talk sensibly with engineers about how a product works and what a change would cost.

   Some roles go further. Technical product manager roles can test technical depth directly. Amazon, for example, lists a separate Product Manager, Technical (PM-T) role: its phone screen spends half the time on “technical product life cycle” questions, and its loop includes technical depth as one of the areas assessed. The job posting is your best clue. If it asks for a computer science degree or experience with APIs or platforms, expect harder technical questions. Either way, here’s the technical understanding most interviews do expect. You should be able to:

   • Explain what happens when someone taps Buy: the app, the server, the database, and the outside services in between.
   • Say what an API is, in one plain sentence, and why teams use them.
   • Talk about trade-offs: faster to build versus easier to change later; build it versus buy it.
   • Ask good questions about cost and risk, like “What’s the hardest part of this?” and “What could break?”
   • Read a simple chart of how a feature is used, and say what it does and doesn’t show.

   If you come from engineering, the risk runs the other way. Interviewers will expect solid technical answers, and they’ll watch whether you can start from the customer instead of the system. Give product sense and behavioral questions extra practice time, and start each product answer from a customer. Either way, Lesson 9 covers the system basics a product manager needs.

3. 3Build evidence you can talk about.

   Without the title, it can feel like you’ve got nothing to point to. You probably have more than you think, and you can build the rest in a few weekends. Interviewers trust evidence over claims. “I’m customer-focused” is a claim. “I talked to six people who’d just bought a sofa, and here’s what surprised me” is evidence.

   Three kinds of evidence work well, in rising order of effort:

   Evidence	What it looks like	What it shows
   A case write-up	One or two pages on a real product you use: who it’s for, one problem, your idea, how you’d measure it	Product sense and clear writing
   A small side project	A simple prototype, a no-code tool, or a survey with real answers from real people	That you can turn an idea into something testable
   Something you shipped	A change at your current job, a club’s sign-up page, a tool your team now uses	Ownership, working with others, and a result you can describe

   Keep each one small and finished. One finished write-up beats three half-built apps.

   The template

   [Product] helps [which users] do [what]. I noticed [problem], and I checked it by [what you did: talked to N people, read reviews, tried it yourself]. I’d try [one small idea] first, because [reason]. I’d know it worked if [observable change]. What I’d test next: [the biggest open question].

   Filled in, for the made-up furniture store

   The made-up furniture store helps first-apartment movers buy furniture online. I noticed shoppers leave product pages to measure their doorways, and I checked it by reading 40 product questions and talking to five recent buyers. I’d try a simple doorway-size check first, because it’s cheaper to test than a 3D room planner. I’d know it worked if fewer shoppers asked about fit before buying, and fewer sofas came back for size. What I’d test next: whether people trust a measurement they type in themselves.

   The template is a case write-up in one paragraph. Expand it into a page, add one sketch, and you’ve got something to walk an interviewer through.

4. 4Write your stories before you need them.

   Behavioral questions ask what you did, not what you’d do. You can’t invent good answers on the spot, but you can prepare true ones. Write a story bank: a handful of real moments from work, study, or volunteering (start with three to five), each one usable for several questions.

   Shape each story with STAR. Amazon’s interview guide describes it this way: Situation (set the scene), Task (your goal, and what you were responsible for), Action (what you did, step by step), and Result (how it turned out, and what you learned). It also calls STAR “simply a tool to help you organize your thoughts”. It isn’t a script.

   Common prompt	What it’s looking for	Pick a story where you…
   “Tell me about a time you disagreed with someone.”	How you handle conflict and change minds	Used evidence to settle a disagreement, or were persuaded yourself
   “Tell me about a failure.”	Honesty, and what you learned	Got something wrong, said so, and changed what you did next
   “Tell me about a hard decision with too little data.”	Judgment under uncertainty	Chose, explained why, and checked afterward
   “Why product management?”	Real motivation, backed by things you’ve done	Did product-like work before you had the title: talked to customers, chose what to fix, or brought people along

   Lesson 15 goes deeper into behavioral questions and how to tell these stories well.

   The result is the easiest part to rush: say what happened afterward, and what you learned. And focus on your own part. Amazon’s guide suggests saying “I” instead of “we” when you describe your actions, because interviewers are trying to find what you did. And not every story has to be a success: what you learned counts.

5. 5Follow a six-week plan.

   You can prepare in four weeks if you must, or stretch it over eight. Six is a comfortable middle for someone with a job. What matters is that you can keep the plan, about an hour on most weekdays and a longer session at the weekend. Here’s one shape that works:

   When	Focus	What you do
   Week 1	Learn the formats	Read the company’s careers pages; list the interview types; draft your story bank; start one case write-up
   Weeks 2 and 3	One question type a day	Rotate product sense, metrics, estimation, execution, technical; tell two stories out loud at the weekend; answer out loud, timed, then compare with the matching lesson (see the table in part 1)
   Weeks 4 and 5	Mock interviews	Two or three a week with partners; full length; feedback straight after; keep a list of what keeps going wrong
   Week 6	Sharpen and research	Fix the top two weak spots; use the company’s product; prepare questions to ask; rest the day before

   General advice, not a rule. If you only have four weeks, shorten weeks 2 and 3, and keep the mocks.

   Answer out loud every time, even alone. An answer that’s clear in your head often falls apart when you say it, and the interview is spoken. Record a few answers on your phone and listen back. It’s uncomfortable, and it works.

6. 6Run mock interviews, with real feedback.

   Practice without feedback mostly repeats your habits. Psychologist K. Anders Ericsson and colleagues, in their 1993 paper on deliberate practice, put it bluntly: “In the absence of adequate feedback, efficient learning is impossible and improvement only minimal even for highly motivated subjects.” A mock interview is how you get that feedback before the real one.

   A simple setup is a group of three, swapping roles each round. One person interviews: asks the question, probes, keeps time. One is the candidate: thinks out loud and answers. One observes, with a rubric, and leads the feedback. Then everyone moves one seat. You learn as much from watching and interviewing as from answering. Here’s a simple rubric for the observer:

   • Did they ask clarifying questions before diving in?
   • Did they pick a specific user, or a clear goal, and stick to it?
   • Was the structure easy to follow? Could you write it down as they spoke?
   • Did they say their assumptions and trade-offs out loud?
   • Did they finish with a clear recommendation, and say what they’d check next?

   Say

   • “You jumped to features in the first minute. Try naming the user first.”
   • “Your estimate was clear, but you never checked it. Add one sanity check.”
   • “That story had no result. What happened afterward?”

   Avoid

   • “That was great.” It’s kind, but it gives them nothing to change.
   • “I’d have done it differently.” Say what, and why.
   • Ten notes at once. Pick the two that matter most.

   If you can’t find partners nearby, find them online in product management communities, or ask a working product manager for one 30-minute mock. A specific, small request is much easier to say yes to.

7. 7In the room: think out loud, and research the company.

   Whatever the question, a few habits help every answer. They’re general advice, and they follow straight from what interviewers are trying to see:

   • Repeat the question in your own words, and ask one or two clarifying questions.
   • Take a few seconds to plan, and say you’re doing it. Silence while you think is fine.
   • Give your structure first: “I’ll pick a user, find their biggest problem, then suggest and rank ideas.”
   • Think out loud. The interviewer can’t give credit for reasoning they don’t hear.
   • End with a recommendation, the main risk, and what you’d check next.

   Then do the company homework. Use the product as a customer for a week. Read the company’s careers pages and recent announcements. Note one thing you’d improve and why, and one thing you admire. Prepare two real questions for them, like “How do teams here decide what to build next?” It shows you care about the work, not just the offer.

With AI: AI is a useful practice partner. You can ask it to play an interviewer, to throw follow-up questions at your answer, or to point out where your structure was hard to follow, at any hour. Treat its feedback as a first pass, not a verdict: it can sound sure about things that are wrong, and it won’t notice that you rushed or went quiet. Use it to get more repetitions, and still do mock interviews with people. And don’t let it write your stories. Interviewers ask follow-up questions, and only true stories hold up.

ROLE AND COMPANY:
Interview types to expect (from the careers page, posting, recruiter):
  [ ] Product sense   [ ] Metrics   [ ] Estimation
  [ ] Execution       [ ] Technical [ ] Behavioral

TECHNICAL CHECK (can I explain it in plain words?)
  What happens when someone taps Buy:
  What an API is:
  One build-vs-buy trade-off:

EVIDENCE (small and finished)
  Case write-up: [product] helps [users] do [what]. Problem I noticed:
  How I checked it:     Idea:     How I'd measure it:

STORY BANK (Situation, Task, Action, Result)
  1. Disagreement:
  2. Failure and what I learned:
  3. Decision with too little data:
  4. Why product management:

SIX-WEEK PLAN
  Week 1: formats, stories, start write-up
  Weeks 2-3: one question type a day, out loud, timed
  Weeks 4-5: mock interviews, feedback straight after
  Week 6: fix top two weak spots, company research, questions to ask

MOCK INTERVIEW RUBRIC
  [ ] Clarified the question   [ ] Picked a user or goal
  [ ] Clear structure          [ ] Said assumptions out loud
  [ ] Clear recommendation and next step
  Two things to change next time:

Ask AI about this lesson

All lessons