#24 Preparing for Tech Interviews, Part 3: Behavioural
Four things to do to prepare for behavioural interviews
Welcome to final Part 3 of Preparing for Tech Interviews series, where I share insights and advice gathered from software engineers working at high-growth startups and big tech companies like FAANG.
Recap:
Note: companies might have specific requirements/responsibilities for their roles. Make sure to contextualise these estimates based on the role you’re applying for.
Behavioural Interviews
If you’re at this stage, congratulations! You passed the hard technical interviews. However, just because you have the behavioural interview left doesn’t mean you’re guaranteed an offer. Behavioural interviews can be the final piece hiring managers need to decide whether you get an offer or not, and at what level you should join.
So, by putting some effort into this final round, you increase your chances of getting an offer you want and can negotiate.
What is a behavioural interview?
It is a way for evaluating candidate’s experience and ability to perform based on their previous work. It also serves as a culture-fit test to see if the candidate will work well with the team.
Leadership roles (e.g., Staff) require a strong yes in behavioural interviews, just as much as system design (see preparation guide above). In the rest of this post, I’ll cover four key steps to help you prepare for behavioural interviews.
How to prepare:
Research the company
Use CARL for storytelling, lint with STAR
Speak to the level you’re applying for
No villains in your stories
1. Research the company
Say you have one day to prepare. First, check out the company’s website and take notes on what they’re doing (mission), what their future plans are (vision), how they plan to get there (strategy). Your goal is to get a rough idea of why this company exists, where it wants to go, and how you can contribute to its mission.
Second, research your interviewer(s). Check their LinkedIn profiles, see what they’ve been working on, and look for common ground. Any shared experience or interest can be a valuable discussion point during the interview. For example:
You both worked at the same company before.
You share interest or expertise in a specific area (e.g., platform engineering).
🌟 Tip: Highlight this in your intro.
You both enjoy reading The Proactive Engineer newsletter.
Your research doesn’t need to be a full-page paragraph, just a few bullet points and any questions you might have for the interviewer.
🌟 Tip: Don’t ask generic questions that can be found in the /about page of the company’s website.
Asking questions that make it seem like you don’t know what you’re applying for will give a bad impression. Do your research beforehand. Ask questions that give you insights into the company’s solution, team culture, and role expectations.
🌟 Tip: A good question doesn’t have a binary answer (yes or no).
Here are few examples:
❌ What is <company>?
✅ I’ve read that <company> does <solution>, could you tell me more about that?
❌ Do you need backend or frontend experience?
✅ Could you share more about the responsibilities or expectations of the role?
❌ Do you like working at <company>?
✅ What’s the one thing you enjoy most about working at <company>?
Coming prepared with questions and a sense of curiosity is a positive signal to the interviewers.
2. Use CARL for storytelling, lint with STAR
Now, when answering questions, you need to build strong behavioural responses by practicing how to communicate your past experiences. The key is storytelling.
The common advice on the internet is to follow the STAR method for storytelling. STAR is a way that lets you describe a situation you handled at work, providing key details for interviewers to assess your experience. It is an acronym for:
Situation: What was happening, who was involved, and why it mattered.
Task: What was your responsibility and what you needed to achieve.
Action: What you did, how you did it, and why.
Result: What was the outcome.
STAR is a good starting point, however I don’t recommend using it for all your responses because it lacks the character’s growth—you. As an interviewer, I am interested to hear about your stories and how you grew from each one of them. Lessons, insights, reflections, things you can take away from an experience.
So, instead I recommend using the CARL method. It is a refined version of STAR that allows you to describe the context you worked in, the actions you took, the results you achieved, and the learnings you’ve taken away. CARL is an acronym for:
Context: [similar to Situation] Share context of what was happening.
Action: [same] Explain what you did, how you did it, and why.
Result: [same] Share the outcome.
Learnings: [new] Share what you learned from the choices you made.
🌟 Tip: I previously covered a similar version (CARs) and how to write them in a Brag document for future behavioural interviews. For more, check out the post below.
Finally, here’s my strategy for preparing behavioural responses:
Step 1: Write down a few compelling stories from your previous work.
Step 2: Use STAR to lint or refine, make sure they have a clear structure.
Step 3: Repurpose them to CARL by highlighting your growth in each story.
I recently found
’s Substack, where he shares excellent advice on preparing for behavioural interviews. Austen was a Senior Engineering Manager at Meta and Chair of the hiring committee for iOS and Android pipelines.Check out his recent discussion on approaching behavioural interviews:
I recommend checking out his newsletter: Mastering the Behavioral Interview
3. Speak to the level you’re applying for
I’ve been in hiring committees where we had candidates who were technically strong but received a lower-level offer based on their behavioural interviews. Frustrating as it sounds, but unfortunately that’s the case. Companies hiring for leadership roles (e.g., Staff) look for signs of strong decision-making in candidates’ responses about their past experiences. If a candidate provides shallow answers or spends too much time discussing lower-level details, committees will be cautious about putting that candidate in a critical role.
If I’m interviewing a senior candidate and the conversation tends to go more on lower-level topics, chances are the candidate will be hired at a lower level.
To fix this, focus on sharing stories that show growth and high-level thinking in your work.
Mid-level: The features you’ve worked on and how you delivered them.
Senior-level: The projects you’ve worked on and how you supported the team.
Staff-level: The projects you’ve led and their organisational impact.
🌟 Tip: I can talk all day about how my team’s code is perfect and clean, but none of that matters if it doesn’t solve a user or a business problem.
Speak to the level you’re applying for. Don’t spend time on “small potato” topics like: code refactoring, what’s a good PR, what’s an ideal stand-up, etc.
4. No villains in your stories
Your goal is to pass the interview, get an offer, join the team, and do great work.
Your goal is not to badmouth your previous companies or create villains to make your stories more compelling. This will negatively impact your overall interview process. Some reasons are:
You’ll certainly badmouth the new company if/when you decide to leave.
You’ll signal a blame-culture attitude (e.g., “our project failed because <person> did not bla bla”).
You’ll come across as difficult to work with, which is the last thing the team needs to worry about.
And in general, interviewers will question your “innocence” if all of your stories revolve around having villains at work.
Story time. Years ago, I once broke a platform’s observability by accident for a few days and no one noticed. As painful and awkward as this was, it created an opportunity for my team and me to re-evaluate our platform alerts, refine our incident response process, and improve our communication speed with users. I am the villain in this story, but the hard lesson here is the one takeaway worth sharing (Think CARL).
Every other person I’ve worked with has a similar “broke production” story, and none of them are villains. These incidents were just hidden opportunities waiting to be stumbled on by someone for improvement.
Focus on telling high-impact stories and new learnings. No villains. Even if you’re leaving because of a bad environment, frame your reason for leaving as looking for better opportunities and how the new company can offer that for you.
🌟 Final tip: Be authentic to your self. If you’re in the behavioural round, it means they value your technical skills and they want to see how you’ll fit in with the team. Come prepared and make it ridiculously easy for them to say yes.
And these are the four things to do to prepare for behavioural interviews
Wrap up
As you advance in your career, behavioural interviews will become increasingly important, especially if you’re applying for a leadership role. So yes, soft skills are important for engineers.
To recap, four things to prepare:
Research the company
Use CARL for storytelling, lint with STAR
Speak to the level you’re applying for
No villains in your stories
Good luck to anyone doing tech interviews, hope you find what you’re looking for!
Quick ask: If you enjoyed this three-part series, let me know in the polls below. Also, if you have a question or a topic you’d like me to cover in the newsletter, feel free to submit it through this form. 🙌
If you haven’t subscribed to the newsletter yet, make sure you do. 🙏
Great set of things to focus on when preparing for behaviorals.
I especially like the breakdown of interview importance by level. I think I cover this in the podcast you embedded: most often the difference between Senior vs Staff or Staff vs Principal is evaluated in the behavioral.
It's also very likely Principal+ roles have multiple behavioral interviews in the loop, often with specific focuses, like XFN relationships or Project Retrospective (at least in MAANG+ companies).