As a senior (or above senior) software engineer, you’re more likely to get down-leveled over behavioral interview questions than in a coding interview. Don’t lose your shirt because you didn’t prep; it’s not as simple as “telling stories”, and it’s not a skill set most engineers practice in their daily work, therefore you don’t want to wing it.
The game is to explain the work you’ve done clearly, crisply, and with resonance. Sometimes what resonates is an impressive metric like “reducing build time by 15%”, but other times it’s being able to admit when you were wrong. That’s a pretty wide-ranging skill set.
This post by StaffEng outlines 4 archetypes of Staff-plus Engineers. Taking even a brief look into those archetypes, you’ll see that coding–or tech, even–isn’t the whole picture. The most common thing is, like, hard-to-put-your-finger-on business stuff. And which interview round is best suited to gauge you on that? … Capisce? Just like the career tracks of individuals, as software engineering hiring progresses, its contents get more difficult and more specific.
Companies used to have less specific and less tricky behavioral questions. A shift took place when Netflix, thanks to its infamous culture deck, decided they were going to have a very hard and quite peculiar behavioral interview. Amazon followed suit. As did Apple. Then came a whole herd of followers until you got the current state of the behavioral interview process. Sure, with some top tech companies, you might get lucky with an easy round. Otherwise, it’s tougher than you thought.
This guide will dive deeply yet briefly into the underbelly of behavioral interview questions for software engineers, we’ll cover:
- Relevant background on behavioral rounds
- How you’re assessed
- Common behavioral questions
- How to structure your answers (hint: don’t use the STAR method)
- How to prepare effectively
Importance of Behavioral Questions for Software Engineers
The more senior you are, the more they matter. From senior to staff to principal and beyond, with each career step more soft skills are expected out of you.
There are hundreds of thousands of dollars between each senior-plus level at a FAANG company, which means (assuming it’s split equally with sys des) behavioral is worth ~50k per level. That’s a conservative estimate.
Understanding Behavioral Interview Questions
“Past behavior is the best way to predict future behavior.” Whether they know it or not, that’s the motto of tech companies that ask behavioral questions. By discussing past experiences, candidates reveal how they’d act if employed by the company they’re interviewing with.
Though companies ask these questions to target a candidate’s motivation, philosophy, interpersonal skills, problem-solving ability, or culture fit, there’s no way to predict which type of questions (in that wide array) you’re going to get. In fact, the surface area they can pull from is even wider.
The answers and the grading processes in a coding interview are much more straightforward, compared to behavioral which can feel entirely subjective. In coding, software engineers know if they bombed a round. In behavioral, they can be shocked to learn they bombed a round. That’s the level of subjectivity we’re talking about: one side can see red, and the other sees green.
How They Differ from Technical Questions
Technical interview questions around coding and technical skills are based on concepts external to you, such as “How would you build a large file system?” File systems were here before you, so after you interact with them, then you can talk about their intricacies. Behavioral questions are based on concepts internal to you; your past experience is something only you know so only you can describe its intricacies.
There are two types of behavioral questions: reflective and situational. Reflective questions are hypothetical, like “How do you approach competing priorities?” Situational questions are about your past, such as “Tell me about a time when…” And the smart candidates know that a situational answer (one based on anecdotal data) is always better than a reflective (hypothetical) answer. Therefore, the way to answer all questions as if they were situational (even if they were reflective).
How You’re Assessed with Behavioral Interview Questions
The meta-skill being assessed in behavioral rounds is communication. All questions assess communication, whether directly or indirectly. You can’t run an organization or have a VP delegate work to you if you can’t communicate clearly. Clear communication is effective in explaining technical concepts to a non-technical audience.
The other factors software engineers are graded on are:
- Problem-Solving
- Learning (and Failure)
- Interpersonal
- Ambiguity
- Leadership
Problem-Solving
Unsurprisingly, if hired, you’d be trusted to make technical decisions. So they want to litmus test your decision-making process. Even though these rounds aren’t asking you to solve problems, one of the most crucial points is your description of past problems you’ve solved.
Learning (and Failure)
Even Amazon, the macho Amazon, the place run by the Terminator, openly praises leaders displaying vulnerability. Sure, maybe “vulnerability” might be a buzzword nowadays, but the point is, if the toughest crowd is sensitive enough to want this, you can bet everyone else is, too. It’s like this, tech companies don’t want defensiveness out of you. They want you to say “I messed that one up.” Without protecting yourself. Pause. Then say how you took some class or learned something so you’d never make that blunder again.
“I’m sorry I cost you money, dear capitalist regime, but then, I found God–that’s what I call Marty Kleppmann–and I’ll never design any architecture that way again, because now I’ve seen the light on weak isolation levels.”
Interpersonal
Partly a test of collaboration, and partly a test of conflict resolution, interpersonal communication skills test your ability to work and collaborate with difficult team members, as well as give (and receive feedback) and build a high-performing work environment. Mentorship can be a part of this category as well.
Ambiguity
Tech is an ambiguous world. Technical leaders and senior-plus engineers are expected to not only survive the madness but thrive within it. Your ability to navigate ambiguity is expected to increase as you climb the software engineering role ladder. Many companies, like Google, hone in on your ability to handle ambiguity and prioritize more than almost anything else.
Leadership
The wider your impact and more broad the influence you convey, the more responsibility you will be given. Tech companies want to know how you set the direction, get buy-in, and affect stakeholders. Think of this as all of the functional leadership skills one must have to operate at this level: prioritization, time management, cross-functional, and more.
Common Software Engineer Behavioral Interview Questions
The questions you might get are infinite, but these patterns are certain to come up. Some questions you may get asked to assess the above factors include:
Problem-Solving
- What is the most significant or hardest technical challenge you have worked on?
Learning (and Failure)
- Tell me about a project you are very proud of. Tell me what you learned from the experience and what would you do differently next time?
Interpersonal
- Give an example of a time you had a conflict with a colleague. What happened, and tell me what steps you took to resolve it?
Ambiguity
- Give me an example of a time when you had to make a decision very quickly and you didn’t have enough time to gather any data to direct the decision.
Leadership
- Let’s say you’re working for a VP who is consistently late to meetings. It’s become enough of a problem to interfere with your work. What would you do?
Tips for Answering Behavioral Interview Questions
To ace your software engineer interview, keep these tricks in mind:
Start with a Single Line
Before you try to craft some long-winded story on paper and practice that monologue before you’ve given yourself a chance to do a good job… work from first principles instead. In the fewest amount of words, how would you express the “kernel” of your project? Boiling a project down to the essential, allows you to not only start from a better place than vomiting on the page (or out loud) it lets you use it as a hook to entice the interviewer.
“One project that comes to mind is a time I saved 300k in annual engineering costs by finding a bug in our cloud infrastructure.” Watch the interviewer’s eyes light up and get excited to hear the rest of the story. Essentially, you can think of it as a “trailer” that makes them want to watch the movie.
Don’t Utilize the STAR Method, Use “Man in a Hole” Instead
It’s 2024, the STAR method is outdated and cliched. It’s not a good method for coming up with an answer. It’s only good as a filter to pass answers through after they’re made, and even that is only maybe necessary. You don’t need to be a man to use “Man in a Hole”, described by an Amazon Principal engineer.
Have at least 5 impact statements in your back pocket
Hiring managers and engineering leadership won’t listen to you if you don’t connect your work with the bottom line. You need to tell them the impact (aka metrics) of your work, or else they can’t understand scale or complexity. A word to the wise: no one knows these numbers with absolute certainty, your best guess is more than good enough. To find impact statements, for anything you’ve built or managed, ask yourself questions like:
- How many devices or users did it launch to?
- How much money was processed by it?
- How much money did you save on annual engineering costs? To calculate…
- Let’s say “X” is the old thing you replaced, and “Y” is what you replaced it with
- Multiply [How much faster Y is than X (in hours)] by [The number of people who used to do X] by [How many times per week the average person did X] by [How much money those people make per hour (divide a salary by 2 to get the hourly)] by [52 (weeks per year)]… and there you have it. You’re probably ready for Shark Tank.
Move the Goalposts
If they ask you a question, and you don’t have an answer that fits 1:1 but you have one that kind of fits, then propose that. “I don’t have anything about a conflict with a manager but I have one about a colleague, what if we talk about that instead?” And if they ask a question you don’t have an answer to, that’s chill too. They don’t expect you to have an answer for every question. Don’t worry, I have asked them.
(The only caveat is if you’re punting on a table stakes question that it’s a no-brainer for candidates to have, like if you’re interviewing for a senior-plus role, and you don’t have an answer to “Tell me about the hardest technical challenge you’ve worked on” or “Tell me about a time you mentored a more junior colleague.”)
When Necessary, Be Specific and Provide Context
Does the interviewer need to know 5 different internal names of teams at your last company? Do they need to know about any jargon, which only past-team members of a company would know? Absolutely not. If you’re asked about an argument with a former colleague do you need to be specific about their exact approach and your exact approach? Again, no way Jose.
On the other hand, a brief 1-2 lines of setup for the business context can help. Specificity helps, especially if it’s with numbers: impact statements, size of the team, number of other teams, how long something took, and how long it would have taken. When in doubt, use the golden rule: does it improve their opinion of you to tell them? Then tell them. If not, then don’t.
Be Concise
The whole idea is to be lean and mean. Simple yet dense. That is aided partly by using the above technique of “starting with one line.” Ultimately, this is the biggest sticking point for engineers: how do you give enough information to set the stage but not too much so it overwhelms them? It’s a balancing act. It’s best to get some feedback from someone who knows what they’re talking about to see how well you’re able to do that.
After coaching thousands of engineers and listening to hundreds of hours of interviews, you rarely see one who’s too concise. Over ninety percent of the time, if there’s an issue with the length of a senior-plus engineer’s behavioral answers, it’s because it’s too long.
Common Mistakes to Avoid in Behavioral Interviews
During an interview, steer clear of these pitfalls:
Trying to Be Too Polished
A senior software architect recently told me, if a candidate is trying so hard to check the boxes, as opposed to being themselves, it’s his number one pet peeve. Any time a candidate says “The Situation was”, “The Task was”, “The Action was”, or “The Response was” if it’s a remote interview, that Architect wants to “open up another tab and do something else.”
If you’re going to describe a “situation”, do it without being married to the structure of too many of those who came before you.
Rambling
When you’re answering behavioral questions, no one wants to hear a monologue. When you’re talking about the rest of the team, limit it to 20% of your answer (80% should be about your individual contribution). If you’re talking about something negative, DO NOT ramble. Get in and out of there fast, so you can focus the majority of your answer on “what you learned and what you did about it” (to make a positive change).
Negativity or Blame
For example, if you didn’t meet a deadline, don’t say it was because the choice to make the deadline so soon wasn’t the right call. (If it wasn’t your call.) Negativity is, by far, the trickiest to see when you’re the one doing it. Again, another reason to get feedback from someone who knows what they’re talking about. It mainly comes out when talking about why you’re looking for a change, why you left old positions, past projects, and past colleagues. Catch it before it becomes a problem because negativity or blame can be an instant rejection.
Overconfidence or Lack of Humility
This is far less common than negativity or rambling. That said, you run the risk of being labeled a jerk. If you’re uber-talented, they might overlook it at some companies. But for other companies, at this point, it’s cliche to have a “no jerks policy”, that will give you the boot.
Behavioral Interview Prep
For senior-and-above software developers to crush behavioral interview questions, it’s all about preparation. These 4 tips can help you prepare:
The More Senior the Roles, The More You’ll Invest
We met an engineer who got an L7 role at Amazon (Principal, avg comp is 600k) and he said that he invested 20k to prepare solely for behavioral. And he ended up getting the exact level he was targeting. I’m not saying anyone needs to spend ridiculous sums, but if you’re looking to land senior-plus roles at elite companies you’ve never got offers from before, spend some money upfront. If you get that big payday, it’s more than worth it. And, pardon the platitude, but it’s true–the payday is more likely if you invest in yourself.
Reflect on Past Experiences and Achievements
Get those one-liners for as many projects as you need to be ready to discuss. Get those 5 impact statements (minimum). Build out some basic scripts or key points (whichever works better for you, some people like to improvise others don’t). And then, grill yourself: for each project you want to be ready to talk about, ask yourself these questions:
- What business problem was it intended to solve?
- What was the greatest technical challenge?
- What were the interpersonal challenges?
- What did you learn?
The full list of grilling questions
Practice with Mock Interviews
Mock interviews are key, especially from software development professionals who have the skills to already have the job you’re trying to get. Another option is coaching from someone whose history speaks for itself. The most important thing is to get actionable feedback from someone who knows what they’re talking about.
Research the Company
How do they measure culture fit? This case study by Ammon Bartram asked 300 hiring managers at tech companies how they determine culture fit, and 3 categories emerged: gut feel/friend test (>10% of companies), specific personality traits (20% of companies), and communication and soft skills (70% of companies). You have to know which category they are in before you go to that interview as a software engineer. It’ll give you direction on what you’re facing. This post describes how to use Ammon’s framework on the most feared behavioral question.
Conclusion
It’s not your use of a programming language that’s going to decide your level. It’s system design and behavioral interview questions. Don’t let the level you want pass you by because of a lack of preparation. If you need to get motivated, have Eric Thomas yell at you for a few minutes, you might be surprised.
Yes, these interviews are subjective, maybe more so than we’d like them to be. But once you understand the game you’re in, then and only then can you start putting points on the board. Don’t be shy to try something new. Embrace this new skill set and acquire a more in-depth ability than before. Thank us later, maybe when you’re making 600k 🙃
.jpg)
