Cracking the Behavioral Interview: What details should you include in your story?
How to be specific without rambling
One of the most common mistakes I see is people who are too vague, generic, or surface level.
It’s a much bigger problem than candidates who ramble on for too long, although I often see both at the same time: rambling about surface-level process.
As an interviewer, I can’t get any signal if you were good at your job when you tell me “I interviewed users to identify their top problems and then prototyped designs to get my solutions approved.” I assume that you’re just following the process that every PM at your company follows. The fact that you don’t realize this isn’t useful counts slightly against you.
More detailed answer still don’t always give me the signals I’m looking for. “I built custom AI dashboards leading to 15% additional revenue” sounds promising. But, I’ve heard this story several times and sometimes this was a founder-led project where the candidate made very minor contributions.
The trick to sounding impressive is to show how hard the work actually was.
You need to include the right details. The ones that show the complexity of the problem and how you specifically drove good results.
It’s not easy to remember the juicy details of a past project, so here are some prompts to help you surface the good stuff:
Quick intro to industry/company/team
Starting context (so you can contrast what you did)
Your insights & how you came up with them
Choices/Options/Tradeoffs
Pushback, their reasons why, how you overcame
Your strategy/values that played a role
The results, and the context they need to understand the results
These details will become the key content in your stories. Don’t worry too much about the format of your answers yet, it’s too early for that constraint. Let’s explore each of these areas.
Quick Intro
If you want your interviewer to understand your story, you’re probably going to have to teach them a little bit about your company, industry, or team before you get into your story.
Goals: It’s totally fine to re-use your company’s talking points on mission and strategy
Customers: Who are your customers, what are their problems, what’s different about them that the interviewer might not know
Here’s a quick example
“At Asana our mission is to help teams work together effortlessly. What’s unique about our target customer is that we really go after the reluctant project manager - maybe a marketing person who’s just been promoted and they realize they won’t be able to get their campaigns out without a bit of project management.”
Use this as a chance to establish your expertise.
Starting Context
You need to start your story by setting up the background context. You need to explain what things were like before you started, so that people can understand how you made a difference.
This bit corresponds to the “Situation” in STAR, or the “Problem” in the PEARL framework.
To understand why this is so important, you need to know a little bit about how managers assign projects.
Sometimes there’s a straight-forward, low-impact project that’s the perfect scope to hand to someone junior, eg. “Build CSV export.” These are easy for the interviewer to evaluate as junior-level.
But a lot of the time the manager needs the junior employee to work on something complex and important. They don’t trust the junior person to handle everything on their own, so they need to scope it down. A common way to scope a complex problem down for a more junior employee is to give them more scaffolding:
Tell them the problem they need to solve
Tell them what the solution should look like
Tell them step-by-step how to achieve that solution
(credit to Shishir Mehrotra’s PSHE framework).
So for complex, high-impact projects, the interviewer needs to figure out how much of the problem and solution were handed to you, and how much you drove on your own.
If you drove the whole project from figuring out the problem all the way through discovering and implementing the solution, there might be 3 or more different stories you can tell about the one project. Pick the most senior one as your primary story, and keep the details of the others for when you need to highlight a specific strength in execution.
What were the expectations you were handed, and what did you decide to do?
To accurately portray your seniority, you need to make it clear which parts of the scaffolding you were or were not given. What details do you have that set up the context to highlight the contrast?
Company leadership thought our biggest opportunity was going after the educational market, but I dug into competitive research and found out…
My manager thought we’d solve our new user adoption problem through an onboarding tour, but looking at the data I realized…
The previous PM had tried to work with our partners by sending them weekly status updates, but through talking to them I learned…
Pop quiz: If you want to make these even better, should you emphasize how good the previous direction was, or how bad it was?
Do you throw in a detail that emphasizes how wrong your manager was? “She was brand new to SAAS products so she didn’t understand that tours don’t work.”
Or one that makes it sound like she might have been on to something? “Our closest competitor had added a tour 3 months ago and we were hearing that it was working”.
Many candidates get this wrong.
Answer: If you make the initial direction sound clearly bad, then it wouldn’t take a genius to switch to a better direction. It also makes me wonder why you’re badmouthing your previous coworkers, and if maybe you were missing something.
If you show all the reasons why the initial direction seemed good, now your pivot sounds impressive. It would have been easy to go along with what people expected, and you understood why they liked that direction, but you went above and beyond to identify something better. Now I start to feel like you might come in and teach me something.
Your insights
You might have noticed that the examples above all go “Other people thought X, but I realized…”
That’s because we’re highlighting the contrast between what would have happened without you, and how you made a difference. There’s some reason that you decided not to go with the flow, and that reason is the insight you had. We could also call this your “Aha moment” or Epiphany in the PEARL framework.
Your insights and how you came up with them are a huge part of the value that you bring. As an interviewer, this is what helps me understand you and what you might do at my company. If you tell me an insight on it’s own, I don’t know how much to believe you.
“I realized our onboarding flow was too difficult” is vague and I’m not convinced. Every APM wants to make onboarding easier. Even if I believe you, I don’t have a sense for how bad the problem was or how easy the solution would be.
If the onboarding pages crashed for half your users and you prioritized fixing that, good for you, but also, duh obvious. I’d say this is a case of taking “Project you’re proud of” a little too literally.
Side note: a nice way to handle this, that many candidates do, is to quickly mention this low-hanging fruit win but then spend your time talking about a meatier project.
Your insight should be non-obvious.
Now, just because the insight should be non-obvious, doesn’t mean that the way you found it needed to be.
Many of these insights are powered by some kind of research you did, either in the moment or earlier in your career. Maybe you were talking to a customer, maybe you watched a user research session, maybe you sliced the data a certain way, maybe you learned something in a blog post or at a conference last year. The other common driver is your own past experience, you saw something like this before.
Since the broad strokes of how you came up with the insight are not that impressive nor unique, you need to share the specific details of what you found and the connections you made. This is a chance to teach the interviewer something and show off your expertise.
Examples
Here’s a few examples from my own experience
Early at Asana we were trying to figure out our target customer so I put together a giant spreadsheet of potential target use cases and what features we would need to be a great solution for each use case. Looking at it, I could see that some use cases would have a large valuable target market, while others were smaller. And for some use cases we were really close to being the best solution out there, while for others there was years of feature work required. I realized that some of the smaller use cases like sprint planning were a near-subset of larger use cases like bug tracking. This helped us put together a plan to win some use cases quickly while we built toward bigger ones.
I’d been looking at the data for Asana and pondering how to improve word of mouth growth, since normal people don’t really recommend task managers to their friends. I noticed that the one thing people got really excited about was our off-by-default unicorn celebrations. Putting these together, it felt worth a try to turn unicorns on by default, and we were able to measure a win by tracking tweets.
I started walking through the user journey for OpenBallot and had learned from the team that we expected a lot of users to come in on election day through Google searches. I knew from past experience that these users will bounce if they don’t immediately find useful content on the landing page, so I realized we needed to change our model to optimize for logged out users.
Notice how these get fully into the details, the same way I’d describe the situation to a coworker while it was happening. I’m not spending much time on the process, but I am really trying to share all the things I was thinking about, remembering, noticing.
When you read these, do you believe I’m telling the truth? Do I sound like I’m accurately portraying my contributions or do you have a hunch that I’m exaggerating? Do I sound like I’m bragging too much or conversely like I’m just talking about my team’s accomplishments?
My guess is that you believe me because I’m talking about what the experience was like in the moment.
Choices/Options/Tradeoffs
When you’re applying to senior level roles, decision making is 1/3 of the rubric.
I like to think of it this way: if the decision was easy, someone else on my team would have made it already. Hopefully I’ve already empowered my team with the goals, principles, and frameworks they need to answer easy questions. If the decision is coming to me, it must be complex, and deserves some intentional thinking.
What were the complex choices on your project?
Just like with Starting Context above, you want to make the other options sound as good as possible. Explain the pros and cons of each side. Describe what tipped you over to the choice you went with, and how you mitigated the tradeoffs.
What were the options?
What were the pros & cons on each side?
What tipped you over to the decision you made?
How did you mitigate the tradeoffs?
For a large project you might have several examples of complex choices and tradeoffs. If you have time, jot down the details for each of them so that you can use them as examples of specific strengths or situations.
In the interview itself, you can briefly hint at each, but dig into just one: “There were a lot of interesting decisions, we had to figure out the data model, testing plan, and marketing approach, I can dig into any of those if you like, but I think the most interesting was how we handled it when we realized the vendor’s product didn’t meet our requirements”
Pushback
Pushback (or as interviewers might phrase it, conflict) is expected in complex projects. Many interviewers will explicitly ask you to talk about a conflict at work.
Stepping outside of interviews for a second, when you’re at work you should be handling pushback by genuinely listening to understand the other person’s point of view.
I know this doesn’t come naturally in a lot of company’s cultures. At Google and Microsoft it was common in hallway conversations to talk about how annoying salespeople were with their useless feedback. Or to complain about the terrible people on another team who wouldn’t help out with what your team needed.
Please avoid this temptation — you’re all working at the same company with the same shared mission. More than that, when you fall into the trap of thinking your team is better/more-important than other teams, you’re failing to grasp the bigger picture of how your company works, which means you can’t make informed decisions.
Once you understand the other’s point of view, you have lots of options for how you handle it. Maybe they’re making a valid point and there’s a win-win solution that works for both of you. Maybe they’re surfacing a higher level strategic misalignment that you can tackle with the right people in the room. Maybe you have some facts you can share that will bring them to your side. Maybe they need a different kind of communication from you to do their job well.
Back in interview land, you might want to prepare 2 examples of pushback.
The first is your best time handling pushback — the time when you really went above and beyond understanding the stakeholder’s point of view and coming up with a much better solution than expected. That’s the one you can use if you’re asked to talk about a conflict.
The second is the best example you have of pushback in the project you choose for your seniority story, in case they decide to specifically ask about conflict on that project. If you’re especially proud of how you handled it, you can include it in your original answer.
Your strategy and values
When you’re working on a project, you don’t reinvent the wheel at every step. Instead, you learned what works and what doesn’t over time, and you accumulated those experiences into a strategies, principles, and values.
For your story, think about each action you took and whether there was a hard-earned principle behind it. Things like prioritizing user trust, balancing speed with quality, or aligning stakeholders by giving them each a chance to be heard.
When you’re telling the story, you can include these principles to show off your expertise. “Whenever I put together a roadmap, I like to check that we have the right balance between improving existing functionality and enabling new use cases…”
The results
At the end of your story, the interviewer is going to try to assess whether you actually did a good job.
When thinking about your results, numbers are good, but they’re not always enough. How do I know if your 10% increase in adoption was impressive or not? Include the context to help the interviewer interpret it — maybe the team expected you to have only a 2% win, maybe this was the largest adoption win that year. Find the details that are convincing.
What not to include
Okay, so there are a lot of details you need to include, and you don’t want your story to be longer than 5 minutes, so what can you skip?
Process: Don’t list out basic steps (I wrote a PRD, I joined the standups, I asked for approval), unless the interviewer has indicated they want to hear them.
Multiple challenges: Pick your best 1 or 2 challenges to dive into, and for the rest just let the interviewer know you could dive in if they want. Especially skip the stories that aren’t demonstrating an important skill or value.
Boring stuff: If you’re excited about something, you can sell it well. If you can’t talk about something with high energy, skip it.
Conclusion
A good behavioral interview response will get detailed and specific on the impressive parts of your story.
This prep is easier to do with a buddy, so try out this custom GPT, Find the Impressive Parts of Your Story
Good luck!
In case you missed them,
Cracking the Behavioral Interview: Build up your Interview Confidence with a Wins Warmup
Cracking the Behavioral Interview: "Tell me a project you're proud of" - 4 Mock Interviews
Cracking the Behavioral Interview: What is the interviewer looking for?
Cracking the Behavioral Interview: Which project should I talk about?
Cracking the Behavioral Interview: What makes a story impressive?