Select - Choosing A Response

Why you need story catalog

To choose the story efficiently. We need

3-5 core stories:
- These are the one where we want to bring out first, hitting multiple signal areas
- These are the one if we have only a few minutes we wanna say
5-7 alternative stories
- To cover some additional signal areas if we used all our core story

[!note]
The goal is to be able to response to anything they throw at you so if you need more story, prepare more

Finding core stories through journaling

This is how you are going to find and form your story.

First go through the key points here, list out all the possible experiences that you had with it

Key point	Example
High impacts projects	Major feature launch, significant refactor, system migrations architecture descisions that impact/influence mutlple teams
Chellenging situation	Tight deadlines, organisational change, technical failures, team or interpersonal conflicts, ambiguous requirements, project where success was uncertain
Leadership moments	Mentoring others, driving cross-team initiatives, representing your team externally
Learning experiences	Mistakes that led to growth, feedback that changed your approach, skills you developed under pressure, times you had to completely rethink your approach
Career transtions	Promotions, job changes, team switch, role expansions, responsiblity significantly evolved

Core story example

SWE II:

Research, planning, and executing small project that lasted for a month
Identify, investigating and resolving a performance bottleneck affecting many users
Building tooling that reduced deployment time from hours to minutes across multiple engineer team

Senior

Lead some project or migraiton while coordinating with stakeholders and managing rollout risks
Design or implement something that widely adopted by other team
Resolve complex technical debt that was blocking team velocity, required buy-in from leadership and careful sequencing

Building story catalog

Once you listed out the experience from previous step, you will build the story in the following format

Part	What include
Context	Situation, role, why it matters to the business. A feature that prevent customer churn carry different weight to "nice-to-have" enhancement. Interviewer need to understand that scope
Actions	Describe what you did, not "we". All the parts including: brainstorm, planning, approvals, architect review, testing, roll out, follow-up actions. This include communicating, iterating( feedback) even thinking and deciding
Result	Impact of your actions, quantifiable results are preferable. If it's non-quantifiable, we prefer for senior: increased personal or team scope, growth in the people, adopted by other team, culture changes…
Learnings	Ability to reflect, grow, apply wisdom to future situations. This includes technical learnings (new approaches or tools adopted), process learning (better project management or communication strategy) and strategic leanrings
Signal areas	Which of the 8 signal areas this land on

Building additional story

These additional story we should focus on 1 signal area at a time, it can hits mutliple signal areas as well but it should be mainly for one signal areas. This is mainly for something like describe a time where you have a conflict etc.

Signal area	Example
Scope	Largest project you have owned end-to-end? When you take on work that was clearly above your level
Ownership	Solve a problem that not your responsibility? A time you followed through the end even though others have moved on
Ambiguity	A project where requirement keeps changing? When do you have to move forward with incomplete or conflicting information
Perseverance	When did you face a technical or organizational obstacle and have to find a way through? Tell me a bout a time you had to cancel or significantly change course on a project
Conflict resolution	A time when you strongly disagree with manager or teammate? A time when you have to work with difficult teammate
Communication	A time when you have to communicate to non-technical audience? A time when miscommunication caused real problem
Growth	Biggest mistake you have made, what happen next? Receive a critical feedback that changed how you work?
Leadership	When you influence a decision without having authority over people involved? Tell me about a time when you helped a colleague grow or get unstuck on something important

Ways to help identify story

Look through email threads, calendar, past convo etc
Interview existing or past coworkers
Visit past work location, view team photo to remember back the time.

Choosing stories in the interview

Criteria needs to go as follow order

Order

1. Scope

Choose the largest box you operate in

Breadth of action: Did you write code, did you also plan, communicate, resolve conflicts and measure impacts?
Timescale: two week vs a year long
Complexity: Technical complexity or organisational that needs cross team collaboration
Business impact: any revenue, performance, team efficiency?

Dont save your best stories for hypothetical later moment, lead with them.

2. Relevant

The story needs to match the question. For example:

Tell me about a time when you failed

Strong match: My recommendation to rebuild our authentication system from scratch turned out to be wrong, and we had to roll back after two months
Weak match: Our sprint velocity was lower than planned for a quarter

The reason is the second one there is no real ownership

3. Uniqueness

Choose the story you haven't tell if you can.

Normally, share all the core stories that check all the box and hits all signal areas, and then we can share new story the person has not heard

However, dont sacrifice scope just for variety — re-use your best story if your third-best conflict story has less scope

4. Recency

A recent story matter more than an old story. You can fall back to an old story but it's less impressive.

Avoid 6+ years ago story unless you're like VP and above

Why this order?

Scope > Relevance:

A bit counter-intuitive but for example the question of "Tell me about your favorite project". Answering with the one with most scope is much better than the one that you like the most since it gives more valuable signal

For example:

Tell me about a time when you had a conflict with your manager — all your disgreements with your actual manager were minor, you might choose the higher-stakes conflict with product manager instead.

Scope > recency:

A project of 2 years ago that demonstrated significant leadership is more valuable than last months

Relevance > recency:

Even if something relevant, if it's older it's better than the recent one that only slightly related

[!important]
Only consider uniqueness later on as the interview progresses
In the beginning, just focus on scope and relevance, later on you can check if you told a certain stories or not

If same question, e.g conflict resoultion, and you have 2 good scenario, offer which one they want to hear

"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 ensure you're giving them the signal they actually want.

However dont over use it, only use when genuinely both are strong

When you dont have relevant story

Get as close as possible. For example, if they ask about leading a mjaor initiative but you've not ever contributed to a large project, you can be honest

"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..."

Since they're looking for behavior, not literal answer their question

If you truly have nothing, treat it like 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

Lying is not easy, risky and damage your character/reputation.

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..."

TLDR: Don't claim a sole ownership if you dont do it. Explain what your contribution is.

Responding to values question

Values questions are for example:

What's ur approach to using AI?
How do you prioritise features?

For this one, provide a framework then an example — framework shows systematic thinking. Example will explain the framework.