Course
Select: Choosing Responses
Build a story catalog, learn the four-criteria selection framework (Scope, Relevance, Uniqueness, Recency), and master techniques for choosing the right story for any behavioral question.
Level:
0:00
/
17:59
You walk into a behavioral interview and the interviewer asks: "Tell me about a time when you disagreed with a cross-functional team member." Your mind races through a half-dozen possibilities. Which story do you pick? What if your best conflict story is from three years ago? What if you have two equally strong options?
And that's just one question. You might face ten questions in a single interview, and you won't know what they'll ask ahead of time.
Choosing the right story for a specific question means doing two distinct things: choosing available stories before the interview, and then picking the right one in the moment. Both require some kind of strategy, which is what this article is all about.
Why You Need a Story Catalog
Scrambling to think of examples on the spot costs you time and mental bandwidth you can't afford. Your working memory is already occupied with impression management, reading the interviewer's reactions, and structuring your responses clearly. Adding "search through my entire career history" to that cognitive load is a recipe for mediocre answers and a lot of stress.
The solution is obviously to identify stories in advance, to have them organized, and already mapped to signal areas so you can quickly identify the best story for any question.
Story Catalog
Your catalog should include two types of entries:
- Core stories represent your significant projects. These are the stories you'd most want to tell a hiring manager if you only had a few minutes. Each core story likely demonstrates multiple signal areas at once and represents the peak of your capabilities. Most candidates need 3 to 5 core stories.
- Additional stories fill in the gaps. Maybe your core stories are all about technical complexity, but you need examples of conflict resolution. Maybe they're all recent, but you want an older story that shows long-term impact. Additional stories give you coverage across all signal areas and provide variety when you've already used a core story. Aim for 5 to 7 additional stories.
Don't fixate on these story count numbers. The goal is confidence that you can respond to almost anything they throw at you.
Finding Your Core Stories Through Journaling
The best technique for surfacing your core stories is journaling, that is, reflecting on your career through writing.
Start by noting the biggest stories you already know you want to tell. Then use these categories to trigger your memory:
High-impact projects include major launches, significant refactors, system migrations, new product features, and architecture decisions that influenced multiple teams.
Challenging situations cover tight deadlines, organizational changes, technical failures, team or interpersonal conflicts, ambiguous requirements, and projects where success was uncertain.
Leadership moments are times when others looked to you for direction: mentoring others, driving cross-team initiatives, or representing your team externally.
Learning experiences include mistakes that led to growth, feedback that changed your approach, skills you developed under pressure, and times when you had to completely rethink your approach.
Career transitions encompass promotions, job changes, team switches, role expansions, and times when your responsibilities significantly evolved.
As you write about these categories, you'll notice certain projects keep appearing. Those are your core stories.
Research supports journaling as a way to help you remember more details and connections between events, crucial when you need to recall specific actions and outcomes from past projects. Journaling also provides mental health benefits by helping process experiences and emotions, making it easier to discuss challenging situations objectively in interviews. Interviewers tend to tune in to, and judge harshly, unprocessed emotions.
Core Story Examples at Each Level
In our coaching experience, sometimes it's helpful for candidates to see examples of what others share as stories in their behaviorals. Here are some common stories we hear for each level.
SWE I (New Grad)
- Building a small feature from design to deployment
- Fixing a critical production bug that required investigation across multiple services and coordination with senior engineers
- Automating a manual process that was taking the team hours each week
- Leading a capstone project in school that involved managing timelines and technical decisions
- Contributing to an open-source project by implementing a requested feature and navigating the code review process
SWE II
- Initiating, researching, planning, and executing a small project that lasted for a month
- Identifying, investigating, and resolving a performance bottleneck affecting many users
- Building tooling that reduced deployment time from hours to minutes across multiple engineering teams
Senior
- Leading the migration of a legacy system to a modern framework while coordinating with stakeholders and managing rollout risks
- Designing and implementing a new API that improved response times and became widely adopted by other teams
- Resolving complex technical debt that was blocking team velocity and required buy-in from leadership and careful sequencing
Staff
- Driving the technical strategy for a product area and influencing roadmap decisions across multiple quarters
- Leading the response to a major production incident while coordinating across dozens of engineers and establishing new reliability practices
- Designing and championing adoption of a platform that enabled other teams to ship features 50% faster
- Influencing company-wide architectural decisions
Senior Staff / Principal
- Leading a complete product pivot that required rebuilding team structure and technical architecture
- Scaling the people in an organization significantly while maintaining quality and culture
- Navigating a complex acquisition integration with merging teams and technology stacks
- Establishing engineering practices and culture that became the standard across the entire company
Many candidates from smaller or traditional companies worry their career stories lack the scale that interviewers at larger companies expect. These fears are generally misplaced. A skilled interviewer evaluates your potential based on the core signal areas, not simply the magnitude of your previous projects. The real challenge is articulating the complexity and impact in terms that resonate with your target audience. See our article on adapting your response to big tech expectations for an example of this.
Building a Story Catalog
Once you've identified your stories, capture them in a consistent structure. For each story, document:
Context covers the situation, your role, and why this mattered to the business. The most critical aspect of context is establishing the stakes. A feature that prevents customer churn carries different weight than a nice-to-have enhancement, and interviewers need to understand that distinction to properly evaluate the scope and impact of your work. Also capture the constraints you operated under, as they often reveal as much about your capabilities as your actions themselves.
Actions describe what you specifically did. Not "we." The interviewer is looking for evidence of your capabilities, so they care less about what happened and more about what you did to make it happen. Brainstorm all the moving parts: ideation, planning, approvals, architecture reviews, technical difficulties, testing, rollout, and follow-up actions. Include key inflection points that wouldn't have happened without you.
Think about actions across multiple dimensions:
- Designing (product and architectural decisions),
- Aligning (building consensus and managing stakeholders),
- Communicating (formal and informal ways you shared information),
- Implementing (direct technical execution),
- Iterating (improving based on feedback), and Releasing (deployment, monitoring, post-launch support).
- Even Thinking and Deciding are actions. The cognitive work you did represents valuable signal for interviewers.
Results demonstrate the impact of your actions. Quantifiable results are preferable: revenue generated, costs saved, performance improvements, user metrics like adoption rates or satisfaction scores, and team metrics like productivity gains or velocity improvements. But non-quantifiable results can also carry significant weight, especially for senior roles: increased personal or team scope, growth in people you developed, process improvements adopted by other teams, and cultural changes that extend beyond individual projects.
Learnings demonstrate your ability to reflect, grow, and apply wisdom to future situations. This is particularly important for senior roles where self-awareness and continuous improvement are key differentiators. Include technical learnings (new approaches or tools you adopted), process learnings (better project management or communication strategies), people learnings (insights about team dynamics or conflict resolution), and strategic learnings (understanding of business impact or organizational dynamics).
Signal Areas reference which of the 8 signal areas this story demonstrates, along with any company-specific values it covers.
Filling Coverage Gaps
After identifying your core stories, look at which signal areas they don't cover well. Go signal area by signal area and identify additional stories using these questions:
Scope: What's the largest project you've ever owned end-to-end? When did you take on work that was clearly above your level?
Ownership: When did you identify and solve a problem that wasn't technically your responsibility? Tell me about a time you followed something through to completion even when others had moved on.
Ambiguity: When did you have to move forward with incomplete or conflicting information? Describe a project where requirements kept changing.
Perseverance: When did you face a serious technical or organizational obstacle and have to find a way through? Tell me about a time you had to cancel or significantly change course on a project.
Conflict Resolution: When did you most strongly disagree with your manager or a teammate? When did you have to work effectively with someone who was difficult to work with?
Communication: When did you have to adapt your communication significantly for a non-technical audience? Tell me about a time when a miscommunication caused real problems.
Growth: What's the biggest mistake you've made, and what happened next? When did you receive critical feedback that changed how you work?
Leadership: When did you influence a decision without having authority over the people involved? Tell me about a time you helped a colleague grow or get unstuck on something important.
Ways to Help You Identify Stories
It can be hard to remember stories. Maybe they happened long ago or maybe they were so challenging you hoped never to think about them again. Here are some approaches to extract these experiences.
Leverage past career artifacts. Dig through performance reviews (especially self-reviews you wrote), resume drafts and LinkedIn profiles from different periods, calendars from significant projects, old presentations, technical documents, PRDs or RFCs, email threads from major projects or conflicts, code repositories with meaningful commit messages, and meeting notes or retrospective documents.
Map aspects of the past with others. Existing or former coworkers can be an encouraging resource to help you recall the past. Try interviewing them: "What project do you remember me being most involved in?" "What do you think I was particularly good at when we worked together?" "What's something I did that made a difference for the team?"
Use sensory memory triggers. These methods might seem unconventional, but they can unlock forgotten memories. Visit past work locations (or similar locations you have access to), eat food similar to your past office meals, listen to music you had playing during those periods, review photos from team events or office spaces, look through old conference swag or company merchandise, and page through technical books you referenced during projects.
Choosing Stories In the Interview
Once you're in the interview with a catalog in hand, you still need a process for picking the right story for each question. Prioritize according to four criteria, in this order:
Selection Criteria
1. Scope
Choose the story with the largest "box" you operated in. Scope means:
- Breadth of actions: Did you write code, or did you also plan, communicate, resolve conflicts, and measure impact?
- Timescale: A two-week sprint versus a year-long initiative.
- Complexity: Technical and organizational; did you coordinate across teams and competing priorities?
- Business impact: Did this move the needle on revenue, performance, user satisfaction, or team efficiency?
Don't save your best stories for some hypothetical later moment in the interview. Lead with them.
2. Relevance
The story must match the question and deliver the signal the interviewer is asking for. Priority should go to stories that naturally demonstrate the requested signal areas without requiring extensive explanation.
Consider relevance on a spectrum. If they ask "Tell me about a time when you failed," a strong match might be: "My recommendation to rebuild our authentication system from scratch turned out to be wrong, and we had to roll back after two months." A weak match would be: "Our sprint velocity was lower than planned for a quarter." The first is a clear failure with real consequences. The second is vague and doesn't demonstrate real ownership.
Also consider relevance to the specific company, role, and interviewer. If you're interviewing for a frontend role with a frontend engineer, a frontend-heavy story resonates more than a backend one, all else being equal.
3. Uniqueness
Prefer stories you haven't told yet in this interview.
This becomes more important as the interview progresses. Early on, lead with your absolute best stories regardless. Later, start factoring in whether you've demonstrated variety across different experiences.
A great interview is one where you've shared all the core stories that best represent your past contributions similar to the target role. All else being equal, opt for the new story the listener hasn't heard. If you have more than one new story to choose with sufficient scope and relevance, consider uniqueness across signal areas. If you've already told a technically complex story, you might choose an organizationally complex one.
Telling diverse stories demonstrates breadth of experience and makes you more memorable. But don't sacrifice scope or relevance just for variety. Your third-best conflict story isn't better than reusing your best technical story when the question is about conflict.
4. Recency
More recent stories carry more weight because they reflect your current capabilities.
This matters more if you're early in your career. Your skills are changing rapidly, so a story from last year is much more valuable than one from three years ago. If you're senior, you have more flexibility. A standout story from two years ago that demonstrates exceptional leadership can outweigh a more recent but less impressive example.
Be careful with stories from 3 to 5 years ago. You probably should avoid stories from 6+ years ago unless you are very senior (like VP or above) or there are extenuating circumstances (like career breaks).
Why This Priority Order Matters
This order exists because you have limited time in an interview, but have to balance that with the assessment goals of the interviewer.
Scope over Relevance might seem counterintuitive, but consider a question like "Tell me about your favorite project." You shouldn't answer according to personal affinity (like your favorite movie) but rather with a project that best represents your largest achievement. Even if another story is slightly more relevant to the literal question asked, your highest-scope story will provide the most valuable signal to the interviewer because it gives them the most insight into why to hire you.
For example, if the question was "Tell me about a time when you had a conflict with your manager," but all your disagreements with your actual manager were minor, you might choose the higher-stakes conflict with the product manager instead that shows your data-driven decision making. You still provide conflict resolution signal with positions of authority, but showcase more of your best repeatable actions.
Scope over Recency because interviewers are assessing the high-water mark of your capabilities. A project from two years ago that demonstrated significant technical leadership and business impact is more valuable than last month's straightforward feature implementation.
Relevance over Recency because a story that directly demonstrates the requested signal area, even if older, is better than a recent story that only tangentially relates.
Consider Uniqueness more as the interview progresses. Early in the interview, focus on scope and relevance. As you move through multiple questions, start factoring in whether you've already told certain stories or demonstrated certain capabilities.
The Menu Technique: When You Have Multiple Strong Options
If you're asked about conflict resolution and you have two good stories, offer the interviewer a choice:
"I could tell you about two different approaches I've taken to conflict resolution. One involved a disagreement with another engineering team about technical architecture, and another was about resource allocation with my manager. Which would be more useful for you to hear?"
This demonstrates you have multiple relevant examples, ensures you're giving them the signal they actually want, and gives you a moment to collect your thoughts. Don't overuse it. But when you genuinely have multiple strong options, it's a smart move.
When You Don't Have a Relevant Story
Try to get as close as possible to a story that's relevant to the question. If they ask about leading a major initiative but you've only ever contributed to large projects, tell that story and be honest about your role:
"While the senior engineer made the final decisions on architecture, I drove the proof-of-concept that informed our approach. Here's what I actually did..."
The interviewer is looking for repeatable behaviors, not just answers to their literal question.
If you truly have nothing, be honest and treat it like a hypothetical: "I haven't led a project of that scale yet, but here's how I would approach it based on my experience contributing to similar initiatives..."
Don't Lie
Never fabricate stories or embellish your role beyond what actually happened.
We understand the temptation. You're in an interview for your dream role and the interviewer asks about leading a major initiative, but you've only contributed to large projects, never led them. Or they ask about conflict resolution and the only disagreement you can remember feels too minor to mention. The pressure to have the "perfect" story for every question can push candidates toward exaggeration or outright invention.
Don't do it.
Lying damages your character. You will lose respect for yourself and create opportunities for impostor syndrome even if you get the job.
Lying is hard. Actors make it look easy but it probably won't be easy for you. You won't have the relevant details about your fabricated projects, and experienced interviewers notice when details get vague, timelines seem unrealistic, or when your confidence drops under probing.
Lying is risky. You could be rejected on principle or damage your reputation in the industry.
Instead of lying, reframe your contributions honestly:
| Don't say this... | Say this instead... |
|---|---|
| "I led the migration from our monolith to microservices, making all the key architectural decisions..." | "I drove the initial proof-of-concept for our microservices migration, which informed the broader team's architectural approach. While the senior engineer made the final decisions on service boundaries, I owned the evaluation of communication patterns and proposed the event-driven architecture we ultimately adopted..." |
| "I resolved a major conflict between engineering and product by convincing them to adopt my proposed solution..." | "When engineering and product disagreed about our approach, I gathered data on both options and facilitated a discussion where we could evaluate them objectively. This helped us reach consensus on a hybrid approach..." |
Personal and School Stories
Always prefer work stories, but if you really don't have one as a junior candidate, academic projects can demonstrate the same behaviors as workplace projects. Look for experiences where you took initiative, solved complex problems, or worked with others to achieve meaningful outcomes.
Personal stories are acceptable, again only for junior candidates, as long as they demonstrate professional behaviors: leadership, problem-solving, collaboration. Avoid overly personal topics and focus on situations that translate to workplace skills.
Responding to Values Questions
Questions like "What is your approach to cross-team communication" are not the same as "Tell me about a time..." questions. These values questions require you to demonstrate a generalized framework for addressing a common work situation. Your maturity in articulating and justifying this approach will weigh heavily on the listener's view of your scope.
These frameworks don't have to be formal or have officially recognized names. For example, you might respond to the cross-team communication question with a three-layer framework:
- Layer 1: tight-loop communication with teams you directly depend on or who depend on you
- Layer 2: structured touchpoints with adjacent teams who might be affected by your work or whose work might affect you
- Layer 3: broadcast communication for the broader organization
When you provide a framework like this, you immediately answer the question asked but also demonstrate systematic thinking.
Coming up with a framework on the fly: When caught off-guard by a values question, take 5 seconds to quickly construct a credible framework by asking yourself: What varies? (Is it the stakeholders, the time, the resources, the risk?) Pick 2 to 3 variations but don't over-complicate it. Name your approach for each variation. Add one insight about when to use each one.
Common framework patterns include:
- For communication: Segment by frequency vs. formality (ad-hoc, regular, formal)
- For prioritization: Use impact vs. effort or customer value vs. technical risk
- For conflict: Scale by stakes (low, medium, bet-the-company)
- For quality: Balance by constraints (speed/quality/scope triangle)
Always share an example immediately after presenting your framework. Do this even if you just came up with the framework on the fly. You're not lying; you just formalized it after you used it.
Responding to Hypothetical Questions
Questions like "What would you do if a project was behind schedule" are similar to values questions. While you may not have faced the exact scenario, you've likely faced the same category of problem.
Choose clarifying questions carefully. Select 1 to 2 questions based on what would genuinely change your approach to the problem. Good questions show you understand nuance ("Is this a B2B or B2C product?" when asked about feature prioritization), reveal critical constraints ("Do I have hiring authority?" when asked about scaling a team), or identify stakeholder dynamics ("Who are the key decision makers?" when asked about driving consensus).
Poor questions are too basic ("What do you mean by 'difficult'?"), too numerous (asking 5+ questions before providing any value), or too deflecting ("Well, what would you do?").
Build a framework using pattern-matching: Abstract the core challenge (project behind schedule becomes resource/time/scope tension), scan your experience for similar tensions (deadline pressures, resource constraints, stakeholder disappointments), and extract the transferable principles (what worked, what failed, what you'd do differently).
Then ground the conversation by sharing a story from your career related to the hypothetical situation, using the same story selection criteria we've discussed.
Exercise: Build Your Story Catalog
Before moving on:
-
Journal through your career using the category prompts above (high-impact projects, challenging situations, leadership moments, learning experiences, career transitions). Identify 3 to 5 core stories.
-
Fill out the story catalog worksheet for each core story. Capture Context, Actions, Results, Learnings, and Signal Areas. You're not writing a full interview answer. Just capture enough to remember what the story is and what signal it covers.
-
Identify your gaps. Review which signal areas your core stories don't cover. Use the per-signal-area journaling questions above to find 5 to 7 additional stories that fill those gaps.
At the end of this exercise, you should have a catalog you can actually reference during your prep and eventually in the interview itself.
What's Next
Now that you have a catalog of stories, the next article how to actually tell those stories in a way that's compelling and signal-rich.
You'll learn the CARL framework (Context, Actions, Results, Learnings): how much context to include, how to describe your actions so they demonstrate repeatable behaviors, how to quantify results even when you don't have exact metrics, and what learnings actually signal growth versus stating the obvious.
Mark as read