The STAR Method and Your Story Bank

You can answer a hundred behavioural questions with eight stories. That sounds too good to be true, but it is how most prepared people do it. They do not memorise a hundred answers. They know a few real stories so well that they can bend each one to fit a different question.

This note does two things. It teaches the STAR shape, which keeps a story from wandering. Then it walks you through building your own bank of stories, with a worksheet to fill in.

STAR in plain words

STAR is four letters. Each one is a part of the story.

• Situation: where were you, and what was going on?
• Task: what was your job in that moment? What did someone expect from you?
• Action: what did you do, step by step?
• Result: what changed because of it?

Picture a friend telling you about the day their scooter broke down. If they tell it well, you hear: the scooter stopped on a bridge (situation), they had to reach the station in twenty minutes (task), they pushed it to a mechanic and borrowed a neighbour's bike (action), they caught the train with two minutes left (result). You never get lost.

If they tell it badly, they spend five minutes on the weather, what they had for breakfast and how old the scooter is. Then they say, "Anyway, I made it." You nod politely and stop listening.

STAR is just the good version of telling a story. Nothing fancy.

The honest fix: most people get the weights wrong

Here is the mistake almost everyone makes. They spend most of the time on Situation, because it is the easy part. It is just background, and background feels safe. Then they rush the Action and skip the Result.

The interviewer needs the opposite. Situation should be short. Action and Result are what get written in the notes.

A rough split for a two minute answer:

If you notice that you are still describing the company, the team, and the tech stack after thirty seconds, stop. Jump to what you did.

The second mistake is to skip numbers. A result like "it was much better" tells the interviewer nothing. A result like "the page load went from about 4 seconds to about 1.5 seconds" gives them something to write down. You do not need a perfect figure. You need an honest one.

If you have no numbers at all, there are still small facts that count: "the on call alerts for that service dropped from about five a week to one", "two teammates started using the script", "the release went from a half day task to about twenty minutes".

The same story, told badly and told well

Here is a believable engineering example. Say you are asked, "Tell me about a time you improved something."

Told badly

"So at my company we have this orders service, it's a Java service, and the team is about eight people. We use Postgres and there was a lot of traffic during sale season. We had a few issues with performance and the product manager was worried. So we looked into it, and we found some things and we made changes, and yeah, it was a good learning experience. It worked out in the end."

What is wrong here?

• Nearly all of it is Situation.
• "We" appears four times and "I" appears zero times.
• There is no description of what was actually changed.
• "It worked out" is not a result.
• The interviewer cannot write a single useful note.

Told well

"I was on the team that owned our orders API. During a sale week, the order list endpoint was taking around four seconds, and support was getting complaints. My task was to bring it down before the next sale, which was about three weeks away.

I started by turning on query logging and found that one request was making about two hundred separate database calls, one per order, to fetch the customer name. I changed it to one query that joined the tables. I also noticed that the filter on order date had no index, so I added one, after checking with a teammate that it would not slow down writes too much on that table.

After the change, the endpoint dropped from about four seconds to about 600 milliseconds. During the next sale, we had no slowness alerts on that endpoint, and support stopped mentioning it. One thing I would do differently is add a test that counts database calls, so that this does not creep back in."

Count the seconds. This is about 110 to 120 seconds when spoken. Look at what it does.

• Situation and task take two sentences.
• "I" shows up many times, and the one place a teammate helped is named honestly.
• The action has details a real person would know: query logging, two hundred calls, an index.
• The result has two numbers and a business effect.
• It ends with one honest thing learned, then stops.

Note that the second version is not more dramatic. The problem is the same size. It is just more clear.

Other quick examples of the shape

A flaky deploy story, in one breath:

"Our deploys to staging failed about one time in five, and people had started re-running the pipeline without looking. I was asked to look at it since I had written part of the script. I read the last twenty failures and found that fourteen of them came from one step that started before the database was ready. I added a simple wait and a health check. In the next month, failures dropped to one, and the team stopped re-running blindly."

A missed deadline story, in one breath:

"I had promised a reporting feature in two weeks. On day eight, I saw that the data export part was far bigger than I had guessed. I told my manager that same day, showed her what was done and what was left, and offered two choices: ship without export, or slip by one week. We shipped without export first, and added it the week after. I now check the riskiest part of a task in the first two days, not the last."

Both are short. Both have an "I". Both end with something that changed.

Building a story bank

A story bank is a short list of real events from your work that you have prepared in advance. You do it once, and then you use it for every interview.

Six to eight stories is the right size. Fewer, and you will repeat the same story in one interview, which looks thin. More, and you will not know any of them well.

Where to find stories

Look at your last two or three years. Scan these places:

• Your calendar and old Slack or Teams messages, for weeks that felt hard.
• Your closed tickets and pull requests, for things you finished.
• Any post mortem or incident document you took part in.
• Feedback from your last review, the good and the bad.
• Side projects, open source work, college projects (if you are early in your career).

Do not only look for wins. A good bank has at least two stories where something went wrong, because failure questions are everywhere and a fake "my weakness is working too hard" answer sounds empty.

Mapping stories to questions

One good story can answer several questions. You just change which part you stress. Say you have these eight stories:

Read it row by row. The "Production bug I caused" story fits Ownership, Failure and Learning. You will stress a different part each time: for Ownership you talk about how you took it up and fixed it, for Failure you talk about your mistake, and for Learning you talk about what changed in your habits.

This is also why you do not need a different story for every question. Choose the one story that fits best, and say the part that matters for that question.

The worksheet

Copy this for each of your stories. Fill in the blanks with short phrases, not whole paragraphs. If you cannot fill a blank, that is a sign the story is not ready yet.

Story name (a short label only you will understand):
______________________________

Rough dates and my role:
______________________________

SITUATION (one or two sentences. What was going on?)
______________________________

TASK (what was I responsible for? Who was waiting on me?)
______________________________

ACTION (3 to 5 things I did myself, in order. Use "I".)
1. ______________________________
2. ______________________________
3. ______________________________
4. ______________________________

A choice I made, and why I made it that way:
______________________________

Something that was hard or went wrong along the way:
______________________________

RESULT (what changed? one number if I can)
______________________________

A number I can defend (time, count, percent, money, tickets):
______________________________

What I learned, or would do differently:
______________________________

Who else was involved, and what they did (so I do not hide them):
______________________________

Themes this story can answer (circle):
ownership / conflict / failure / ambiguity / teamwork / learning

Two of those blanks need a note. "A choice I made, and why" is the one that interviewers love most, because it shows how you think. And "Who else was involved" keeps you honest. It helps you say "my teammate wrote the migration, and I wrote the query changes" without drifting into either hero or hiding.

How long should an answer be

About two minutes. If you speak at a normal pace, that is roughly 250 to 300 words.

Under a minute is too thin, and the interviewer will have to drag the details out of you. Over three minutes and they will start to look at the clock. The ideal is a clean two minutes, then a pause, so they can ask a follow up.

The way to find your real length is to time yourself. Most people think they are at two minutes and discover they are at four.

Use "I", not "we"

This one needs a little care, because it can swing too far.

Say "we" when you are describing the team, a shared decision, or the final outcome. Say "I" when you describe your own part. The test is simple: could the interviewer, reading only your sentence, tell what you personally did?

Saying "I" is not bragging. You are describing facts. If you are uncomfortable with it, practise out loud until it feels normal. Plenty of good engineers come from teams and cultures where "we" is polite. That is a nice habit at work and a costly one in an interview.

The reverse also exists. If every sentence is "I did this, I did that, I saved the day", the interviewer starts to wonder how you work with others. Give credit where it is real. "My teammate caught that the index would slow down writes, and that changed my plan" is a strong sentence, not a weak one.

When you have no story

Sooner or later you will hit a question you have no ready story for. "Tell me about a time you had to deal with a very difficult stakeholder", and you have never had one. Here are some honest ways through.

First, pause and think. Taking ten seconds to say "Let me think of a good example" is normal. Interviewers prefer it to a rushed, wrong story.

Second, look for a smaller version. You may not have dealt with a very difficult stakeholder, but you may have dealt with a teammate who disagreed about a review comment. Same skill, smaller scale. Say so: "I have not had anything very big, but here is a smaller one that taught me the same thing."

Third, borrow from another part of life. A college project, an open source contribution, a volunteer group, a family business. Keep it relevant, and be clear about the setting.

Fourth, if you truly have nothing, say what you would do. "I have not been in that exact spot. Here is how I would handle it, and here is a nearby thing I did that shows the same habit." It is not as strong as a real story, but it is far better than inventing one. Interviewers can smell an invented story from far away, and a follow up question usually breaks it.

What you should not do is bend a story into something it was not. If your story is about a bug, do not stretch it into a "conflict with leadership" because the question asked for that. It will not fit, and the follow up will show it.

Common slips when building a bank

• Writing stories as full paragraphs and then reading them back. Keep them as bullets, and tell them fresh.
• Choosing only stories where everything went well.
• Having three stories that are all about the same project.
• Forgetting the numbers until the night before.
• Never saying them out loud until the interview.

Try it yourself

• Make a list of every project, task or incident you can recall from the last two years. Aim for at least fifteen, even tiny ones.
• Circle the eight that you remember best. Fill in the worksheet for the first three.
• Take one worksheet and tell the story out loud, timed. Where did you go past two minutes?
• Rewrite one of your own sentences that starts with "we" so that it starts with "I", and check that it is still true.
• Pick a question you dread, such as "Tell me about a time you failed". Write down which two stories from your bank could fit it, and which part of each you would stress.