How to Nail Big Tech Behavioral Interviews as a Senior Software Engineer

So a lot of folks who are preparing for behavioral interviews, their approach is pretty similar to maybe how they approach a LeetCode interview or a DSA interview, or how they approach a system design interview. And that's basically like, I need to get a lot of problems and do a bunch of reps on these problems and try to get better as I solve these problems. So they might go and say, oh, let me find a list of all the best, you know, behavioral interview questions on the internet and I will like answer them and then I'll be ready to go. And that is not— while logical, I understand why they might take that approach, that's not actually a really good approach to preparing for behavioral interviews. Behavioral interviews are more about you and who you are. And so in order to, to be ready for a behavioral interview, you need to be able to do 3 things.

This conversation I talk with Austin McDonald, who has been an engineering manager at Meta close to 10 years, where he also conducted over 1,000 interviews in big tech. He also coached more than 200 engineers as they prepare for behavioral interviews, and he put all of his learnings in the book he recently published called Mastering Behavioral Interviews. I'll put the link to the book in the description. In our conversation, we talked all about how to master behavioral interviews as a senior engineer applying to big tech companies. Now let's get straight into our conversation. Austin, really great to have you here today. Today we're going to be talking about, obviously, all about behavioral interviews. It's a really, really important topic in, in any kind of, you know, interviews that we're doing, any kind of like senior IC roles. Engineering roles, and so on. Before we head on straight into behavioral interviews, let me ask you if you can do a short introduction about yourself.

Sure. It's great to be here. I love talking about behavioral interviews. To me, it's the interview where you really get to know each other. You get to know the interviewer, you get to know the candidate. It's a really exciting, like, time that you spend with the company and with the candidates. So I love talking about it. So I'm Austin. I was an engineering manager for almost 10 years at Facebook/Meta. I While I was there, I was the hiring committee chair for iOS and Android. So I picked the interviewers, trained them, we picked the questions, and then of course we review all the packets and decide who to hire and at what level for all the iOS and Android engineers there. I also did about 1,000 interviews, big tech interviews over my career. And then since I left Meta a couple years ago, I've been coaching folks on behavioral interviews and done over 200 coaching sessions with engineers, helping them get jobs at level all the way from mid-level engineer all the way to principal engineer at places like Meta. So it's been a great experience. And then recently I published this book, it's called Mastering Behavioral Interviews. It's a collection of almost everything that I know about behavioral interviews and it's available now.

Awesome. Yeah, it's really great to see you have so much experience in behavioral interviews. And yeah, let's go straight into the, you know, really topic that a lot of people are wondering these days, especially With the AI getting, you know, better and better and is changing a lot of things in our industry, especially for engineers and engineering leaders. But what do you see, like how has things changed because of AI? You know, what's the expectation? How has the expectation changed in engineers and managers, you know, and also how have behavioral interviews changed because of AI as well?

Yeah, great question. And if the listeners haven't listened to your conversation with John Crickett, that's a great one to go back to where you talked about the influence of AI and how AI is changing teams. So, just to echo some of the things that he said, full stack now means like full stack, the entire business. So, you own everything from identifying the opportunity and engaging with partners and deciding what you're going to build, designing that thing, building it, implementing it, shipping it, following up afterwards and understanding what's working. And I think that AI really enables us to own this entire stack by both by giving us an opportunity to accelerate the implementation phase, but also by giving us the ability to do and analyze some these parts of the business, like design or some of the, like, marketing aspects that perhaps engineers weren't, wasn't accessible to them in the past. So this kind of, like, full stack or full business ownership means that there's a couple of parts of a behavioral interview that a company might be really zeroing in on to understand if you as an engineer are great for their company. So number 1 is scope. So now that there's more ambiguity, there's more opportunity for you to make an impact. Then we're looking for that larger scope and to understand whether you've operated at that level, going to examine that in the behavioral interview. Ownership, right? Your ability to not just take instructions and then sort of produce code from those instructions, but your ability to understand what should be done. That's an important aspect that's assessed in a behavioral interview. And then communication, right? So we talked, I mean, my little list of all the different points of the stack, a lot of those points involve intense communication and communication with customers, communication with other people on the team. Communication with, you know, with other engineers. So that's an important aspect of working that's going to be much more important now that AI is here. The other thing I think about is Kent Beck's Explore, Expand, Extract framework, and it's his description of how technologies are created and adopted and eventually monetized. And we are definitely in this explore phase, which means there's this rapid expansion of ideas and a lot of people just trying lots of different things in AI. And of course, anybody Everybody who's an engineer right now is constantly consuming these newsletters to understand, oh, what's the latest model or what's the latest technique for me to maximize my utilization of AI, which means that aspects like your ability to grow, your ability to ingest information and then be able to turn that into action in your day-to-day work, your ability to handle ambiguity, right? So it's, you know, what worked 2 weeks ago doesn't work today in AI. So I think that that ability of handling difficult situations and being able to break it down into small pieces and try different things and throw away things that don't work and keep things that do. Handling ambiguity is super important. And then perseverance. I think anybody who has worked with an AI model to code knows how difficult it can be to get the model to do the thing that you want it to do. And that requires a lot of perseverance and character. And so those aspects, growth, ambiguity, perseverance, those are being assessed in the behavioral interview. So companies are going to be looking to see how you respond to this rapidly evolving AI environment. And they're going to do that in the behavioral interview. And this is something that John, in your previous conversation, talked about, but there's now going to be more opportunity for time with people. If implementation is something that can be handled more and more by AI, that means that you have more opportunity to communicate, more opportunity to potentially get into conflicts and then needing to resolve those conflicts, and then more opportunity to demonstrate leadership skills. And those things, again, are assessed in the behavioral interview. And so if you look at those, those, all those aspects I mentioned, scope, ownership, communication, growth, ambiguity, perseverance, conflict resolution, leadership, So those are the 8 signal areas that are looked at in a behavioral interview.

That makes a lot of sense of what I'm seeing happening across the industry, which is obviously, you know, the amount of hats that people are wearing is the highest number these days that has been ever. So with tools getting better and better, then the scope is changing and also the expectations are rising. And, you know, For example, like when Amazon introduced the cutting of and expanding the ratio between managers and individual contributors, that automatically says to you that the expectation has risen from everyone to be wearing different hats. And especially on the managerial and let's say staff engineer, engineering managers, architects, those kind of three roles are getting closer and closer together. And the amount of let's say leadership skills, also managerial skills, technical skills, those skills are getting like kind of blurred together. And that shows also on the behavioral interviews, as you mentioned, which makes a lot of sense. You want to mimic what's actually being used in expectations in roles. You want to mimic that on behavioral interviews. So yeah, thanks for sharing that. Now we're going to go straight into Behavioral interviews. Let's go straight into beginning and, you know, we're going to focus more on senior engineers. And let me ask you, why exactly should senior engineers focus on behavioral interviews?

Yeah, for sure. I mean, senior engineers, the places where we determine as a hiring committee, for example, when I was on the hiring committee at Meta, the place where we determine someone's level is primarily in system design and in the behavioral interview. And the places where we determine the most senior levels is in the behavioral interview. So, When you're inverting a binary tree, the way that you invert that binary tree looks kind of the same between if you're a junior engineer or a senior engineer, maybe you can talk about it in slightly different way, or maybe your code is slightly more efficient, slightly cleaner, but you're not going to detect a principal engineer versus a new grad engineer based purely on their code. So looking at the maturity of how you engage with system design problems, how you're able to understand trade-offs and communicate about them, what your experience level is with production level challenges and problems and how you ingest that into or inject that into your system design solutions, that's a huge part of leadership and a huge part of leveling. But if you look at someone's, I don't know, web crawler design between, say, like a staff-level engineer and a principal-level engineer, they may not look that different. In a 45-minute conversation, there's only so much difference you can extract in how someone sets up some distributed systems problem. But if you look at the behavioral interview, the level, the kinds of problems, the kinds of challenges that person has engaged with, the scope of the organization that they have led and the kinds of conflicts they've resolved, the kinds of ambiguity that they've broken down, the kinds of initiative that they've been able to create. Those aspects are very different between, say, someone who's at a senior level and someone who might be at a staff level. A senior-level engineer might have worked on projects which last 5, 6 months. They may have led a few other folks, but a staff-level engineer has led projects that last multiple years or projects which involve the entire team, you know, 10, 15, 20 people. And that difference in that level assessment happens in that behavioral interview. So when we would be sitting in the Meta hiring committee and we would be seeing, is this person really a staff-level engineer? Are they ready for this level 6 role at this FAANG company? We would look directly at the behavioral interview to assess that. So, you know, as you become more senior, of course, definitely as you move into a manager role, now they start to add additional additional behavioral interview rounds to your interview loops to assess you. That behavioral interview becomes more and more important, or that style of interviewing becomes more and more important the more senior you get.

Yeah, I really like what, what I believe Taha Hussein mentioned, which is communication is the real difference between seniors and obviously the staff engineers. And also, you can have the technical experience of a senior engineer, but if you are if your communication skills are on a junior level, you're actually going to be a junior engineer. So because you can't actually share the impact of the work that you're doing and you can't explain your technical solutions to people in an understandable way and people can't resonate and can't actually, you can't, you can't show how much great you are technically because you lack those communication skills. So yeah, communication skills are normally the biggest differentiator between senior and then also then obviously staff level or more. You can quickly see by the way the person approaches problems and the way they are sharing problems. Are they being very clear? Are they speaking in simple terms? They understand the audience, they understand who they are talking to. They want to get to know the person better so they can share, so they know exactly how much in depth and how much in detail they need to go on a specific technology and things like that. They know that the audience is very important and it's not about What you say, but how you say it as well. So, yeah, really, really good point about it. Let's go, you know, what would be your, for example, a senior engineer is listening and they would like to, they would like to break into a big tech role, let's say Google, Meta, or Apple or so on. What would be like a step-by-step, like your recommendation they should take in order to do well for their behavioral interview?

Right. So a lot of folks who are preparing for behavioral interviews, their approach is pretty similar to maybe how they approach a LeetCode interview or a DSA interview, or how they approach a system design interview. And that's basically like, I need to get a lot of problems and do a bunch of reps on these problems and try to get better as I solve these problems. So they might go and say, oh, let me find a list of all the best, you know, behavioral interview questions on the internet and I will like answer them and then I'll be ready to go. And that is not, while logical, I understand why they might take that approach, That's not actually a really good approach to preparing for behavioral interviews. Behavioral interviews are more about you and who you are. And so in order to, to be ready for a behavioral interview, you need to be able to do 3 things in the interview. So first, when you get these questions, oftentimes the questions are like, tell me about a time when you did whatever, or tell me about, you know, what you think about testing or what you think about management or whatever. You need to be able to decode the question, understand what, what the interviewer is trying to get at. What are they trying to, how are they trying to assess in me? What do they want to hear from me? You need to be able to select some response. And oftentimes that response is a story from your past. And then you need to be able to deliver that response in some kind of engaging way, right? Not too short, not too long, uh, has the right aspects about you, is not too boring, right? So you need to be able to deliver it in some way that's acceptable and engaging to the interviewer. Well, in order to do those 3 things, decode, select, deliver, that means that you need 3 to 4, what I call core stories from your past. These are the stories that you would tell a hiring manager if you only had a few minutes with them that demonstrate illustrate your kind of high watermarks, right, of your scope and your ability to handle ambiguity and your ability to communicate. We were talking about earlier. So those core stories, a lot of people can identify them and they have some ideas, but, um, the book also walks you through a bunch of different questions to help you identify what those core stories might be. And then frequently those are the majority of the interview that you'll talk through those, you know, 3 or 4 stories. Um, but you'll probably need some additional stories. They may ask you questions, for example, about times when you failed, or they may ask you questions about times when you have, uh, you know, you've had to communicate something to someone very specific, very senior, those kinds of questions, which kind of are getting at more specific parts of your past. And so what I recommend people to do is take a look at these signal areas. We talked about them earlier, those 8 signal areas, and they're, they're identified in the book. And go and ask yourself some key questions about each one of these signal areas to identify additional stories that might be, uh, that might come up. And so now you have this story catalog of 3 or 4 core stories that really represent you. And then some additional stories that cover these additional kinds of questions that you might see. Then you need to know how to deliver them well. So just identifying the stories is not enough. You need to construct some version of that story that you can tell that really highlights those repeatable actions, those things that you have done in the past, which will then, you will repeat once you get into this organization where you're applying for. And then you need to practice, right? So I think everybody knows that practice makes progress. So an interview is a nerves-inducing environment, right? We are often nervous when we are in an interview. And the more you get a chance to practice those stories, telling those stories either to a video camera or to a friend, or I even recommend having, especially if you want to break into big tech, having some kind of a professional mock interviewer that comes from the company. That you are applying to. Take a look at your stories to make sure they're calibrated well, make sure they fit the cultural aspects that a big tech company is looking for. And once you practice that, you'll have a lot more confidence and be ready to go into that interview and be able to connect with the person and then be able to tell those stories in a way that you've prepared. So that's what you need. You need a story catalog, you know how to deliver them, and you need to have been able to practice them. And so the book walks you through each one of these stages.

Yeah, I think one thing that is very important to mention is especially people that go on a behavioral interview, that they don't prepare about the structure of the answer, right? They go, maybe they have, they know what they want to talk about, but they don't actually internalize in their heads about the structure, how to actually answer the question. Can you maybe share a bit about more the structure of the answers? What's the expectation? Regarding the structure and how does that look like? How should everyone structure their answers to ensure that is, you know, it's aligned with what the interviewers are expecting?

Right. So let's back up a second. So the thing that, the reason that behavioral interviews exist is because behavioral interviewers are forecasters. They're looking at your past experience and they're predicting whether you'll be successful in their organization based on what you've done in the past. They want to see past past behaviors. That's where the interview gets its name. They want to see past behaviors that you've demonstrated that are then repeatable in their organization. So that's really the core. We're going to build everything that all the stories that we create, all the preparation that we do is built around how can I communicate these past behaviors? These are things like, oh, I communicated, right? I wrote an email, I communicated over Slack, or maybe I debugged, right? I broke a problem down into small bits and then I took each one, or maybe I initiated a problem. So all these kinds of verbs that you have done in the past. Those are the behaviors that you want to build around. Well, you know, behaviors themselves, I just go list, hey, I initiated, I debugged, I, you know, I communicated. That's not a very interesting story. And I don't understand very much about whether those were even the right actions. So you have to have some kind of context in the very beginning when you're providing, when you're starting a story to tell the listener, where are you? Why are we doing this? You know, why, what is the business need or what is the technical need behind whatever you're about to tell me that you did? Then we lay out those actions and that's where most people make mistakes. They, they most of the time don't include enough actions that they have performed, or they talk to me about what happened that the team did, but they don't tell me about what they themselves did. And then we need to hear some kind of judgment about whether or not these actions were the right ones. And this is where results come in. So you need to tell me what happened at the end of this, all these strings of actions. What was the impact, right? And then what I really like to have, especially for senior engineers, is I want I love to see some kind of reflection. I think one of the reasons why we hire senior engineers and have high expectations of them is because they're able to go through experiences and projects and then come out the other side with some kind of repeatable learning, something that they can either make themselves better or make the team better. And so I love to hear at the end of these stories some kind of reflection on, well, I, you know, I learned this, or the next time I would have done this XYZ differently. What that amounts to is context in the beginning, actions in the middle, and then ending with results and learnings. And there's a really easy mnemonic for that. Call it CARL, C-A-R-L, CARL. And that's an easy way to remember how to structure these stories.

What about, obviously the STAR method has been quite popular for behavioral interviews. What about like STAR method in comparison to CARL? What's your take on that?

Yeah. So if you, if you haven't heard of STAR method before, it's Situation, Task, Action, Results. Super popular, been there for a very long time about how to structure these stories. It does provide a similar arc where you have some kind of context at the beginning, actions in the middle, and then results at the end. So if you're armed with the STAR method and that's all you have, that's like way better than nothing. So I want to say that, but I really do have two problems with the STAR method, or I encounter two problems when I'm coaching people. The first one is the difference between a situation and a task, right? I think oftentimes, for example, even especially senior engineer stories, there's many, many tasks, right? The first task is to identify the problem, and then I have to align the stakeholders, and then I had to— then the task was to, you know, decide what to build, and then it was to build, and then it was to debug. It's like, how many tasks are we, you know, are we going to have here, right? And then so I think any kind of mental energy you're spending trying to separate the situation from the task To me, I just lump that into context. Like, this is the information you need to know in order for you to understand what's going on with the story. So I like that better. And then the fact that the STAR method doesn't have a built-in learnings or reflections piece. Some people have added it on the end, like an extra R for reflections. I call that the pirate STAR. STAR! You know, that R on the end. That's fine. You can do that too, right? But I really like that reflections. I think that that showcases a level of seniority and introspection that people are looking for, especially for senior roles. So to me, For me, it's easier to coach people to use the Carl Method. But if you are, you know, if you have an interview tomorrow and you built a bunch of STAR stories, that's great. I think you'll do well. Just add a little bit of extra learnings on the end. I think you'll be good to go.

Yeah, that definitely makes a lot of sense, especially regarding learnings. That's something that I want to hear a lot because it tells me what a person has learned from it and what are the expected, what my expectations are going to be about that person if that person comes across a similar situation once again. That is crucial. In anything is, you know, what kind of mistakes you have made and also how are you going to address it in the future. Very crucial for experience. You can't teach experience and you can only learn from it and you need experience in order to do well in our industry. You can't just expect that you will know everything all at once and yeah, I really like that comparison and yeah, thanks for sharing that. What about, you know, any kind of pitfalls or any kind of, you know, problems or any kind of mistakes that you've seen, let's say, senior engineers make in behavioral interviews? What should they, you know, avoid doing? What's something that are like common mistakes that senior engineers make?

Right. So the very first thing is to decode the question like I talked about, to truly understand what the interviewer is looking for. And oftentimes people will get a little nervous and maybe the question is like, you know, tell me about a time when you you had a conflict with a manager. And then they have an example which fits that exactly, that right, that exactly that question. They have a conflict with their manager, but maybe it's a smaller scope conflict and maybe the larger scope conflict from their career might have been with a skip level manager or with like another senior peer on another team. And so this choosing which story to respond, right? This second step, this select step, like selecting the right story is oftentimes a mistake that I hear from senior And usually it means that they're choosing stories which are not of sufficient scope. So if you know you're applying for a staff engineering role, especially at a big tech company, you only have this 45-minute block to tell your stories. You want to make sure that you get out a lot of stories which demonstrate a staff-level scope. So selecting those stories, which really represent that target level, that's the number one. And I think that scope is the most important part of selecting a story, even more important than exact matching to the question. You know, it's not that they're really passionate about, about conflicts with managers. That's not the reason that they're asking about this question. They're looking for your ability to handle challenges with leadership and manage positions where you are in, you know, you are not, you are not the leader in this organization, but you still need to manage this conflict. So they're looking for that signal and you can give them that with maybe different stories. So choose the one that has the largest scope. That's number one. I think the, Number 2 thing would be not providing enough repeatable behaviors. So typically this is where they're not comprehensive enough, right? So they've not, not, you've not thought about all the different parts of, of, of a project, all the different parts of the software development lifecycle. And so sometimes we think like, oh, managers aren't interested in hearing about my debugging or managers aren't interested in hearing, you know, about how I, had to like make this planning document and sent it out. That's kind of like an assumed part of the story, right? Oh yeah, I had this idea, you know, we planned it and I implemented it. And that's kind of sometimes the stories that I hear, but that's leaving out all the repeatable parts, right? I want to understand how you came up with this idea. What would you, what were you thinking? What kind of data did you look at? I want to understand more about how you communicated the plan. Did you decide to have a meeting? Did you decide to write a document, right? Did you get input from anyone else? All this little small details, those are the repeatable parts that Once you got into their organization, that's what you would be expected to do. So leaving out those kinds of, of, of sort of juicy bits. This happens especially for conflict stories. So oftentimes a conflict story is, well, you know, we had this disagreement and we talked about it and then we, you know, we came to this conclusion and then we were done. Right. And I think that that's emphasizing the fact that you could get through the conflict. That's good. But what were your conflict resolution skills? Like, did you go and express empathy and understand where the person's coming from? Did you decide to escalate? And why, like, why did you decide to escalate? What was the thinking behind that? Did you collect data before you went into the next conversation? What data did you collect? How did you, how did you gather it? Right? So those kinds of details are really valuable. This is a simple, and the next one is similar. So I would say that neglecting the complexity that leadership tasks involve. So we can get focused on, on being an engineer and the engineering is about, is about, you know, building things about shipping things about the, about the implementation. But forgetting some of the other parts of the conversation for other parts of software development lifecycle, things like aligning with stakeholders, things like communicating with customers, right? And you might leave out some of your thinking that you applied during those parts of the lifecycle of a project, or you might have applied some kind of framework. So, oh, you know, we decided to use, you know, this implementation framework, or we decided to prioritize our tasks based around, you know, this idea. We decided to take on some technical debt because this was the phase in our business that made sense for us. So that kind of framework-driven conversation and decision-making process, people sometimes leave that out. I would say that senior engineers often have longer stories. So we have 1, 2, 5-year projects, right? Things that take a really long time. How do you condense that story into something that someone's willing to listen to? And that's where story organization and preparation comes in. And so I really recommend that senior engineers sit down with their stories, especially those 3 to 4 core stories, identify what are the parts of this story that are the most important for someone, an interviewer or a hiring manager to listen to, then how can I bring those up front? So you might say something like, in this project, there's like 3 or 4 really interesting parts. You know, the first part was how I came up with the idea and how I was able to convince others to come along with it. The second part was how I solved some like really difficult technical problems along the way. And then the third part was about how we had to think carefully about the rollout strategy. And then the fourth part was our follow-up after the project was shipped and how we collected user data and that informed the future. So here I've already given you at the very top of this story some sense of what are the signals that you're going to receive from me as you listen to the rest of the story. And, you know, in this way you can use it like a set of slides when you're giving your presentation. Sometimes you might ramble on a little bit, you know, when the slide is up there and then you change slides and then everyone in your audience kind of wakes up. Oh, okay. New slide, right? We're going to talk about something new. And so you might ramble on a little bit about the initial initialization or the initiative part, how you came up with the idea. But then you say, okay, you remember that second part was about how, you know, I had to solve some difficult technical problems. Let me talk about that. And then your audience will kind of perk up. Okay, I'm ready to listen to this part that you're telling me. So having a strong story organization helps you communicate effectively, but it also helps the listener stay engaged for a longer story. So I see this one a lot for managers especially. And managers, their job is to communicate, right? That's one of their primary jobs. So what do they do? Well, they like to talk, you know, I think it's just interview. Let me tell you this story. Oh yeah, yeah, yeah. You know, this, this, this, this, this. So this kind of verbosity of adding words and just keep going and talking and talking and talking and talking and talking. That's a pretty big pitfall for senior engineers, especially for managers. So you, again, it comes back to, uh, you understanding as a candidate, what are the most important parts and being able to communicate that, that efficiently to the listener. And then of course, responding to the listener's facial expressions and how they're engaged with the conversation, where they're asking you follow-ups. And so navigating that and kind of learning from your interviewer as you're in the, in the midst of doing the interview is really important. Uh, senior engineers and especially managers are held to a higher standard. So it's dangerous to hire senior engineers. It's dangerous to hire managers. When you get them into your organization, they have a lot of influence. They have a lot of power. And so hiring managers are sensitive to bringing on new leaders under their team. So they are looking for mistakes. They're looking for red flags. They're looking actively to understand whether or not this is— you are the right person for the role.. So when you start to share weaknesses, especially, or perhaps it could be as innocuous as saying like, well, you know, we, I was working on this project, we had a lot of technical debt and then we needed to decide, and then you tell the story about how you resolve the technical debt. You're thinking like, yeah, of course, this is great. You know, I'm telling this story about, about how I solve this problem in the organization. You know, don't you want me, don't you want to hire me and I'll solve your problems? But then person in their mind, they might be thinking, well, Well, who's responsible for this technical debt? How did it come about? Weren't you there? Haven't you been there for 5, 6 years? Aren't you responsible for this? So I think having some kind of part of the story, the context in the beginning where you say, we made these decisions based on this business need and we decided to push forward on this feature to secure this customer and that left us with technical debt. So I think some kind of justification for why you had this problem in the first place, I think is important. So thinking defensively, in other words, towards thinking, how is my listener going to interpret what I say in an uncharitable manner and making sure that I am injecting some defenses against that as I'm communicating. Oftentimes senior managers or senior leaders in an organization are handling problems and dealing with problems right? If it was an easy situation, maybe it would've been done by a more junior engineer. And so you have to be careful about shifting blame. So when we start saying things like, well, you know, some other team, you know, created this problem for us. And so we had to solve it. This is a negative flag for leaders. So taking ownership and taking responsibility for challenges is something that I have to coach leaders in how they communicate. And then the last thing is whenever we're in a behavioral interview, we are in a vulnerable position. Like we are telling stories about our past. We're telling stories about decisions we made and situations that we were in. And sometimes if there's unprocessed emotional baggage that you may have about this project, maybe, maybe you're pretty, still pretty upset about with that manager from that period of time, or maybe that tech lead and that conflict really, you know, you never really got over that. I think that sometimes those things come across. You are talking to a, probably talking to a senior leader. As an interviewer, and they probably have a very high, you know, EQ, and they can detect what's going on inside of your mind and heart. So when you come into a conversation and you're telling a story and you haven't processed some of those feelings from the past, that can come out and be a risk for you. So those are the things that I think about when I'm helping senior folks prepare for behaviorals.

Yeah, thanks a lot for sharing all of this. Yeah, it resonates quite a lot with me, especially, you know, you gotta remember As an interviewer, you want to de-risk as much as possible for you to be hired, right? Because, you know, hiring managers are putting a bit of a risk on you to hire you. So it's, it's on your, it's your job and your responsibility to ensure that you de-risk this as much as possible. So you want to think about how can you de-risk it? What kind of stories you want to share? How can you present yourself to be as low risk as possible? And you want to do And you want to answer in that way. You want to show yourself, showcase yourself as the most credible person as possible. So the hiring manager is going to be very confident and is going to be, you know, very happy about hiring you and they will have zero of those doubts about hiring you. That's kind of like what gets you into the right mentality about it. You mentioned a lot about how important stories are and You mentioned also you suggest about having 3 or 4 stories to be prepared. Can we go a bit more into detail, like what kind of stories you suggest? Like how can senior engineers prepare these stories? What's your recommendation on that? Maybe like an example of these 3 or 4 stories. What kind of stories should they prepare?

Right, right. So I really recommend that, especially if you are changing industry types, like maybe you're going from a startup to a big tech, or maybe going from a traditional company to a big tech. That you understand what the scope of the target role is. So you can get this course from the job description. You can read the job description and understand what's, what's there, but you should also leverage any information you can find on the internet, especially, or from friends, if you're unfamiliar with, say, like what a senior engineer means at, at Google, for example, what are their responsibilities, right? So I think that's the number one thing is understand what the scope is expected of you in this target role. Then you can come back back and start to identify projects that are related to that scope. For example, and I provide a whole list of these in the book just to help you get calibrated. So for example, as a level 5 or as a senior engineer at a, let's just take a big tech company, for example, their expectation is to own an entire project. And that project might be a couple of months long. Maybe it's, I don't know, implementing some kind of dashboard system for the team in order to track all of their metrics over a long period of time. And so that involves some kind of requirements gathering phase and understanding phase and knowing what the company needs. And then designing a solution probably involves getting input from other people and then being able to implement that. Probably had some implementation challenges and different kinds of— this is where the system design parts come in, right? Some kind of technical choices you had to make. And then some kind of rollout. How did you convince people to use this thing, right? So that might be something that a Level 5 might engage on and might do. Frequently, they are leading other people. So they may have had one or two more junior engineers that you're responsible for and that you're creating tasks for them, delegating them, coaching them, mentoring them, right? Of course, any project at this level is going to have some kind of visibility. So being able to communicate upward to your manager or to your management chain on what's happening on the project is an important part. So those are the kinds of stories I generally hear from Level 5s. Senior engineers. Conflicts are often between senior members of the team or between cross-functional staff members. So it might be a conflict between you as an engineer and the designer, or it might be a conflict between you and the manager on how to approach something, right? Or maybe, maybe between you and a skip-level manager sometimes. At that next level, at that staff level, that level 6 level, now I'm looking for someone who is going to be not just owning projects, but owning entire goals. So They're a peer with the manager, helping to identify what are the important things that the team should focus on, then helping to create a roadmap that has multiple projects on it. Then, of course, the senior engineers are taking on those projects. Oftentimes that level 6 person is taking on the most technically complex work inside of the organization. And frequently they're the one who is working across organizations, right? So they're working maybe with other partner teams to ensure that the roadmap is aligned before the planning season starts, right? Those are the kinds of projects that a Level 6 might engage in. So for example, they might be performing a very large refactor, for example, like completely rebuilding some key part of the system that is very sensitive and has a lot of business implications, and they have to think carefully about how they're going to build and implement that. Those are the kinds of stories and projects that I hear from Level 6s. Conflicts. So conflicts at level 6 are almost always off team, right? So they are either between teams, maybe between, you know, how are we going to prioritize these two different competing team roadmaps and then make sure that we're delivering on whatever the business needs with the amount of resources that we have, or frequently they're with skip-level management. So how, maybe it's about, you know, hiring additional engineers or providing some kind of budget for the team. Those are the kinds of conflicts that I frequently hear. For Level 6.

Got it. So it's really just about understanding the expectations, what's expected from the role, and then prepare stories that are aligned with those expectations. That is crucial. You want to get as close as possible to reach those expectations. If you're going to be sharing stories that are less than it's expected, then you might get downleveled. Then that's what you don't want. Got it. That makes a lot of sense. All right. We talked a lot about obviously behavioral interviews and, you know, how to prepare for them. What about any kind of additional tips about how can a senior engineer break into big tech and also any kind of additional tips about behavioral interviews that we didn't mention before?

Yeah, let's talk about big tech for a minute. I think that big tech has two really interesting existing parts that might be different from organizations that you've been a part of in the past. And the number one thing is, well, not the number one, but one of those things is scale. And the other one is culture. So of course, one of the reasons that you might be attracted to big tech is because there's more scale, more users, larger systems, right? That can advance your career in some aspects like that. But that has some implications. So of course there's more users in the, in the user base. You have to think more about what are the different needs of the users. There's a larger organizational size. So you might have gone from a company maybe of 100 people or 1,000 people, and now you're joining a company of 50,000, 100,000, right? And so that kind of how to work across larger teams, many more teams involved in any project, many more levels of approval, for example, that are required before you can accomplish anything. So those kinds of aspects are important to think about. Things like pace. Oftentimes we think about big tech and we think, oh, you know, they don't move as fast as a startup. And I think that that's true in some ways. They often often don't, are not able to produce new features or new products as fast, but the expectation and the pace, the pace of working is actually quite high. So most engineers have multiple projects that they're managing at once, and there is an intense culture of evaluation and performance management that exists at most of these companies, and that can create a lot of stress. So that kind of pace can be a different scale than maybe someone has operated at before. And then the last thing that's really different about scale is because there's so many users, represent, so much money on the line. They have a lot of resources to help support their teams. They are really into measuring impact. So, because you thought it was a good idea is like not enough of a reason to do things. They are going to be very carefully assessing whether or not the work that you're about to do is going to be effective. They're going to ask you to do predictions and understand how many more likes, comments, shares, money, whatever the team's goal is. Is they're going to be assessing whether or not those projects are going to deliver those things. And then afterwards, they're going to be very rigorous about measuring the impact and expecting you to demonstrate that. So what does this mean, right, in the scale department? You may not have been operating at the scale. That doesn't mean that you cannot get a job at big tech. I certainly did not have that kind of scale before I got a job there, and everyone has their first experience in big tech. So, but you do need to change some of your language around what you, what you, how you talk about things. So for example, when you're talking about working with an organization. Instead of saying, I talked to Bill, the designer, you might say like, oh, I worked with the design organization and I did this, right? And that might be a subtle shift in language. Or you might say something like, maybe you didn't do a lot of A/B tests in your previous organization, didn't have the user base, for example, didn't have enough users to get statistically significant results. Well, you could say something like, well, you know, we could have tested this, or I would have liked to test this, but I realized I didn't have enough users. So I had to make a judgment call So you're sort of bringing in those aspects that are familiar to the listener when you're telling these stories. So that's scale. And culture is the other big difference between like a big tech company and maybe especially like a traditional company, maybe like a bank or insurance company that is still doing a lot of high, maybe even high-scale engineering, but has a different sort of cultural focus. So when you're applying for one of these big tech roles, you need to make some changes in how you tell your stories. One of them is that you need to emphasize ownership. So talk about how you went beyond just whatever the assigned task was. I think in a larger org, maybe in a traditional organization, there's a manager, the manager identifies priorities, engineers implement the priorities, right? And that's not really the way that, that big tech works. It's much more expected that you are the one who are taking ownership over your area of the, of the product, your area of the code base. You are the one suggesting the ideas, right? And so you are the one taking responsibility for, for results outside of whatever your kind of formal on-paper role is. So every time you can emphasize that you were the one who had this idea, or even you might make a change in your language from something like, well, the manager assigned me this task in the, you know, in the sprint meeting, you might say something like, I was interested in this task, right? And then I took it on. It's not a lie, right? We're sort of skipping over the fact that it was assigned to you, but there's some sense of ownership or some sense of initiative or some sense of action that you're you're taking. I would use data-driven language. So instead of just saying like, oh, we deployed, you know, we improved our deployment process. You might say like, oh, we, we reduced our deployment time, you know, from 2 hours to 20 minutes, right? Something like this. So you're providing some kind of data, even if it's estimated data, that's fine. So you could say something, oh, it was about a 50% reduction. Those are really helpful in, in, in having a culture of, of measurable results. One of the things I talk about in the book is that there are these myths or these ideas about, especially about Silicon Valley that it has about itself. And I use the word myth on purpose because it's not necessarily true. One of those is that they like to change the world, right? Imagine Steve Jobs up on stage. What is he talking about? He's talking about totally transforming the world into something completely different based on this little box he's going to give you in your hand. And I do think that when we talk about impact, impact, we talk about what we've done, we don't just say like, oh, you know, I sped up some database queries, right? You can talk about, well, I really improved the user experience for our entire customer base and I reduced infrastructure costs, right? So you're talking about this kind of change the world style impact of the projects that we're working on. That's an important part of adjusting to the cultural expectations of big tech. The, you know, big tech is a place where, you know, new patterns are created. New implementation patterns, new architectures, new frameworks are being experimented and being created. And so even if that's not something that maybe your older company had time to implement, right? Maybe they had a legacy code base. You might mention it, right? So you might say something like, well, we had this, you know, monolithic architecture and I designed my feature, but I designed my features in such a way where they could have been split into separate services later, right? So now I'm giving you this sense that I understand how, you know, a larger company or a company with more time might, or more resources might be able to change these architectural choices. So when you're working with people, emphasize how you're working with them. So I think you want to highlight that you work across organizational boundaries, that you are someone who can work with lots of other players on the team. So sometimes if you're in a traditional organization, it might be more of a waterfall approach where ideas are not are not percolating inside of some collaborative team, but maybe they're sort of coming down the pipe, you know, to you. And instead, I would try to emphasize any times that you did get a chance to ask questions or suggest things or sort of how you worked on a team in a more collaborative way. That's going to be important for big tech. Speaking of communication, communication is expected to be very direct in a big tech organization. You might be coming from a more organizational, a more hierarchical organization where where information is sent to your manager and that manager then communicates with another manager and that manager then communicates to people there on their team. And that might be the cultural expectation in the company that you're coming from. But those kinds of stories won't work well. They are signaling to the listener, to the interviewer at a big tech company, that you don't take the initiative or that you don't own the outcomes. So any times where you can start to talk about how you had difficult conversations or needed to get information from other people and how you engage directly them, that, that's going to be more important for them. And the last one is being really comfortable with rapid iteration. So at, at a big tech company, oftentimes they're, they're going to be building something and then wanting to change it rapidly, throw it out and build something else. So anytime when you had experience with side projects or hackathons or where you had to build some kind of proof of concept or a pilot program, those, those kinds of stories stories will resonate really well with someone at a big tech company who has ingested this, I call it fail fast myth, this idea that if we can, you know, get something out there as fast as we can, see what the users do with it, and then fail quickly, we can get to whatever it is that is the desired end state.

That makes a lot of sense. You know, it gets us back to what you were talking about before, and that is, you know, you want to make it You want to make it as close as possible to the expectations that, you know, the hiring manager has, and you want to de-risk the decision as much as possible. And you mentioned a lot of good things that are, you know, what are the expectations from the hiring managers. So it's really important for everyone who is listening to get as close as possible to this because that's how you're going to de-risk the actual decision for you to be hired. Let's go a bit more into behavioral interviews as well. You mentioned obviously a lot of tips already. What are some additional tips that you haven't yet shared?

Yeah, there are a number of things that we haven't talked through yet, and I do encourage people to pick up the book. I dive into all these in detail and even some more. So one of them is to really tune the level of detail that you are providing. This is frequently a conversation I'm having with senior coaching candidates is, well, how much detail do I provide? And so it's useful to think about this from a couple different perspectives. One of them is, what is the detail even for? So why do I include, for example, like, you know, database implementation details that I'm providing, right? Well, what is the point of that? And so, especially with technical detail, oftentimes the point is to showcase that you're a highly technical person and that you can solve highly problems at a difficult level. And so what I would encourage you to think about doing is thinking, well, have I done that already? You know, have I already presented this? Have I already presented in this story a level of technical depth to showcase that I truly understand what's happening in this project? If I have, then like additional technical detail, you know, may or may not be what the interviewer is really looking for. So I've already made that point in a sense, right? I've already made the point that I can go deep into this machine learning algorithm and I can choose the right, you know, the right model or something. So why do I continue to go into in depth into like this, you know, data engineering part of the problem? And it kind of depends on the role. So if it's a very highly technical role and you know the person is assessing you primarily on technical grounds, that might be a good choice. But if the, if it's a sort of general hiring manager and there, and you haven't, for example, told very many stories about leadership or about mentoring or about how you communicated with management or talk to customers, if you haven't gotten to those parts of your profile, you might want to emphasize that. So thinking about, you know, the level of detail that you provide. Another framework for detail— this very simple shorthand is if it's been like 30 seconds since you have shared some repeatable behavior, then you might be in danger zone. So think about what have I done? You know, why, why, why am I not telling you about what I have accomplished or what I, what I did in this story? So if it's been about 30 seconds, think about that. Maybe it's time for you to either like move on to the next point and, uh, you know, tell me about what you did next in the story. Another framework that's helpful is to, uh, consider where you are in the If when early on in the interview, someone may ask you a question, oh, tell me about a project that's really ambiguous. Well, if you're early in the interview and they've sort of started a new topic, in a sense, the listener might be more interested in a longer story. Maybe they're more amenable to you telling, you know, a 5-minute story, even if it's well organized. But if they're asking you a follow-up question, something like, well, like, tell me about who you worked with during this project. Right? Then they're probably looking for, they probably have other follow-up questions. So you don't want to give too long of a response, but that one's still kind of general, right? It's kind of in the middle. Maybe it's like they are looking, they're looking for something, what are they looking for? They're looking for communication, looking for collaboration, they're looking for leadership, right? Those are the signals that they're looking for with a question like that. So you need to have kind of like a medium-level response. And then they might be asking you like a very pointed follow-up question. Like, why did you choose to, you know, use this NoSQL database versus a SQL database? And in this case, they're looking for something very specific. So I think you should just give them that thing and then move on, right? Definitely not a STAR or CARL story. Like, oh, this is the situation in which I'm using— you're already in that, right? You're in the middle of the story. You don't need to be going back and telling me all this, you know, CARL response, right? This is a very specific question. Get to the question, get back to your story or get back to their next question. So thinking about where I am in this interview and, you know, what, how can I navigate the interview in time is really important. Another thing that I really recommend people doing, speaking of managing the interviewer, is to think about, well, how can I leverage, how can I partner with the interviewer in order to get the right story to them? So sometimes you may have multiple stories that have different aspects. So for example, you may have a newer story that has, maybe has more conflict resolution, but maybe an older story has more leadership opportunities, right? And so you you can use something called the menu technique. Maybe the question is something like, tell me about a time when you had some difficult challenges to work with other people, right? It's a conflict resolution story, but it's also a leadership story. And maybe they're, they're interested in one of these stories. And so you can just, instead of having to pick one and then hoping that's the right one that the person wanted to hear, you can simply say, well, I have these two stories. Make sure that when you offer the two options, you're telling me what I get from listening to each one of these stories. So one of them is about you lead, you know, leading, and one of them is more about conflict resolution, right? And so based on, on, on whatever the interviewer is looking for, they'll choose one. Maybe you get a chance to tell both, right? That's great. Even better. There are some situations where you might be in a place where you don't have a great response to a story. So now you have to figure out what to say. You might say something like, maybe the question is something like, tell me about a time when you had to have a conflict with an manager, something, maybe you've never had a conflict with your manager. So how do you respond to that kind of story? Well, there's a couple of options. One of them is to try to find some related story, which it also gives the same kind of signal. So if this is a conflict resolution story, then how can I tell some other conflict story? And maybe it's, hopefully it's not with a peer, hopefully it's with someone at least that you, that, that you have some kind of, you know, leadership dynamic with. But sometimes that is not even available. Maybe you have to, to totally change, you know, which, how you respond. So sometimes providing lists of things before you dive into what is maybe not the best story can help to give a sense of scope or, or breadth of what you've accomplished. In this example, you might say something like, well, I've had another number of conflicts in my life. I've had conflicts with product managers. I've had conflicts with peers, had conflicts with mentees, right? And then you maybe dive into one of these stories that I just mentioned, which is not exactly the thing that they're looking for, but because I provided some sort of breadth-based overview at the very top, I can get a sense of like, okay, maybe this is not the best story, but I see that they have engaged in similar situations in the past. So these kinds of communication tactics can be, can be really valuable. I want to say a couple of things about talking about weaknesses, mistakes, or regrets. This is frequently a topic of conversation in, especially in senior behaviorals. I would often ask explicitly when I was interviewing at Meta things like, tell me about a time when you failed, or tell me about what you would do differently. And the key piece here is to make sure that you choose a story that is at least plausible about why you made the wrong choice in the beginning. So for example, if you say something like, well, you know, we decided to ship this, these features to production without adequate tests, and then we ended up running into some, you know, problems in production. And then we had to go back and fix them. Well, what is that telling me about you? Yes, it is telling me that you can debug things and tell me that you can persevere through challenges. Yes, those are good things, but it's also telling me that you ship things to production without thinking about testability. So that's not the greatest look for you. So make sure that you choose some story and frame it in a way in the beginning that makes it look like the choice you made was plausible. For example, in this case, it could be that, well, you know, we were in this, we were in a high-pressure situation. We really needed to get this feature out by the end of the month in order to make this really large deal. It was going to make or break our next funding round. We had to make it happen. And you know what? Decided to cut scope on the testability and, you know, that ended up being a mistake, right? So you at least justify the choice that you made and it seems reasonable to the persons in their, in their mind, right? The other thing I would say about telling stories about weaknesses or mistakes or regrets is you always want to end those kinds of stories with what you learned and how you applied that information differently. So you might say something like, well, that was a painful experience and what I learned was to not deprioritize this part of development. And the next time we had this project that was similar to this context, context, then I took, you know, these actions, right? I ensured that we had this minimal set of tests to ensure that things worked as expected, right? So you're showcasing that you've demonstrated the learning that I'm looking for. And that's part of the growth signal that I'm trying to assess with these kinds of questions.

That makes so, so much sense, especially, you know, what I like to say is that the first question and the way you answer it and the way the sub-questions you're going to receive tells you, actually gives you the blueprint on how you need to move forward. And it's important that you recognize that. And it's important that you then adjust the way you are approaching to that because not every hiring manager is the same. Maybe some person might be more technically oriented, maybe another one might be more leadership oriented and teamwork oriented and so on. So you want to mimic the energy that they have and you want they want to share exactly what they're looking for. It's on your side to figure that out, what exactly is kind of like what they're looking for. So you want to listen closely. Obviously, it's important that you are on your best game and you make sure that you have all the stories correct and so on, and that you're prepared correctly. But ultimately, you want to also at the same time also observe the hiring manager and, you know, do what is expected. Awesome.

I just want to jump in there. So I think that that's really for the, in the interview itself, that's great. And then this is also a thing you can do outside of the interview. So if you write down the questions that you receive, the follow-ups that you, that you receive, you can think to yourself, okay, is this follow-up one where they just simply didn't understand something? Maybe I should add that to the context, right? So that, that it's not confusing to the listener. Or is this someone poking at a weakness? Oh, maybe I should have sort of been defensive in my weakness in advance. Or is this someone just wanting to know more information, right? And I think that you reflecting on that sometimes outside of the interview, after you've calmed down a a little bit that can help you the next time you go into a behavioral interview.

Makes, makes a lot of sense. I have just one last question for you. And obviously you shared so much valuable insights from your experience and so on. What would be like your, your closing thoughts about advice for especially for senior engineers trying to do well on behavioral interviews in big tech? And also how can people find you and connect with choose well?

The biggest thing that I tell people is, look, your stories are better than you think they are. They are probably deeper. They are probably more meaningful. You probably had a lot more actions and a lot more thinking, a lot more repeatable behaviors that you would want to showcase to a manager than you have identified so far. So spend some time really thinking about what are all those pieces of the software development lifecycle that I have demonstrated actions on and these stories. And those stories are probably good enough, right? So sometimes, especially people moving from maybe a smaller company or traditional company to big tech, they think, oh, these stories aren't— my stories aren't good enough, or I won't be able to get this job. I think that's not true. I think the stories do demonstrate a lot of repeatable behaviors. Go find those behaviors. That's my biggest thing. And the second thing I would say is don't blow off the behavioral interview. Of course, if you've gotten this far in the conversation, you're probably not somebody who will blow it off, but hopefully without— without a few people who hear this, behavioral interviews really do help you get the roles that matter the most. So spend some time preparing for them and you'll You'll do awesome. If you want to find me, you can find me on Substack at Mastering Behavioral Interviews. And you can also pick up my book, Mastering Behavioral Interviews. It's the guide to storytelling in tech. It was just published and it's got a lot of great examples, a lot of great tips and a step-by-step process to take you all the way through from coming up with your stories to practicing them and nailing it. So good luck out there. Have a lot of fun.

Well said, really great conclusion. Austin, thanks a lot for sharing all of this. Amazing insights. And, uh, yeah, I really enjoyed the conversation. Thank you for joining me.

Yeah, it's been great to be here. Thanks, Gregor.