The behavioral interview is the last component of the interview loop at BigTech. It’s not, as its name implies, a technical interview. Instead, it focuses on your previous experience. You’re there to show that you understand how to act and communicate. It’s similar to the System Design round in that it weighs more heavily for senior candidates.
Well, I don’t need preparation to talk about my experience, you might think. And you’d be wrong. Don’t underestimate this interview or you will fail it miserably. A behavioral interview isn’t an informal chat where you reminisce about your previous experience and have a good laugh in the end. There are clear expectations.
I’m ending my series about interviewing talking about this interview format.
Structure of a Behavioral Interview
A behavioral interview centers around open-ended questions. There are many, many sample questions on the internet. They tend to sound similar, though:
- Tell me about a project where you had a big impact
- Tell me how you solved a conflict between multiple teams
- Tell me about a time when you had to make a quick decision
Note that these questions focus on your previous experience, not hypothetical scenarios. The reasoning is that it’s easier to understand how you think by hearing about what you did already.
These questions are vague and undefined. However, that doesn’t mean you should answer with the first thing that comes to mind. Doing so is a recipe for rejection. Instead, the canonical advice is to use the STAR method. While that’s the right starting point, we can build on top and do better. Allow me to explain.
STAR is Flawed
This response could be shorter
STAR (Situation, Task, Action, Result) is a way of structuring your answers to any behavioral question. You start explaining the context. Then, you talk about your task. You follow with your actions, and in the end, you round it up with the results of those actions. Using this structure ensures that you tell a coherent story.
There’s a problem, and it has to do with repetition. In practice, Situation and Task often overlap significantly. If you follow the method rigidly you’ll end up mostly saying the same thing twice. It might sound innocuous, but you can’t afford to use your limited time inefficiently.
In these interviews, time is your enemy. At Meta, for instance, they last 45 minutes. That includes the introduction and your questions, mind you. You won’t have enough time to talk about all the wonderful things you have done. Repeating yourself leaves you less time to provide useful signal. It makes the interviewer’s evaluation harder, which reduces your chances.
I prefer using a streamlined version of STAR. Let’s call it PAR: Problem, Action, Result.
Let’s say you get one of the aforementioned questions. You come prepared and want to answer it following this method. What are the relevant bits to include for each section?
This part is about giving context. Where were you, when was that, and what was your role. Make it short and crisp. Skip any detail about your position that’s not fundamental for understanding the situation.
After that, it’s time to describe the problem. Remember that you have to make it understandable for people who weren’t there. Talk about the timelines. If you were measuring the problem with some KPI, that’s worth mentioning.
Be succinct! An interviewer will get frustrated if you bore them with irrelevant details. Practice saying the least possible that is still enough to understand what’s going on.
You set up the stages, now it’s time for the important bit. What did you do? Explain that without domain-specific context or internal terminology. Focus on what you did. A behavioral question isn’t the time to talk about the team. They are looking to hire you , not your team. Ensure that there’s no ambiguity about that.
Don’t go too broad with your answer. For a complex project, you did a lot of things. You don’t have time for all of them. Pick the top three that are the most relevant for the question and had the most impact. Again, you’re looking for the right amount of detail.
The result is where you round up your answer and come to a satisfying conclusion. You did a whole bunch of things. Talk about the outcome. There has to be some outcome. If all your actions changed nothing, find another example.
Ideally, you’ll have numbers that you can mention. You don’t always have solid, well-measured numbers, but you can make reasoned estimations. Don’t make outlandish claims unless you’re ready to justify them.
Depending on time, consider including:
- Next Steps: What would come next?
- Scaling: How can you use what you did to scale it to a bigger audience?
- Learnings: What would you do differently next time?
You put all three together, and that’s your answer. See this post from Will Larson to see an example.
Building a Portfolio of Experiences
In my experience, the best way to prepare for the behavioral interview is to build and curate a portfolio of examples based on your experience. There are way too many questions out there. You can’t prepare specific answers for all of them. Instead, I focused on having strong examples that cover multiple behaviors. That way, you can adjust them to the situation instead of scrambling to think of something unique on the spot.
The Amazon Leadership Principles are a good base. They cover plenty of ground, so you get to think about many different aspects of your previous jobs. I have a table with examples spanning my career that I’ve refined carefully. I usually follow the same approach to extend this table.
First, I write down a sketch of my answer. Just enough that I know all the points I want to cover. It’s fine to bring your notes to an interview, but don’t read a whole answer straight out of them. Once the case is ready it’s time to polish it! Your first version will inevitably suck. You probably made it too long. Or didn’t make the results clear enough. In any case, you need to iterate relentlessly. Get feedback from somebody you trust for extra perspective.
Lastly, test it out. Read the scenario aloud to yourself or somebody else. Do a mock interview, or use it in a real interview. While your experience remains the same, your ability to present it will improve massively.
Some Extra Thoughts
Don’t make stuff up. Honestly, you’ll probably get caught and fail the interview. Even if you somehow put it past your interviewer, you’re setting yourself up for failure.
Try to cover a decent span of your career. People want to see that you have acquired a broad array of experiences. At the same time, your most recent work is the most valuable. It’s easier to remember, and it’s a closer representation of who you are today. Your strongest examples should come from the last few years.
You should prepare enough examples. You might get behavioral questions in every interview you do. Expect a couple of them. Talking about the same scenario over and over won’t be beneficial.
Lastly, don’t limit yourself to positive experiences exclusively. We all have failed at some point. Talking about your failures openly is a great way to show self-reflection and growth. What did you learn, and what would you do differently? Needless to say, don’t confront failure by blaming others. Even if it happens to be true you’re showing a very concerning side to somebody who’s trying to gauge your contributions.
Measure your Outcomes
Let’s be clear: You can’t change your experience. You can make present it better. You can show your ability to reflect and learn. Don’t get discouraged if you think that your examples are too modest.
If you don’t have impactful examples, think about how to get there over time. Use this to guide your work. If you’re working on a problem at work, go deep and understand its true impact. Seek metrics that will reflect changes. If you’re doing good work, you’ll be able to show it sooner or later. If you somehow didn’t burn all your motivation yet, this video from Jackson Gabbard.
Top comments (0)