Course

Common Pitfalls

The most frequent behavioral interview mistakes and how to fix them, from missing the underlying assessment to fairy tale endings, plus pitfalls by signal area and level.

Introduction: The Most Common Behavioral Interview Pitfalls

0:00

22:20

Video Content

After coaching hundreds of candidates through behavioral interviews, we've noticed the same mistakes appearing over and over again. Most candidates have strong experiences and compelling stories, but certain weaknesses in how they approach interview prep or how they tell their stories hold them back from a hire decision.

The good news is that these pitfalls are entirely avoidable and most of them can be addressed simply by being aware of them.

Pitfall #1: Missing the Underlying Assessment

Every behavioral question tests something specific. Interviewers aren't asking random questions because they're curious about your life. Instead, they're probing for specific signal areas: Ownership, Perseverance, Communication, Conflict Resolution, and so on that we talk about in our article on how behavioral interviews work. If you miss what they're actually testing, your entire answer goes off-target, no matter how well you tell the story.

Consider a question like "Tell me about a challenging project." The word "challenging" is doing a lot of work here. The interviewer wants to hear about Perseverance, how you hit a real wall and pushed through it. They want to understand how you maintained motivation when things got hard, what approaches you tried when the first solution didn't work, and how you adapted your strategy while maintaining focus on the core objective.

But what do many candidates do? They spend three minutes describing the technical architecture and thirty seconds on the actual challenge. They're so eager to demonstrate technical competence that they forget the question wasn't "Tell me about an interesting system design," and the interviewer walks away without the signal they needed.

Pause for a few seconds after hearing the question. Ask yourself: what signal are they actually looking for? Then select your story accordingly. It's ok to spend some time to think.

Pitfall #2: Not Enough Actions

Actions are the center of any behavioral interview story. That's where the signal the interviewer is looking for lives and that's what will go into their notes. Everything else (Context, Results, Learnings) is supporting material.

When I listen to candidate responses, I'm looking for those repeatable actions to see how they would play out on my team, if I were to hire this candidate. Did they describe what they actually did? Can I picture the specific steps they took? Do I understand their decision-making process? Too often, candidates offer something like this:

"We had a tight deadline on a project at my fintech company to add a search filter. I built the filter, after a couple weeks of testing, and shipped it on time. The customers liked it and we hit our metrics."

This tells me almost nothing. What did you actually do? How did you build it? What decisions did you make along the way? What obstacles did you encounter? The shallow context, quick "I built the feature" summary, and vague sense of results leave me without any evidence of your capabilities.

Interviewers are looking for you to list as many relevant actions as possible because they're assessing whether you can repeat your results in their organization. They care less about what happened and more about what you did to make it happen.

Consider how different this sounds:

"I improved our service's performance by identifying that we were making N+1 queries on our product listing page. Every product triggered a separate database call for its reviews. I refactored this to use a single JOIN query with eager loading, which reduced our p95 response time from 3.2 seconds to 400ms. Customer support tickets about slow loading dropped by 60% in the following month."

Now I can see your technical judgment, your debugging approach, and the business impact of your work.

The 30-second rule: If you've been talking for thirty seconds and haven't shared an action that moves the story forward, you're providing too much detail on something that isn't the point.

Remember that actions extend beyond building things. Think about:

Designing: System design choices, API specifications, architecture decisions. How did you gather the needed information? What alternatives did you consider?
Aligning: Building consensus among stakeholders, negotiating priorities and tradeoffs, coordinating across functions.
Communicating: Technical documentation, leadership presentations, difficult conversations, translating complex concepts for different audiences.
Implementing: Resource allocation, technical execution, risk mitigation. What did you do that another person in your role might not have done?
Iterating: Gathering feedback, measuring results, making course corrections based on new information.
Debugging and Analyzing: Root cause analysis, performance optimization, quality assurance.

Watch for passive language in your responses: "I was assigned this project," "My manager asked me to," "The ticket came to me." These phrases make you sound like work happens to you rather than you driving the work. Even if you were assigned something, focus on what you chose to do once you had it.

Pitfall #3: Context Overload

The context you provide should be the minimum needed to understand your actions and why they mattered. The most critical aspect of this context is establishing the stakes: why the work was important to the organization and its customers.

A feature that prevents customer churn carries different weight than a nice-to-have enhancement. Interviewers need to understand that distinction. But they don't need to understand your org chart, your sprint process, the history of your team, or the background of your manager — unless those things were important to the actions.

Target about 10% of your story on context. For a three-minute story, that's roughly twenty seconds. If you're explaining background for more than thirty seconds, stop and ask: does the interviewer actually need this to understand my actions?

Include context details only if they (1) establish the stakes of the problem, or (2) make your actions understandable. If a detail doesn't serve one of these purposes, cut it.

Context becomes more important for stories with emotional arcs: conflict stories, failures, and high-stakes situations where relationships and judgment are evaluated. In these narratives, seemingly minor details can help interviewers understand the interpersonal dynamics at play. When and where did critical conversations happen? Was it a heated exchange in a public meeting or a careful one-on-one discussion?

But even in these stories, the context serves the actions. You're providing just enough so the interviewer can appreciate what you did.

Pitfall #4: The "We" Disease

"We built a new caching layer." "We decided to go with Redis." "We shipped it in three weeks."

Who is "we"? What did YOU do? The interviewer is evaluating you and not your whole team. Every "we" is a missed opportunity to demonstrate some specific contribution.

This is one of the most common issues I see, and it's especially prevalent among candidates who genuinely work well in teams. They're so accustomed to thinking collectively and collaboratively that they describe their work collectively. But the interviewer needs evidence of your individual capabilities.

Instead of...	Try...
"We decided to use Redis"	"I proposed Redis because our read-to-write ratio was 100:1 and we needed sub-millisecond response times"
"We built a new service"	"I designed the service architecture, implemented the core endpoints, and wrote the integration tests"
"We shipped on time"	"I coordinated the release across three teams, managing the dependency chain and running the deploy"

You're not claiming you did everything alone, you're just being specific about what you did. The interviewer knows you worked with others, and you don't have to worry about coming across as arrogant.

Pitfall #5: Picking the Wrong Stories

Obviously, the interviewer only hears the stories that you tell them, so story selection matters a lot. Remember that when choosing a story, prioritize according to these criteria:

Scope first. Choose the project with the largest scope. This means breadth of actions you took (did you plan, execute, and resolve conflicts along the way?), timescale for the project, technical or organizational complexity, and impact on the business.

Relevance second. The story needs to match the question and deliver the requested signal. Remember this is a spectrum:

Great match: "Tell me about a time when you failed" → "My recommendation to rebuild our authentication system from scratch turned out to be wrong..."
Decent match: "Tell me about a time when you failed" → "I underestimated the complexity of integrating with a legacy system..."
Weak match: "Tell me about a time when you failed" → "Our sprint velocity was lower than planned..."

Uniqueness third. If you've already used a story in response to a previous question, consider whether to go back to it or cover new ground. A great interview is one where you've shared all the core stories that best represent your contributions. All else being equal, opt for the new story the listener hasn't heard.

Recency fourth. More recent stories carry more weight because they represent your current capabilities. A story from last year typically trumps one from five years ago, all else being equal.

There are some other common selection mistakes I see:

Scope mismatch: Don't choose a bug fixing story, unless it's a really hard bug fixing story, when you're interviewing for a senior role.
Too old: Stories from five years ago make the interviewer wonder what you've been doing since. For most candidates, stick to stories from 0-3 years ago.
Not your project: If your actual contribution was attending meetings and providing input, the interviewer will see through that.

Pitfall #6: Fairy Tale Endings

"We shipped on time, metrics improved across the board, stakeholders loved it, and everyone lived happily ever after."

Interviewers might hear this and think, "You must not have been very close to the action here, not close enough to see problems, or maybe you're hiding something, or maybe you're not aware enough to see the weaknesses."

Real projects have real problems, like bugs and collaboration issues. If you choose a story with genuine challenge, that will provide more signal than a smooth one. This is why the CARL format includes Learnings at the end, since they are a natural conclusion to the story, like Aesop's fables, and they provide you a platform for expressing depth.

Here are some ways to include real problems, which will make your stories more credible:

Include obstacles: "We hit a performance regression in staging that took a week to debug."

Include mistakes and recoveries: "I initially underestimated the cross-team dependencies, which caused a two-week delay. Once I recognized this, I set up daily syncs to catch issues earlier."

Include imperfections: "We shipped on time, but the test coverage wasn't where I wanted it. I added those tests in the following sprint."

And certainly when interviewers ask about weaknesses or failures, they're specifically looking for this kind of honest self-assessment. Choose mistakes that show skill growth rather than character flaws. Frame them as learning opportunities that led to better approaches.

The most compelling learnings show clear application to future situations. "This experience fundamentally changed how I approach X" is more powerful than "I learned that Y is important." Even better is when you can point to a subsequent project where you applied the learning.

Pitfall #7: Not Practicing

Candidates who know their stories on paper but haven't practiced them out loud consistently underperform candidates with slightly weaker experiences who've rehearsed. This is because the cognitive load of real-time storytelling is large, and practice closes the gap between what you mean to communicate and what actually comes out under pressure.

The signs of insufficient practice are obvious but fixable:

Stories that go long, like 5-6 minutes
Losing your place and backtracking
Tangential details because you haven't decided what to cut
Verbal fillers ("um," "like," "you know," "basically")
Pacing issues like rushing through important parts or lingering too long on setup

Review the practice article to learn about our suggested progressive practice approach, starting with by yourself and moving up to professional mocks.

Pitfalls by Signal Area

Responses that target each signal area tend to have their own common mistakes so let's review those.

Scope

Are the projects you're describing representative of your level?
What is the "so what" of this project? Can you articulate business outcomes and user impact?
Do you communicate the complexity? Number of teams involved, timeline, components affected.
Are you demonstrating the scope expected for your target role?

Ownership

Watch for passive language throughout your responses. Remember the "we" disease.
Are you showing bias for action, how you considered ways to quickly get started with whatever it was?
Are you describing how you measured results and why you wanted those particular metrics?

The difference between "I was asked to improve the search feature" and "I identified that our search was causing user drop-off and proposed a fix" is a huge difference in the level of proactivity demonstrated.

Perseverance

In your Context section, are you selling why the challenge was actually difficult? Were there time constraints, or technical challenges, or people challenges?
Show how the issue was discovered. Did it emerge mid-project? Were you the one to find it yourself?
Are you demonstrating sustained effort over time and not just quick wins?
Be sure to include follow-up actions you took to help prevent whatever challenge this was in the first place.

Ambiguity

Are you quantifying or sufficiently describing the ambiguity in the first place (scope uncertainty? technical unknowns? unclear success criteria?)
Show structured thinking (prototyping, stakeholder interviews, phased rollout)
Demonstrate course-correction as you learned more
Are there opportunities to highlight clarifying ambiguity for others, not just yourself?

Communication

Be sure to highlight methods and reasons for communication: was it verbal or written, who needed it, and what happened after?
Remember to demonstrate communication at multiple levels: across like with your peers, up like with your manager, and down if you had other ICs working under your direction.
When you tell a communication story, show that there was a two-way understanding: you checked comprehension or maybe you later gathered feedback and adapted.

Conflict Resolution

Choose a conflict reflective of your level: disagreeing with a peer is a lower level conflict than disagreeing with a partner team
Be sure the story describes how you were directly involved in resolving it. Don't describe conflicts you observed from the sidelines.
Show empathy. If you're making the other person look bad, the interviewer knows you're not being charitable.
As much as possible, frame the resolution of the conflict as a win-win.
Show the relationship afterward. Did you build respect and repair trust?

Growth

If the question is about a mistake, then share a real mistake, something you actually needed to learn. Not like, "I work too much".
When sharing a mistake, make sure it's not too obvious from the beginning what you should have done
Show you internalized the learning with specific behavior changes
Point to subsequent situations where you applied the learning

Leadership

Show how you influenced others and created conditions for them to do their best work
Demonstrate how you slowed down to think and created clarity when there was chaos or ambiguity
Are you mentioning how you mentored or developed other team members, through teaching code reviews, etc.?

Pitfalls for Senior Candidates

Senior candidates face additional challenges because their stories are richer and more complex, and also because the interviewers tend to scrutinize more closely.

Too Verbose

Senior candidates have rich, complex stories, but that means they are harder to tell in a short timeframe. Having richer stories is a good thing overall, but you have to decide what is actually useful for the interviewer to hear.

Use the Table of Contents structure to collect the actions into themes: "I contributed in three key ways: the technical architecture, the stakeholder alignment, and the team mentoring. Let me walk through each."
For each of the themes, prioritize telling the 3-4 most important actions
Include details only to establish credibility and once you've done that, keep moving with the story

Consider pausing after your Table of Contents to allow for questions. This helps avoid the sense that you're delivering a monologue.

Leaving Out Frameworks

Senior candidates describe what they did but often not how they thought about what they did, why they chose that path.

At Staff and above, the interviewer wants to know your process:

"I prioritized the work" → How? What framework?
"I made the technical decision" → What tradeoffs? What criteria?
"I mentored the junior engineer" → What approach? What techniques?

Example: "I prioritized the roadmap based on a combination of customer impact, engineering effort, and strategic alignment. I scored each initiative on those dimensions and presented the tradeoffs to leadership."

The interviewer wants evidence that you'll make good decisions in their organization too, not just that you made good choices in the past. At senior levels, your frameworks matter as much as your outcomes. The interviewer is assessing whether your decision-making process will transfer to their context.

Not Thinking Defensively

Interviewers for senior candidates are risk-averse since bringing in senior leaders to an organization is likely to have a wide impact across the product and team. Because of this risk aversion, interviewers are likely to fill any gaps in your narrative with negative assumptions about you or your actions.

Watch for statements that invite uncharitable interpretation:

You say...	Interviewer wonders...
"My manager assigned me this project"	Do you not seek out work yourself?
"It took me three months"	Is that reasonable? Did you consider alternatives?
"The codebase had no test coverage"	If you're senior enough to notice, why didn't you fix it?

To address this, either elide the problematic parts ("I took on this high-impact task") or proactively frame them ("The three months included building the feature-flagged migration path so we could ship incremental improvements to users every sprint").

Not Steering the Interview

The temptation in an interview is just to go with the flow of the questions and let the interviewer take you wherever they want to go. It's natural: they are making the hiring decision. But this is a mistake; it's actually your job as the candidate to guide the interviewer toward your most important stories and the most important parts of those stories.

Start in the TMAY: Mention a complex project in your "Tell Me About Yourself" and the interviewer will likely ask about it next. You just guided them toward your strongest material.
Breadcrumbs: Brief mentions of interesting sub-topics invite follow-up questions. "I also had to navigate some stakeholder concerns, but the key technical challenge was..." You've signaled there's a good conflict story available.
The menu technique: "I have two examples of conflict: one involving a technical architecture decision and one involving a cross-team alignment challenge. Which would be more useful?" Now the interviewer picks based on the signal they need.

Putting It Together

All these pitfalls can be overcome, most with simply noticing them or just a little practice on top of that. Go audit your stories and see which pitfalls to focus on.

Up next is our last article in this master class, focused on the different types of behavioral interviews you'll likely encounter in your process: from recruiter screens, to leadership interviews, to follow ups.

Mark as read

Next: Special Interview Types