Behavioral interview questions are a staple of modern tech interviews.
Despite being much less technical than coding or system design questions, for example, they are just as influential on who gets a job offer at the end of the hiring process.
A behavioral interview question, as the name suggests, is a question focused on your past performances or behaviors in your professional career.
You may also know them as the "tell me about a time..." or the "give me an example of..." interview question.
Ultimately, companies ask these questions because they are thought to predict your future job performance.
Still, many tech candidates may struggle to answer these questions or answer them as best as they should.
But that's where STAR comes in.
The STAR method is one of the most well-known interview frameworks out there.
It is a particularly effective framework for answering behavioral interview questions.
As a matter of fact, Amazon explicitly recommends that their candidates use this framework for answering Leadership Principle-related interview questions.
While it's true that you shouldn't rely solely on this or other frameworks when going through your interviews, they can be handy when used appropriately.
The STAR method stands for Situation, Task, Action, and Result.
In short, using this framework, you can break your interview answer into these four components for a crisp, concise response without compromising quality.
Of course, that's easier said than done.
What would a real-life example of using STAR look like?
Let's imagine that you, as the candidate, were asked to talk about a time you disagreed with someone and how you resolved it.
Let’s say you decide to talk through a time, as a technical program manager, you had a conflict with an engineer over whether or not code refactoring was necessary for an upcoming Scrum sprint.
First and foremost, you'll need to flesh out the situation. Specifically, it's essential that you explain the context behind the situation and why your role in it was crucial.
Ultimately, this sets the stage for the rest of your answer.
You'll want to provide enough detail to demonstrate why this situation you chose is worth discussing in the first place and why it is an appropriate choice to exemplify your skills.
So, for our example, you could explain the situation in the following way:
"When I was acting as the lead TPM for a particular project, some members of my team and other stakeholders were pushing to update the website's logo.
Nevertheless, an engineer I was working with on this project wanted to wait. They were trying to implement new technical infrastructure that would make it much easier to change the logo, if need be, in the future.
This logo change was ultimately so significant because the CEO was pushing hard for the company to look its absolute best to help raise a Series B round of investment. Unfortunately, this out-of-date logo created bottlenecks for the design teams, who needed to wait for the new logo to take screenshots or build other branding assets to help with the Series B.
At the same time, though, our engineering teams had suffered a severe setback due to careless and sloppy coding many months prior. Our developers needed to rebuild much of the system architecture virtually from scratch because of this.
Finally, the engineer in question, who wanted to wait to change the logo until the new infrastructure was implemented, was not a nobody. While they were new to the team, they were not new to the company. In fact, they had worked there for many years and, at that point, they were the most experienced and most senior engineer on our team."
Depending on the situation in question, the Task portion of STAR may be a bit redundant.
If you feel like you already covered the task itself while describing the situation, feel free to skip this rather than repeat yourself.
After all, the purpose of interview frameworks like STAR is to help be succinct while still being comprehensive. Needless to say, repeating yourself defeats that purpose.
Nevertheless, this portion of STAR is where you can clarify what your role in a particular situation was and, specifically, what you needed to do about it.
So, in our example, you could say something like this:
"The ultimate goal was to be investor-ready in two weeks. My boss made me responsible for this logo-changing project.
Before this project, however, I had several meetings with the company's engineering managers about the development setback I mentioned earlier. There were ongoing efforts on our parts to improve the development process to avoid similar incidents in the future.
So I needed to figure out a way to navigate these different priorities and bridge the gap between the CEO's Series B goals and the engineering managers' goals to improve development processes."
The Action portion of STAR is the real meat and potatoes of your interview answer.
This, of course, is where you explain how you handled the problem or completed the task you previously outlined.
While you do so, you should spotlight and emphasize the specific relevant skills that this situation (and the actions you took) demonstrate.
Also, it's always best to make sure, during this section, you talk about your team as well as yourself. Many candidates think they're only supposed to highlight their own particular role, and rightfully so, it is their interview, after all.
Still, giving credit where credit is due and speaking about your teammates' or coworkers' contributions to the solution or to your success demonstrates humility and leadership skills.
As you can imagine, hiring managers love to see tech candidates with such qualities.
So, for our example, you could say something like this:
"Initially, given the small time frame I was working under, I tried to convince the senior engineer to simply change the website logo. Nevertheless, they shut me down right away.
So, I brainstormed and made a list of my possible options. I also shared them with my manager and kept them in the loop regarding this situation.
Essentially, I could have either:
- Postpone the logo change,
- Launch a temporary logo while further investing in the engineering infrastructure,
- Or launch the new logo while postponing the implementation of the engineering infrastructure.
Despite these choices, I felt it would be best if I could find a solution that would address everyone's specific needs here.
As a result, I did my best to be as empathetic as possible and listen to everyone involved.
I spoke with the designers - they emphasized that they ultimately only, at that point, needed an updated logo on one of the website pages, not necessarily everywhere.
Nevertheless, the senior engineer was very clear that they disapproved of what they saw as a quick, ad-hoc solution to this problem, the very kind that was the cause of that severe engineering setback that caused so much trouble for us. This engineer preferred that we invest in long-term solutions instead, which, in this case, was implementing technical infrastructure to make logo changes in the future.
Despite these concerns, my boss told me that the CEO was chiefly concerned with updating the logo - as doing so would allow them to present our product to investors.
So, I decided to schedule a meeting between the designers and the senior engineer in question. During this meeting, we jointly brainstormed a solution that would be mutually beneficial."
Finally, you'll need to explain the results of your actions.
Detail how the initial situation was ultimately resolved and how your actions, in particular, helped make this resolution happen.
Still, don't forget to mention your teammates or coworkers and the results of their efforts, as well.
This portion of STAR is also the best place for you to talk about the lessons you learned along the way.
So, for our example, you could say something like this:
"Despite the collaborative nature of the meeting, tempers were relatively high at the beginning. However, I cooled things off by suggesting that everyone reiterate their goals for this logo change project.
The designers restated that the logo does not necessarily need to be changed everywhere immediately- just on one page of the website.
From there, the senior engineer thought of an idea involving a short-term implementation for the logo change. However, the kicker was that this short-term implementation could be repurposed afterward into a more significant system design change that the engineering team wanted to make.
This solution was ultimately agreeable to everyone, and the roadblock facing this project vanished.
Thankfully, this meeting helped resolve the issue right then and there rather than escalating to the CEO.
This situation really hammered home how vital empathy, understanding, communication, and conflict resolution are when developing products as a team."
And that's the STAR framework!
As we mentioned, this framework is best for answering behavioral interview questions, in particular.
However, you should not rehearse or read through a prepared answer. Otherwise, your answers won't sound natural or authentic.
After all, this is a framework, not a script.
What you should do, though, is have some example situations in mind going into the interview. Then, when asked a behavioral interview question like the one in this article, you can tailor them to the specific question.
In other words, the best way to use the STAR framework is to prepare a story bank ahead of time.
That is, a collection of 5 - 10 stories or situations that you can easily speak about, that you know well, and that demonstrate some of your best strengths as a tech candidate.
Hopefully, depending on the behavioral interview question, you'll have something in the story bank that you can use to answer the question thoughtfully.
Be sure that your story bank enjoys enough diversity. It ultimately won't do you much good if every story in the bank is very similar. This, too, will threaten to make your interview answers sound inauthentic.
Instead, try to find stories from different companies, roles, teams, etc.
No matter what, though, be sure that, when telling your stories, you feel confident, knowledgeable, and professional, as these qualities will inevitably translate into your interview performance.
Also, you'll want to have a couple of stories in your story bank that explicitly showcase some of the skills specific to the role you're applying to. In virtually all cases, the job description or the job listing will directly list particular skills necessary or preferred of the candidates.
After you've started building your story bank, ask yourself some of these questions to test yourself:
At the end of the day, there's no way to know exactly what questions your interviewer will ask on the big day.
However, once you're comfortable with the STAR method and have a solid story bank, you'll be able to confidently answer any behavioral interview question that comes your way.