Behavioral questions.

Key terms

Behavioral question

An interview question about what you did in a real past situation, often starting “Tell me about a time…”.

Hypothetical question

A question about what you would do in an imagined situation, such as “What would you do if…”. Different from a behavioral question, which asks what you did.

STAR

A structure for answering behavioral questions: Situation, Task, Action, Result.

SOAR (interviews)

A variant of STAR: Situation, Objective or obstacle, Action, Result. Not the strategic-planning framework with the same name.

CAR

A shorter structure: Challenge, Action, Result.

Story bank

A short list of your real experiences, each written up in STAR form and tagged with the questions it can answer.

The idea

Some interview questions ask what you know. Behavioral questions ask what you’ve done. “Tell me about a time…” “Describe a situation where…” “Give me an example of…” There’s no clever answer to work out. There’s only your experience, told well or told badly.

Told badly sounds like this: a long setup, a lot of “we”, a vague ending, and no clear point. Told well, it’s a short story with a beginning, a middle, and an end, where the listener can see exactly what you did and why. This lesson teaches the structure, the preparation, and the practice that get you there. The model answers come from a made-up candidate, Maya, so you can see the shape without borrowing anyone’s story.

The lesson, in seven parts

1. 1What a behavioral question is listening for.

   Behind every “Tell me about a time…” is a simple bet: how you handled things before is a decent guide to how you’ll handle them here. MIT’s career office puts the idea plainly: “The purpose of behavioral interviewing is to objectively measure a potential employee’s past behaviors as a predictor of future results.” Amazon’s guide to its own interviews puts it this way: behavioral questions “help us understand how you approach challenges, make decisions, and work with others.” It adds that Amazon avoids brain teasers “because they don’t reliably predict success.”

   So the interviewer isn’t grading the story’s happy ending. They’re listening for how you think and act. Did you notice the real problem? Did you choose, or drift? Did you bring people along? Did you learn something?

   That changes how you listen to the question. “Tell me about a time you disagreed with an engineer” isn’t about the disagreement. It’s often about how you handle disagreement with people who don’t report to you. Working with people you don’t manage is a big part of a product manager’s job. Before you answer, ask yourself what the question is really probing, and pick the story that shows it best.

2. 2Structure the answer with STAR.

   STAR is a common structure, and it’s the one both MIT’s career office and Amazon’s interview guide teach. Amazon describes it like this:

   Letter	What it answers	Rough share of your answer
   Situation	What was going on? Where were you, and what made it interesting or hard? Just enough background for the big picture.	About 20%
   Task	What was your goal? What were you responsible for?	About 10%
   Action	What did you do, step by step? Your own contribution, even on a team.	About 60%
   Result	How did it turn out? What did you accomplish, and what did you learn?	About 10%

   Descriptions follow Amazon’s “Interview loop” guide. The shares are the rough guide from MIT Career Advising and Professional Development.

   Look at that last column. It’s easy to spend half your answer on the situation and rush the action. Flip it. The action is where the interviewer learns about you. Two more habits worth keeping:

   • Say “I”, not only “we”. Amazon: “It’s helpful to use ‘I’ instead of ‘we.’” MIT suggests focusing on how you contributed to the team’s outcome. Credit the team, then be clear about your part.
   • Tell one specific situation, not a summary of how you usually work. Amazon asks for “a detailed account of one situation for each question you answer.”

3. 3Know what SOAR and CAR add.

   You’ll see two other acronyms. Both keep STAR’s backbone: what you did, and what happened.

   SOAR, as UC Berkeley’s Executive Search team describes it for interviews, stands for Situation, Objective or obstacle, Action, Result. Its second step asks: “What was your objective, goal, and/or obstacle that you had to achieve or overcome?” It’s useful when the obstacle is the heart of the story, such as a key person leaving halfway through.

   CAR, as the University of Wisconsin-Superior’s career center teaches it, stands for Challenge, Action, Result. The challenge folds the situation and the problem into one step. UW-Superior presents it for networking as well as interviews, and with one less step it suits shorter answers.

   Amazon’s guide says STAR is “not the only way to share your experiences. It’s simply a tool to help you organize your thoughts and tell a story that brings your strengths to life.” Pick whichever helps you tell a clear story. Interviewers care about the story, not the acronym.

4. 4Build a story bank before you need it.

   Trying to find a story in the moment is how good candidates freeze. So prepare. MIT suggests preparing 3 to 5 stories. Amazon suggests having “a few examples ready that highlight different strengths, including times you’ve taken risks, succeeded, failed, and grown.”

   The trick is that one good story answers several questions. A story about using support data to change a delivery process can answer “a time you used data”, “a time you influenced someone without authority”, and “a time you disagreed with a stakeholder”. Here’s how to build the bank:

   • List 8 to 10 moments from work, school, or volunteering where you made a real difference, struggled, or changed your mind.
   • Write each one as short STAR notes, not a script: a line each for the situation and task, three or four lines for your actions, a line for the result and what you learned.
   • Tag each story with the themes it can answer: conflict, data, failure, prioritizing, leading without authority, a customer insight, a hard trade-off.
   • Look for gaps. If no story covers failure, find one. Failure comes up often; Amazon’s product manager prep page asks for examples of how you’ve “taken risks, succeeded, failed and grown.”
   • Keep the best 5 or 6 ready, with a mix of themes. That’s a little more than MIT’s 3 to 5, so you have a spare when one story doesn’t fit.

5. 5Talk about results honestly.

   Numbers make a result concrete. MIT says it’s “important to highlight quantifiable results”, and Amazon says that if you have “any numbers or specific outcomes to back it up, even better.” But a number you can’t explain is worse than none. Interviewers ask follow-ups, and an inflated number falls apart on the second question.

   Some habits that keep you honest:

   • Use only numbers you can explain: what was measured, compared with what, and over what time.
   • Separate what you did from what the team did, and from what else changed at the same time.
   • Use a range or a rough figure when that’s all you know, and say so: “about”, “roughly”, “in the first month”.
   • If you have no number, describe the change you could see: what people did differently afterward.
   • Don’t share figures your employer treats as confidential. Describe the direction and size in general terms instead.
   • Include what you learned, especially when the result wasn’t a success. Amazon: “not every story has to be a success.”

   The template

   Result: [what changed], measured by [what], from [before] to [after] over [time]. My part was [your contribution]. What I learned: [one lesson you still use].

   Filled in, for the made-up furniture store

   Result: in the pilot region, delivery-timing calls fell from about 120 a week to about 70 in the first month, while the other regions stayed about the same, measured by our support ticket tags. My part was finding the pattern and making the case; operations made the change. What I learned: bring the customer’s words, not just the count. (Made-up candidate, made-up numbers.)

6. 6Shape answers to the common product questions.

   Product manager interviews mix true behavioral questions with a few about your motivation and judgment. Here’s what each one is usually after, and the shape of a strong answer:

   Question	What it’s usually probing	Shape of a strong answer
   Why product management?	Do you know what the job is, and why you want it?	A real moment that pulled you toward it, what you understand the job to be, and evidence you’ve already done parts of it
   Tell me about a time you faced a challenge working with a team.	Collaboration and conflict	STAR: your part, how you handled the people, what you’d keep or change; no blaming
   Tell me about a time you chose between faster and better.	Judgment on trade-offs	What was at stake each way, how you decided, what you shipped, and how it turned out
   Tell me about using data to influence a stakeholder.	Evidence and persuasion without authority	What they believed, what you gathered, how you showed it, what changed
   Why this company?	Research and real interest	Specific products and customers you’ve looked at, and how your experience fits; not general praise
   How do you prioritize?	A method, and whether you use it	Name a method (see lesson 3), then one real example of using it
   What would you change about our product?	Product sense	A short app critique (see lesson 14): one user, one problem, one fix, its trade-off, and how you’d measure it

   The middle column is a common reading of each question, not an official rubric. Companies differ.

   Here’s a full model answer from Maya, a made-up candidate who has led a support team at the made-up furniture store for three years and wants to move into product. The question: “Tell me about a time you used data to influence a stakeholder.” Situation: “Last spring, calls about late deliveries were our biggest category, and the operations manager believed most were customers who’d missed the delivery text.” Task: “I wanted us to fix the cause, not just answer calls faster, but operations wasn’t my team.” Action: “I tagged two weeks of delivery tickets myself, about 400 of them. Most came from one region, and the customer’s words were nearly always the same: the text gave an eight-hour window. I took ten real quotes and the regional split to the operations manager, and asked one question: could the text give a two-hour window? I offered to have my team track the effect.” Result: “Operations piloted it in that region. Delivery-timing calls there fell from about 120 a week to about 70 in the first month, while the other regions stayed about the same, and they rolled it out everywhere. I learned that a pattern in customers’ own words persuades faster than a chart.” Notice the balance: one sentence of situation, most of the time on action, an honest result with her part made clear.

7. 7Practice out loud, then let it go.

   A story you’ve only thought about isn’t ready. Say it out loud, time it, and listen back. Aim for about two minutes as a starting point, then adjust to the interviewer. Amazon’s tip helps when you’re unsure: pause after your answer and ask if the interviewer would like more context.

   Don’t memorize a script, though. MIT warns that scripting stories “may limit your ability to adapt as needed in an interview, and can seem unnatural or disingenuous to an interviewer.” Learn the bullet points. Tell the story fresh each time.

   Then prepare for the follow-ups, because that’s where interviewers dig. After every story, ask yourself these, or have a friend ask them:

   Follow-ups to practice

   • “What would you do differently?”
   • “How did you measure that?”
   • “What did the other person think?”
   • “What was your part, exactly?”
   • “What happened after?”

   Avoid

   • Memorizing word for word
   • Telling the same story for every question
   • Ending without a result
   • Rehearsing only in your head
   • Hiding failures; pick one you learned from

With AI: AI can help you prepare: it can ask you practice questions, point out when you said “we” twelve times, or tighten a rambling draft. Two cautions. An AI can make up details that sound like yours, and an invented detail is still invented when you say it in an interview. And interviewers hear many polished, generic answers; your real specifics are what make a story yours. Use AI to practice and edit, not to write your past.

STORY TITLE:
Themes it answers (conflict, data, failure, prioritizing, influence, customer insight, trade-off):

SITUATION (one or two sentences):
TASK (my goal, my responsibility):
ACTION (what I did, step by step; say "I"):
  1.
  2.
  3.
RESULT (what changed, measured how, over what time; my part vs. the team's):
WHAT I LEARNED:

LIKELY FOLLOW-UPS, AND MY ANSWERS:
  What would you do differently?
  How did you measure that?
  What did the other person think?

----------------------------------------
MY BANK AT A GLANCE
Story | Conflict | Data | Failure | Prioritizing | Influence
1.
2.
3.
4.
5.
Gaps to fill:

Ask AI about this lesson

All lessons