STAR method interview answers: a guide for junior developers
The STAR method interview format: Situation, Task, Action, Result. A before and after answer for junior developers, plus a small script that scores your answer.
The STAR method is a way to answer behavioral questions in four parts: Situation, Task, Action, Result. The most important part is the Action, meaning what you yourself did. Do you tend to tell a long story about the background and forget to say what you did? Let's take a look.
What makes "tell me about a time you had a conflict" hard?
In the previous post, Minh got through the technical round at company A and was invited to the next round with the human resources team. Minh is a made-up character, a mix of situations familiar to new IT graduates, and company A is made up too. This round has no countdown and no code editor. The person across the table asks things like "tell me about a time you had a conflict while working in a team".
This is a behavioral question. It doesn't ask what you know; it asks what you have done. According to university career centers, the reason is that past behavior helps predict future behavior, as the career guide from the University of Wisconsin explains. There's no correct answer you could check with a test, and many technically strong candidates stumble here.
Minh has a real story to tell: a graduation project, a team of four building a coffee-selling website, where two teammates disagreed about how to write code. Here is Minh's first answer, copied word for word and split into four sections so we can compare later (the names Hung and Lan are made up as well):
## Situation
Back when we were doing our graduation project, there were four of us in the team, building a website that sells coffee, and in the team there were Hung and Lan. The two of them are actually quite close, but when it comes to code they often don't agree. Hung is used to writing fast and using short variable names, while Lan usually wants full variable names and lots of separate files. By week six this got tense, because every time Hung sent a pull request Lan left a lot of comments, and then the two of them went back and forth in the group chat, and the mood was pretty uncomfortable, and the rest of us didn't know what to say.
## Task
At that time I was in charge of the cart and checkout, so my code depended on both of them.
## Action
We had a team meeting and talked to each other to sort it out. We agreed on a few things together. I also said a few words.
## Result
After that things got better and the team finished the project.Read it again through the interviewer's eyes and there are three problems. The Situation takes up nearly the whole answer, and the listener waits a long time to reach what they need. The Action is three vague sentences that sound like the whole group did everything ("we had a meeting", "we agreed") and Minh "also said a few words". The Result has no detail you can believe: better by how much? After hearing it, the interviewer still doesn't know what Minh did.
What is STAR, and what does each part need?
The four letters are the four parts of the answer, in order:
Situation is a short background: where, who, what happened. Just enough for the listener to understand, with no need to tell it all. Task is your responsibility in that situation, which is why this matters to you. Action is the steps you took, concrete, using "I" and not "we". Result is what happened afterwards, measured where possible, plus what you learned.
The Furman University guide to the STAR method describes the Action as the main steps you took. Many other career centers, such as the UMBC page on STAR, teach the same four-part structure, and such guides often point out that many people neglect the Result even though employers like to hear more about it. Those two mistakes, a missing concrete Action and a missing Result, are exactly the two in Minh's answer.
These sources don't say what share each part should have. The proportions I use below are my own experience, and you should treat them as suggestions, not rules: Situation plus Task under about 30% of the answer, Action at 45% or more, and the whole answer about a minute and a half to two minutes when spoken.
A small tool for scoring an answer
Writing an answer down and rereading it by eye makes it easy to feel fine about it. So I wrote a short script to count: how many words in each part, the estimated speaking time, whether the result has a number, and whether in the Action you talk about "me" or about "the group". It takes a Markdown file with exactly the four sections shown above. Save it anywhere, as long as it sits next to your answer file:
// Grades an answer written in the STAR format. Reads a Markdown file with four sections: "## Situation", "## Task", "## Action", "## Result".
// Usage: node check-star.ts answer-before.md
import { readFileSync } from "node:fs";
const SECTIONS = ["Situation", "Task", "Action", "Result"] as const;
const WORDS_PER_MINUTE = 130; // a speaking speed I picked to estimate with; time yourself reading a passage aloud and replace it with your own
const GOOD_TIME = [60, 120]; // seconds: the range I set for a behavioral answer
const file = process.argv[2];
if (!file) throw new Error("Pass a file name, for example: node check-star.ts answer-before.md");
const content = readFileSync(file, "utf8").normalize("NFC");
const countWords = (text: string) => (text.match(/[\p{L}\p{N}]+/gu) ?? []).length;
// Split the file into parts: each "## Name" line opens a part, and the lines after it belong to that part.
const parts: Record<string, string> = Object.fromEntries(SECTIONS.map((name) => [name, ""]));
let current = "";
for (const line of content.split("\n")) {
const heading = /^##\s+(.+?)\s*$/.exec(line);
if (heading) current = heading[1];
else if (current in parts) parts[current] += `${line}\n`;
}
const wordCounts = Object.fromEntries(SECTIONS.map((name) => [name, countWords(parts[name])]));
const total = SECTIONS.reduce((sum, name) => sum + wordCounts[name], 0);
const seconds = Math.round((total / WORDS_PER_MINUTE) * 60);
const share = (name: (typeof SECTIONS)[number]) => Math.round((wordCounts[name] / total) * 100);
console.log(`${file}: ${total} words, about ${seconds} seconds at ${WORDS_PER_MINUTE} words/minute`);
for (const name of SECTIONS) console.log(` ${name.padEnd(10)} ${String(wordCounts[name]).padStart(3)} words ${String(share(name)).padStart(3)}%`);
// "we", "our", "us", "the team" talk about the group. "I", "my", "me" talk about yourself.
const action = parts["Action"].toLowerCase();
const teamCount = (action.match(/\b(we|our|us|the team)\b/g) ?? []).length;
const meCount = (action.match(/\b(i|my|me)\b/g) ?? []).length;
const times = (n: number) => `${n} ${n === 1 ? "time" : "times"}`;
const warnings: string[] = [];
for (const name of SECTIONS) if (wordCounts[name] === 0) warnings.push(`The "${name}" section is missing.`);
if (seconds < GOOD_TIME[0] || seconds > GOOD_TIME[1]) warnings.push(`Length is ${seconds} seconds, aim for about ${GOOD_TIME[0]}–${GOOD_TIME[1]} seconds.`);
if (share("Situation") + share("Task") > 30) warnings.push(`Situation and task take up ${share("Situation") + share("Task")}% of the answer, aim for under 30%.`);
if (share("Action") < 45) warnings.push(`Action is only ${share("Action")}%, aim for 45% or more: the listener wants to know what you did.`);
if (!/\d/.test(parts["Result"])) warnings.push("The result has no numbers.");
if (meCount + teamCount > 0 && meCount / (meCount + teamCount) < 0.5) warnings.push(`In the action you talk about the group ${times(teamCount)} and about yourself ${times(meCount)}: the listener can't tell what your part was.`);
console.log(warnings.length ? warnings.map((w) => ` ! ${w}`).join("\n") : " No warnings.");Two places in the code need explaining. The regular expressions \b(we|our|us|the team)\b and \b(i|my|me)\b look for those words standing alone, so "me" isn't found inside "time" or "meeting". And the numbers 130 words per minute, 60 to 120 seconds, 30% and 45% are ones I set myself, not anyone's standard. The script is a ruler for comparing two versions of your own answer, not a judge.
Running it on Minh's first answer:
answer-before.md: 182 words, about 84 seconds at 130 words/minute
Situation 124 words 68%
Task 20 words 11%
Action 27 words 15%
Result 11 words 6%
! Situation and task take up 79% of the answer, aim for under 30%.
! Action is only 15%, aim for 45% or more: the listener wants to know what you did.
! The result has no numbers.
! In the action you talk about the group 2 times and about yourself 1 time: the listener can't tell what your part was.It's what I'd guessed by eye, but now with numbers. The answer is 84 seconds long, which is fine, but 79% of it is background and only 15% is what Minh did.
Rewriting it: start from the Action
The way I suggest Minh rewrites it is to reverse the order of work. Don't write top to bottom. Write the Action first, because that's what the listener needs, then add just enough background to make the Action understandable, and finally the Result with specific numbers. To make the Action concrete, Minh asks three questions: what did I do first, what did I say to whom, and why did I choose that way. Here's the rewrite:
## Situation
In our graduation project, four of us were building a coffee-selling website. By week six, two teammates disagreed about variable names and how to split files, so one person's pull requests kept getting sent back.
## Task
I was in charge of the cart, and my code depended on both of them, so I couldn't stay out of it.
## Action
I booked 10 minutes with each of them separately and asked what a good piece of code looks like to them. Both wanted readable code and differed only in how to get there. I suggested writing five short conventions in a CONTRIBUTING file, such as how to name things and when to split a file, and I drafted it myself for them to edit, using each person's own words so they could see their view in it. I proposed trying the conventions on one pull request before applying them to the whole team, and after the first try I posted the result for everyone to see.
## Result
Over the next two weeks, the number of pull requests sent back dropped from 6 to 1, and pull requests were merged the same day instead of waiting 4 days. The team handed in the project on time. I learned that once a disagreement is written down as a shared convention, it stops being a matter between two people.answer-after.md: 226 words, about 104 seconds at 130 words/minute
Situation 37 words 16%
Task 23 words 10%
Action 107 words 47%
Result 59 words 26%
No warnings.I should be honest about one thing. My first version of this rewrite was also flagged: Action was only 44%, just under the threshold. I added one clause (the part about using each person's own words) to get past it. The final version is only a sentence longer than the first, and that's what I want you to see: the gap between an answer scored "vague" and one scored "specific" is often just a few sentences, not a completely different story.
About the numbers in the Result, "from 6 to 1" and "4 days" are Minh's (an illustrative character). When you write your own story, use only numbers you really have. If you have none, describe a result you observed, for example "after that the two of them stopped going back and forth in the group chat about naming". An invented number is easy to ask about, and then you lose both the story and the listener's trust.
A bank of stories for many questions
Something worries many people: there are dozens of kinds of behavioral questions, so do you have to prepare dozens of answers? No. Following the suggestion in the Furman guide, you prepare a few stories for each skill area and reuse them. For someone new to working, three real stories are often enough. Here is Minh's story bank, each story in four short STAR lines:
# Minh's story bank (illustrative)
## 1. Disagreement in the project team (skills: teamwork, resolving conflict)
- Situation: Group project of 4, week 6, two teammates disagreed about naming and splitting files, pull requests kept being sent back.
- Task: I was in charge of the cart, my code depended on both of them.
- Action: Asked each of them separately, suggested writing five conventions in CONTRIBUTING, tried them on one pull request.
- Result: PRs sent back dropped from 6 to 1 in two weeks; merged the same day instead of waiting 4 days; handed in on time.
## 2. Hardest bug: the 6:30 a.m. expense on 1 December landed in the wrong month (skills: problem solving, persistence)
- Situation: In my expense book app, on my machine it was right but on the server an expense at 6:30 a.m. on 1 December was counted in November.
- Task: Find the cause and fix it before friends used it for real.
- Action: Guessed the server runs on UTC, reproduced it by running the tests with TZ=UTC, then fixed it to always work out the month in Vietnam time.
- Result: The bug could be reproduced and is locked down by a test; afterwards 12 friends used it for two months without hitting it again.
## 3. Too shy to ask, so I lost time (skills: noticing a weakness and changing)
- Situation: Working on the cart, I got stuck on a state bug and struggled alone for two days without asking anyone.
- Task: The whole team needed the cart finished to connect it to checkout.
- Action: I gave myself a rule: if stuck for more than 1 hour, write the question (what I tried, what the error is) and send it to a teammate.
- Result: The next time I got stuck, I asked after 1 hour and finished that same afternoon instead of two days.Story 2 is the "6:30 a.m." bug that Minh mentioned in the interview preparation post. Story 3 is about a weakness, and it does one important thing: it tells a real weakness together with something Minh did to fix it. "My weakness is perfectionism" sounds safe, but interviewers have heard it too many times.
These three stories can answer about eight common questions:
- "Tell me about a time you had a conflict in a team" and "tell me about a time you disagreed with a teammate": story 1.
- "What's the hardest bug you've met?" and "tell me about a time you had to learn something new very quickly": story 2.
- "What's your biggest weakness?", "tell me about a mistake you made" and "what do you do when you're stuck?": story 3.
- "What are you most proud of?": story 2 or story 1, whichever has a result you can measure.
The rule for using the bank: when you meet a question, don't think up a new story. Find the closest story in the bank and pick the part that fits the question. The same story, asked about conflict, stresses the communication in the Action, while asked about pride it stresses the Result.
Then the phone rings: "the company wants to send an offer"
Minh answers the human resources round with more confidence than the first time. A few days later the phone rings: company A wants to send an offer. The salary in the offer is a bit lower than Minh hoped for, and the caller asks "how do you feel about it?". Whether to accept right away, what to say, and whether to negotiate on a first job are the topics of later posts.
You can follow the whole journey in the series The junior journey. If you want more practice, the question on behavioral questions and the STAR method, the question tell me about yourself in one minute and others are in the interview question bank.