Build your behavioral story bank¶

For anyone with a behavioral round in the next 2 to 6 weeks. You finish with 8 to 10 written stories, a grid that shows which story answers which question, and a story picked for each of the 50 most common questions.

How many stories you need¶

Source	Number	What they say
interviewing.io (Gilad Naor)	Brainstorm 20 to 30, keep 8 to 10	Filter hard, keep the stories that show your target level
Amazon's STAR worksheet	List 10 to 15 significant moments	Not covering all 16 principles is expected
Jugal's Amazon roadmap	6 to 7 rock-solid stories	Map each one to 2 to 3 Leadership Principles and keep a cheat sheet
Tech Interview Handbook	3 to 5 core projects	Most questions get answered from a few key projects
Google's old interview page (archived 2020)	Three answers per likely question	Have another story ready so the next interviewer hears something new

Target 8 to 10, with Jugal's 6 to 7 as the floor. Below that you will repeat stories: an Amazon loop is four to six interviews (About Amazon), each with 2 or 3 behavioral questions. Above 12, you will not get each story to the 10 out-loud run-throughs it needs.

Step 1: Brainstorm 20 to 30 moments¶

Write one line per moment and do not judge yet. Stop at 20 lines minimum. Use your resume as the trigger, newest first (Amazon worksheet).

Where to look	Stories it usually gives you
Internship or job	A production bug, a deadline, a code review disagreement, work you took on without being asked
Class or capstone project	Teammate conflict, scope cuts, a technical decision with trade-offs
TA or tutoring	Helping someone struggling, explaining hard ideas simply, fixing a broken process
Hackathon	Pressure, decisions without data, leading peers with no title
Open source	Taking hard feedback from maintainers, learning a codebase fast, persuading strangers
Research	Ambiguity, a failed approach, digging into data
Clubs and events	Motivating a group, a missed goal, organizing without authority
Part-time jobs (any kind)	A difficult customer, doing more with less, putting the customer first

Find receipts while you brainstorm: old emails, chat messages, pull requests, design docs, review comments, grade sheets, app analytics. Gilad Naor at interviewing.io calls these your evidence.

Tip: Start a work log today: one dated line per bug, review, or decision, with the result.

Jugal's version for AI work: "Keep a simple doc called 'prompt log.' Write the change you made and whether it helped. After 30 days, you have 30 experiments you can talk about in an interview." (AI Engineering 101)

Step 2: Score each moment and filter¶

Score every moment from 1 to 3 on Steve Huynh's four dimensions (Pragmatic Engineer).

Dimension	1 point	2 points	3 points
Scope	Only my own task	Helped my team or a group of users	Affected another team or many users
Contribution	I helped	I owned a clear part	I drove it from start to finish
Impact	No visible result	Result, no number	Result with a number
Difficulty	Nothing hard happened	One obstacle	Real constraint, trade-off, or conflict

Drop any moment where your own contribution is unclear.
Drop any moment where nothing hard happened.
Sort the rest by total score.
Break ties in this order: highest scope, most relevant to the job, most unique, most recent (Hello Interview). Amazon also asks for recent examples (Amazon phone screen).
Keep the top 8 to 10, then check coverage in step 3.

Step 3: Cover the must-have story types¶

Your 8 to 10 stories together must cover every line below. One story can cover several.

Step 4: Fill the mapping grid¶

Put stories in columns and question themes in rows. This is the interview preparation grid from Gayle Laakmann McDowell's Cracking the Coding Interview, also in awesome-behavioral-interviews and as a Notion template.

Rule: every row needs at least 2 stories. Every story should fill at least 3 rows.

Example grid for one student's 8 stories (a composite, not a real person):

Theme	A: Flaky CI tests (internship)	B: Campus app, 400 users (capstone)	C: Hackathon scope cut	D: Autograder for 300 students (TA)	E: Open-source PR redesign	F: Club launch missed	G: Spreadsheet automation (part-time job)	H: Research result did not replicate
Proudest project	x	x		x
Hardest technical problem	x							x
Failure or missed goal						x		x
Conflict with a peer			x			x
Disagreed with someone senior	x				x
Tight deadline or pressure	x		x
Ambiguous requirements		x					x	x
Decision without full data		x	x
Initiative outside scope	x			x			x
Led without the title			x	x		x
Learned something fast					x		x	x
Critical feedback received					x	x
Helped or mentored someone		x		x
User or customer first		x		x			x
Simplified a process	x			x			x
What I would do differently			x			x		x

Blank copy for your own notes:

| Theme                          | S1 | S2 | S3 | S4 | S5 | S6 | S7 | S8 | S9 | S10 |
|--------------------------------|----|----|----|----|----|----|----|----|----|-----|
| Proudest project               |    |    |    |    |    |    |    |    |    |     |
| Hardest technical problem      |    |    |    |    |    |    |    |    |    |     |
| Failure or missed goal         |    |    |    |    |    |    |    |    |    |     |
| Conflict with a peer           |    |    |    |    |    |    |    |    |    |     |
| Disagreed with someone senior  |    |    |    |    |    |    |    |    |    |     |
| Tight deadline or pressure     |    |    |    |    |    |    |    |    |    |     |
| Ambiguous requirements         |    |    |    |    |    |    |    |    |    |     |
| Decision without full data     |    |    |    |    |    |    |    |    |    |     |
| Initiative outside scope       |    |    |    |    |    |    |    |    |    |     |
| Led without the title          |    |    |    |    |    |    |    |    |    |     |
| Learned something fast         |    |    |    |    |    |    |    |    |    |     |
| Critical feedback received     |    |    |    |    |    |    |    |    |    |     |
| Helped or mentored someone     |    |    |    |    |    |    |    |    |    |     |
| User or customer first         |    |    |    |    |    |    |    |    |    |     |
| Simplified a process           |    |    |    |    |    |    |    |    |    |     |
| What I would do differently    |    |    |    |    |    |    |    |    |    |     |
Rule: 2+ stories per row. 3+ rows per story.

Then map the same stories to your company's values: the Amazon LP map or the Google attributes.

Step 5: Write each story on a card¶

One card per story. Bullets, not paragraphs. You memorize the bullets, not the sentences.

STORY [#]: [Title that teases the challenge and the number]
When / where / my role: [Month Year], [company, course, or club], [your title]

Situation (1 to 2 sentences, include the stakes):
  [What was broken or at risk, with a number. What happens if nobody acts.]
Task (what I owned, how success was measured):
  [My piece. The goal as a number or a date.]
Actions (3 to 5 bullets, every one starts with "I"):
  - I [verb] [what] because [why].
  - I [verb] [what].
  - I [convinced / disagreed with / escalated to] [who] using [data].
Obstacle or trade-off: [The hardest part and what I gave up.]
Result (numbers): [Metric before] to [metric after] in [time]. [Who benefited.]
Learning: [One sentence.] Used again on: [later project].

Scope: [just me / my team / another team]
Maps to: Amazon LPs [2 or 3]. Google attributes [ambiguity / feedback / user first /
  team / leading without the title / data].
Follow-ups I expect:
  - Why not [obvious alternative]?
  - What exactly did you do, versus the team?
  - How did you measure that?
  - What did the other person say?
  - What would you do differently?

Questions to answer before you write, adapted from Amazon's official worksheet:

Situation: Where and when was this? What was the goal?
Task:      What was my role? Why did it matter? What was the risk if nothing happened?
Action:    What did I personally own? How did I change the outcome?
           Who else was involved? What was the biggest obstacle?
Result:    How did I measure success? What were the numbers?
           What trade-offs did I make? What would I do differently?

Templates for the hardest stories¶

Failure, built on CARL and IGotAnOffer's rules (a real miss with consequences, not a typo, not someone else's fault, not reckless):

Context (under 30 s): In [when], I was [role] on [project].
  The goal was [goal], and [stakes].
The miss (1 sentence, owned): I missed it because I [your decision or gap].
Recovery (most of your time): First I [contained the damage].
  Then I told [who] on [when]. Then I [fixed the root cause].
Result: [What was recovered, in numbers]. The original goal was
  [met late / partly met / not met].
Learning and proof: Since then I always [new habit].
  On [later project], that meant [result].

Conflict: interviewing.io warns against conflict stories that turn into an argument about who was technically right (interviewing.io). Short on conflict stories? Austen McDonald lists the kinds that work in Conflict Stories 1 of 5.

Context (20 s): [Project], [who], [the decision on the table], [deadline or stakes].
Their view, stated fairly: [Person] wanted [A] because [their good reason].
My view: I wanted [B] because [data or reason].
What I did: I [asked questions / ran a quick test / wrote both options
  with trade-offs] and [who made the call].
Decision: We went with [A, B, or a mix]. If it was not my option,
  I committed by [concrete action].
Result: [Outcome in numbers]. After: [how we worked together next].
Learning: [One sentence].

Changed your mind, a common Google and Amazon (Are Right, A Lot) question. Jugal's format: "what you believed, the specific evidence that changed it, and what you do differently now" (OpenAI campus lead post).

Belief: I used to think [view] about [topic], because [reason].
Evidence: Then [specific data, test result, or person's argument] showed [what].
Now: I [what you do differently], for example on [later project or task].

Step 6: Add a number to every story¶

Count something. Compare before and after. Say "roughly" for estimates (Hello Interview, interviewing.io).

What to count	Example line
Users or testers	About 400 students used it in the first month
Time saved	Grading went from about 6 hours to 40 minutes per assignment
Speed	Page load went from 3.1 seconds to 1.2 seconds
Errors and bugs	Flaky test failures went from about 20% of runs to under 2%
Scale	Processed about 50,000 rows a night
Adoption	Maintainers merged it; 3 other teams copied the script
Ranking or grade	Top 5 of 60 teams
Cost	Stayed on the free tier, about $40 a month saved

Jugal's rule for resume numbers applies here too: "If somebody asks you about that number in an interview, you need to be able to explain it." (I Asked Claude to Make My Resume Unrejectable). More ideas: metrics when you have none.

Step 7: Title each story¶

A title that teases the challenge and the evidence helps you recall the right story in two seconds (interviewing.io).

Weak title	Strong title
Internship project	The 9 flaky tests that cost my team an hour a day
TA work	Rewriting the autograder for 300 students in 2 weeks
Hackathon	Cutting half our features at hour 20 and still placing top 5
Club	The launch I missed by 3 weeks, and the plan I use now

Worked example: weak vs strong¶

The question: "Tell me about a time you solved a problem nobody asked you to solve." The story is a composite example, not a real person. Copy the structure, not the facts.

Weak version (about 30 seconds)¶

So in my internship we had a lot of issues with our tests. They were really slow
and flaky, which was annoying for everyone. We decided to look into it and we found
some problems with how the tests were set up. We fixed a bunch of things and made
the pipeline faster. In the end the team was really happy and it was a great
learning experience. I learned a lot about CI/CD.

Strong version (about 2.5 minutes, STAR plus Learning)¶

SITUATION
Last summer I interned on a 6-person payments team. Our CI pipeline took about
40 minutes per merge, and roughly 1 in 5 runs failed on tests that passed on retry.
Engineers re-ran builds 2 or 3 times a day, and a release had slipped by a day
the week before.

TASK
My intern project was a reporting feature, not CI. But I was losing about an hour
a day to reruns, so I asked my manager for 2 days to measure the problem. She agreed,
as long as my feature stayed on schedule.

ACTION
I pulled 3 weeks of CI history, about 600 runs, into a spreadsheet and grouped the
failures by test. 9 tests caused about 80% of the flaky failures.
I reproduced each one locally. Six shared one root cause: they used the real clock
and a shared test database, so they collided when they ran in parallel.
I posted two options in the team channel: quarantine the 9 tests, or fix the shared
setup. The tech lead wanted quarantine only, because the release was close.
I disagreed, because quarantined tests hide real bugs. I proposed both: quarantine
that day, and I would fix the setup within the sprint, with a date he could hold
me to. He agreed.
I wrote a fake clock and a separate database schema per test, got two reviews, and
fixed the other 3 tests one at a time. I also added a weekly dashboard of the flaky
rate so it stayed visible after I left.

RESULT
Over the next 4 weeks, flaky failures went from about 20% of runs to under 2%.
Median pipeline time dropped from 40 to 24 minutes because we stopped retrying.
My reporting feature still shipped on the original date, and the team kept the
dashboard after my internship.

LEARNING
I learned to measure before I propose a fix. My first guess was the build cache,
and the data said no. Now I collect failures in one place before I debug anything,
and I did the same when login errors spiked in my capstone app.

What changed¶

Problem in the weak version	Fix in the strong version
"We" hides the candidate (4 times)	Every action starts with "I"
No stakes	A slipped release and an hour a day lost
No numbers	40 to 24 minutes, 20% to under 2%, 600 runs, 9 tests
No ownership signal	Not her project; she asked for time and kept her own deadline
No conflict	Disagreed with the tech lead, proposed a middle path, committed to a date
Vague action	Measure, reproduce, root cause, options, fix, guardrail
Generic learning	One specific lesson, then proof it was used again

One story, many questions¶

Change which part you expand. Keep the facts the same.

Question	Lead with	Spend the most time on
Tell me about a time you disagreed with someone senior.	The quarantine debate	How you proposed both options and committed to a date
What is the hardest bug you fixed?	The 9 tests	Reproducing locally and finding the clock and database root cause
Tell me about work outside your scope.	It was not your project	Asking your manager, protecting your own deadline
Tell me about a decision you made with data.	600 runs in a spreadsheet	How the data killed your first guess
Tell me about raising the quality bar.	Refusing quarantine-only	The fix plus the dashboard
Tell me about a tight deadline.	The release date	Shipping your feature on time while fixing CI

Amazon principles this story shows: Ownership, Dive Deep, Have Backbone; Disagree and Commit, Insist on the Highest Standards, Deliver Results. Google attributes: data, respectfully challenging the status quo, caring about the team.

Jugal's example¶

Jugal's Amazon roadmap uses this example to show how one story covers several principles (Your 6-Week Amazon Interview Roadmap):

Situation: "Our checkout system was failing for 15% of gift card purchases during
Black Friday week."
Task: "I was the junior dev, but I owned this service, and customer support was
drowning in tickets."
Action: "I spent two days instrumenting every error path. Built a tracking system.
Reproduced 12 edge cases. Got my seniors to review my fix. Shipped it. Added alarms
so it never happens again."
Result: "P95 checkout errors dropped 42%. Support tickets down 38%. NPS score climbed
back up over the next month."

His note: "See how that hits Customer Obsession, Bias for Action, AND Ownership? One story, multiple principles."

The 50 most common questions, by theme¶

Deduplicated from the Tech Interview Handbook, awesome-behavioral-interviews, IGotAnOffer, Amazon's interview pages, Google's interview tips, Hello Interview, interviewing.io, PracHub, and Jugal's posts. The "use this story" column points to the story types in step 3.

Do this: copy the tables into your notes and add the title of your own story to every row. A blank row means you need another story, or the bridge script for that question.

Introduction and motivation¶

#	Question	Use this story	They are checking
1	Tell me about yourself.	Your 60 to 90 second pitch (template)	Clear, relevant summary
2	Why this company?	Specific product or team, plus your matching proof	Real interest, research
3	What are your strengths and weaknesses? What gets criticized in your work?	Feedback received	Self-awareness
4	Where do you see yourself in 5 years? What do you want next?	None; a short, honest goal tied to the role	Motivation, fit
5	Why are you leaving your current company or internship?	None; forward-looking reasons	No negativity
6	What words would your colleagues use to describe you?	Pick 2 words, one quick example each	Self-awareness
7	What questions do you have for me?	3 prepared questions (list)	Curiosity

Projects and technical depth¶

#	Question	Use this story	They are checking
8	Tell me about the project you are most proud of.	Proudest project	Scope, ownership, impact
9	Tell me about your most challenging project.	Proudest project or hardest problem	Difficulty, perseverance
10	What was the most difficult bug you fixed?	Hardest technical problem	Depth, debugging method
11	Tell me about a project you owned end to end.	Proudest project	Ownership
12	Tell me about a problem with several possible solutions. How did you choose?	Hardest problem or data decision	Judgment, trade-offs
13	Tell me about a complex problem you solved with a simple solution.	Process fix or hardest problem	Simplicity
14	Explain a technical concept to a non-technical person.	Helping or mentoring	Communication
15	How do you stay current with technology?	Learning fast	Curiosity

Failure and mistakes¶

#	Question	Use this story	They are checking
16	Tell me about a time you failed. What did you learn?	Failure	Accountability, growth
17	Tell me about a time you took a risk or made a mistake.	Failure or data decision	Judgment, honesty
18	Tell me about a project that did not go to plan.	Failure	Recovery
19	What would you do differently on a past project?	Failure or proudest project	Reflection
20	Tell me about a time you missed a deadline.	Failure or deadline	Ownership, communication

Conflict and disagreement¶

#	Question	Use this story	They are checking
21	Tell me about a conflict with a teammate.	Peer conflict	Resolution, respect
22	Tell me about a time you disagreed with your manager.	Disagreement with someone senior	Backbone with data
23	Tell me about a conflict where you had to influence someone.	Peer conflict or senior disagreement	Influence without authority
24	Describe working with a difficult team member.	Peer conflict	Empathy, no blame
25	Tell me about committing to a decision you disagreed with.	Disagreement with someone senior	Commitment after debate

Deadlines, pressure, and priorities¶

#	Question	Use this story	They are checking
26	Tell me about a time you met a tight deadline.	Deadline	Delivery, scope choices
27	How do you prioritize competing tasks?	Deadline	Prioritization method
28	Tell me about working under pressure or a heavy workload.	Deadline	Composure
29	Tell me about something you persevered at for months.	Proudest project or learning fast	Perseverance

Ambiguity and judgment¶

#	Question	Use this story	They are checking
30	Tell me about a decision you made without complete information.	Ambiguity	Calculated risk
31	How have you used data to make a decision?	Data decision	Evidence over opinion
32	Tell me about a time requirements were unclear or kept changing.	Ambiguity	Creating structure
33	Tell me about a time you had to pivot or adapt to a big change.	Ambiguity or failure	Adaptability
34	Tell me about a problem you anticipated and prevented.	Initiative or hardest problem	Foresight
35	Tell me about trading a short-term gain for a long-term goal.	Initiative or proudest project	Long-term thinking

Ownership and initiative¶

#	Question	Use this story	They are checking
36	Tell me about a time you took ownership of something outside your scope.	Initiative	Ownership
37	When did you go above and beyond?	Initiative or user first	Drive
38	Tell me about a process you improved.	Initiative	Simplify, measurable change
39	Tell me about a time you challenged the status quo.	Disagreement or initiative	Courage with tact

Leadership and teamwork¶

#	Question	Use this story	They are checking
40	Describe a time you took the lead on a project.	Leading without the title	Initiative, organizing people
41	Tell me about a time you led without formal authority.	Leading without the title	Influence
42	How did you motivate a group or encourage collaboration?	Leading without the title	Team building
43	Tell me about helping a struggling teammate or mentoring someone.	Helping or mentoring	Empathy, coaching
44	Tell me about working with another team or department.	Proudest project or peer conflict	Cross-team communication

Learning and feedback¶

#	Question	Use this story	They are checking
45	Tell me about critical feedback you received and what you did.	Feedback received	Humility, change
46	Tell me about a time you gave someone difficult feedback.	Helping or peer conflict	Candor with care
47	Tell me about a time you learned something quickly.	Learning fast	Learning method
48	What is something new you learned recently?	Learning fast	Curiosity

Users and quality¶

#	Question	Use this story	They are checking
49	Tell me about a difficult customer or user.	User first	Empathy, problem solving
50	Tell me about a time you put the user first or pushed back for the user.	User first	User focus

Tip: Google's old careers page told candidates to write down the top 20 likely questions and three answers for each, so the next interviewer hears a different story (archived Google page). Do that for questions 8, 16, 21, 22, 26, 30, and 36.

Rehearse until it sounds natural¶

Read a card once, then put it away. Tell the story out loud and time it against a 2 to 3 minute target.
Record it on your phone and listen once. Mark every "we", every filler word, and every missing number.
Run the follow-up drill: a friend or an AI asks five follow-ups per story (why, what exactly did you do, what was the alternative, how did you measure it, what would you change). At Amazon, one point can be probed for 10 to 15 minutes (interviewing.io).
Tell it to a person and ask them to repeat your result back. If they can't, your result is not clear.
Repeat until each story has been told about 10 times. Jugal: "By the tenth time, they'll sound natural." (Your 6-Week Amazon Interview Roadmap)
The day before, read only the titles. Recall each story from its title.

Keep every story true¶

Jugal's test: "When have I actually done this?" Not "when could I twist a story to fit this". (Your 6-Week Amazon Interview Roadmap)
Interviewers probe details. A made-up story falls apart on the third follow-up.
Small and real beats big and invented. Junior scope is expected (Tech Interview Handbook).
No story fits? Use the bridge script on How behavioral interviews work.

Resources¶

Amazon Leadership Principles STAR worksheet (PDF): Amazon's official 4-page story worksheet. How to use it: fill it before any Amazon round; it works for other companies too.
interviewing.io: Stop memorizing STAR: brainstorm, scope, evidence, filter, title. How to use it: follow it for steps 1 to 7 above.
awesome-behavioral-interviews: prep grid image, 51 questions with sample answers. How to use it: copy the grid; use the questions for drills. The sample answers are generic (one claims "over five years of experience"), so never reuse them.
Behavioral Interview Preparation Grid (Notion): duplicable grid. How to use it: duplicate it and fill one column per story.
Byte by Byte: behavioral interviews: grid-first method with short answers. How to use it: read its first three steps.
Andrew Yeung: Your behavioral story bank: spreadsheet method for a large story library. How to use it: optional, if you prefer a spreadsheet.
IGotAnOffer: Tell me about a time you failed: 5 rules and example answers, including student and fresher examples. How to use it: compare your failure story to the student example.
Tech Interview Handbook: behavioral rubrics: example answers by level. How to use it: check each card against the junior example.
Why Smart Candidates Still Fail FAANG Interviews: Jugal's 60 company questions (15 each for Amazon, Google, Meta and Apple) with what each answer should show, first published in Behavioral Interview Preparation. How to use it: add every question to your grid as a row check.

Next: Amazon Leadership Principles