Sorry, I was all excited about behavioral interviews. I got carried away there. Okay, Austin, we're going to talk about behavioral interviews today. What is your input on behavioral interviews? Why are you interested in them? Yeah, that's good. I love people, John. I think that's really what life is about. I think when I was in my...
late 20s, realized that technology is great, love technology, love building things, love making lights flash. But really, at the end of the day, at the end of my life, what do people talk about? at the end of their lives. They talk about relationships. They don't talk about, I wish I had mastered this API.
I wish I had gotten this promotion. You know, I wish I had gone to this particular place. There's a lot of things in life to invest in, and those are good things. But relationships are what last. Relationships are what really matter. And then behavioral interviews are the time.
in the hiring process when you get a chance to assess someone as a person and you get a chance to assess how they're going to interact inside of your organization. And as I was transitioning from being an engineer to being a manager because i love people i think that i naturally gravitated towards behavioral interviews as a thing that's just really interesting you i got a chance to do probably like a thousand behavioral interviews when i was at meta and um
i mean i got to meet a thousand great people and talk to them about their careers and what motivated them and what excited them about this project and how they navigated this interesting situation or that interesting situation I think I learned a ton from them. I learned a lot about how I should do my job better by listening to them talk about their job. That's how I got excited about behavioral interviews.
because I'm excited about people. So that almost makes it sound like behavioral interviews are something that you really enjoy doing and you learn a lot from. And I know it's much deeper than that. We've talked more on this, but what does the organization get out of the behavioral interview?
Not just what is Austin yet. Sorry, I was all excited about behavioral interviews. I got carried away there. That's cool. If you think about... taking a hiring process all the way back down to fundamentals and if you're designing a hiring process what do you want to do you want to understand in the most efficient way possible i'm talking to this candidate how will this candidate
perform once I get them inside of my organization. And there's many aspects of that to an engineer. If we just spend a little bit of time thinking as engineers, what do we do in our job? There's many different parts. And so far, most companies have broken this down into three big buckets. So they've broken it down into some kind of coding or hard, skilled, technical bucket. Then they've broken it down into some sort of
planning, designing, we call it system design, right? Some sort of thinking about how the different pieces fit together. But then that's not it. That's not the only things that we do as engineers we interact with.
people we uh resolve conflicts right we have to to uh respond to feedback that's given to us we have to lead others we need to think about uh what's happening in the project and decide on the next steps so If you just assessed those technical or system design aspects, that's not going to be enough for a hiring manager and organization to understand.
will this candidate perform well in my organization so they add this behavioral interview and the behavioral interview if when done correctly is really about this idea that past performance is not a predictor of future results for your stock broker but it is a predictor of future results in people so how you have performed in the past is a predictor of how you will perform in the future and a behavioral interview a well-conducted behavioral interview
is one in which we understand how the candidates have performed in their job various challenges and various situations in the past and then the hiring manager or the interview process is projecting that
into the future and trying to understand how will this candidate perform in our team and in our company once we hire them. And using those signals, that's a way in which the behavioral interviewer can understand if the candidate will be successful okay so past performances but predict a future performance what allowance do you make in that for people changing people growing i love this question
Yeah, I do believe people can change. I believe that people tend to change over long periods of time. And I think that's also true in my life. I think it's in the character changes that I've made and the significant alterations I've been able to do to how my my career has has progressed and how my personal life has progressed has been small consistent changes applied over time and uh i think that that's the case i believe that's the case for most people
radical change from someone who doesn't resolve conflicts well, doesn't lead others well, to suddenly becoming someone who is great at interacting with others, that can happen. And I believe that can happen. But I also believe that typically takes time. And some organizations are willing to invest in that time. Some organizations aren't. And I think this is what a behavioral interview and...
a candidate hiring process needs to decide. What kind of candidate are we looking for and then at what time scale are we willing to allow for weaknesses. And a lot of this when it comes down to a hiring process is all about the person's level.
So if I'm bringing in someone as a junior engineer, I understand that this person's conflict resolution skills, this person's ability to handle ambiguity, this person's ability to communicate, probably even this person's ability to be empathetic towards others. is likely not as developed as it could be. And so when I'm assessing them, I'm assessing them relative to the level at which I'm proposing to hire them.
And I think that's where the allowance comes in is, you know, but if I'm hiring a senior engineer or someone I'm going to put in charge of others, I don't want. to take a risk honestly on someone who's not empathetic someone who doesn't resolve conflict well even if i feel like i could coach them and help them they're going to have a
large blast radius of damage on my existing team and the people that I care about, the people that I have on the company now, if I were to hire them. So I think in that sense, there is an allowance for growth and growth is often something that
hiring managers look for explicitly so we'll talk about feedback how have you responded to feedback well in the past what how how aware are you of your weaknesses and i think this is where individual roles or individual interviewers my approach thinks differently Personally, when I interviewed folks, I was trying to understand the amount of self-awareness. I think if someone's self-aware of the challenges that they go through, then I think that person is pretty close to making...
any needed changes and being able to respond. I think someone who's not self-aware, who can't list their weaknesses, who can't admit failures, that person could be dangerous. dangerous person to bring into your organization. Yeah, I see what you're saying there. So I think if I was play some of that back, I might say that When you're very new to your career, you haven't had time to form those habits. So you've got time to form, learn and ingrain the good habits.
Where by the time you get to senior, you've perhaps spent more time ingraining those bad habits, making them more permanent. So they get, in a way, harder to change. And I think, in a way, as much as we call them soft skills, they are really hard skills to learn. Much harder to learn and practice than, say, coding. Because if we jump into software, you can open a book, you can learn the syntax of a language, and you can start by encoding it fairly quickly.
And you can repeat. And every time you write this function and you get it to do two plus two, it's going to give you the answer for those people skills are far more complex because there's a person at the other end, their behavior is going to change, isn't it? They're having a good day. They're having a bad day.
They're up at some early hour in the morning like you are now, Austin. They might be pre-coffee or, you know, they might be getting towards the end of their week and tired like I am. You know, all those things can make it change and make every single situation difficult. I think it requires far more experience to get used to handling them. Yeah, God forbid they're pre-coffee. I definitely have my coffee this morning. So, yes, I think that we're going to sort of philosophical...
territory now, which is, which is good, I think, which is one of the reasons why I love behavioral interviews. I would say that who someone is on the outside is really a reflection of who they are on the inside, what your beliefs are. what you've internalized, what the experiences are that you've had in your life is what makes you who you are and it's what directs your actions as you engage with others.
And I think that's the reason, that's what you're getting at when you say it can be challenging to hard to change these soft skills. And it's because it requires you to change who you are. So you can learn all the conflict resolution techniques. You can read a bunch of blog articles about it or read some books. And that's helpful. Those are good tactics. But at the strategic level, if you don't care deeply about people, if you...
don't understand you can't put yourself in their shoes you can't be empathetic If you don't believe in win-win situations or win-win resolutions, it's going to be really difficult to be effective in a large organization or even a medium-sized organization to resolve conflict. I think those internal beliefs are what you have to change if you want to change your external behaviors. And changing internal beliefs, I think we all know.
that that can be a challenge, right? Believing, changing what we believe about ourselves, changing what we believe about others. And a lot of that has to do with the experiences that we've had in life. And sometimes those experiences happen really young and then we have to spend time unlearning those things.
And that can take time. Yes, absolutely. And I think the other thing that you mentioned that you can know all about all the techniques for comfort resolution, but there's things that you can't just read a book and do. You actually need to have gone and practiced them and done them.
And they're not things that, you know, I don't know of many places where you get a comprehensive training course. Well, they'll take you into conflict resolution and give you a realistic scenario and let you practice it. I mean, maybe hostage negotiators get that, but certainly as a software engineer manager.
I've never seen that. Conflict resolution has been, you know, here's a page. When you give someone a pip and they're a bit upset, do these three things. Moving on. And it's been a 15, 20-minute conversation. mix of other management skills and you're not practiced it. You've not put, and you've got to learn by doing with these things. It's like swimming. You can't read a book on swimming, jump in the ocean and swim.
It's not going to be a fun experience and you're going to make a mess of it a lot of the time. Cool. So bringing us back to behavioral interviews before we disappear in philosophy and philosophical discussions, what are the signals that you're looking for in a behavioral interview?
Yeah, so this is a really good question. So when you start to think about, again, going back to our hiring process from the fundamentals, if a hiring manager deeply understands what it takes to be successful on their team, then they can identify those signal areas and then assess, ask questions that are related to those things. So what are some of those things? And I think that they fit into roughly, I don't know, it's like eight or 10 buckets or so.
And different companies, they emphasize different things. We could talk about that. But these are things like... initiative, right? Ability to take on, be active and proactive in an organization. Somebody who can handle ambiguity. Somebody who, given instructions that are not very clear or given instructions that don't have all the different pieces.
How can you make progress? How can you get what you need in order to go? Perseverance, right? Overcoming challenges. Convict resolution, we talked a lot about that one already. I think someone who responds well to feedback in any organization we want, people who are growing, people who are giving feedback to others in effective ways and then taking feedback from themselves. Someone who can lead others well, someone who understands.
what it's like to give instructions and knows how to delegate to others. It's more of a senior trait, obviously. Empathy, we talked about that one and the importance of that. And communication skills. And the behavioral interview is interesting because we're assessing you.
And we're assessing how you communicate in the past. We're going to ask you questions about that. But also we're seeing you communicate in real time. And those are the kinds of signals that we're looking for. And different organizations have.
codified these i mean amazon has like whatever it is 16 leadership principles that they think are really important and they assess those in every interview meta has five of these axes different companies have formalized these and um I hope to talk a little bit about being an interviewer, but if you are an interviewer, I think this is your opportunity to really think about what it is that makes people in your organization successful.
make a short list of those things. That's what you need to be assessing in the interviews. I absolutely agree. And my experience is most hire managers don't do that. Their job spec is, what is all the technology we use? Create a shopping list of it, fill it out. The interview is like, well, we like in Java, so let's test some algorithmic or data structure in Java. And, you know, I've never worked in big tech. My experience is outside big tech. In a lot of cases, they.
don't do a behavioral interview or it's somewhat copied from what they've heard secondhand might be done somewhere else. So they'll ask some of these questions of how do you handle ambiguity? but they haven't thought of how they get a signal from that. So let's take that question. How do you handle ambiguity? What does a good answer look like? What's the signal that you're looking for there? What's the bad answer? And can we maybe pin it to, you know, what's a junior?
What's a senior? What's a staff? And what would be a senior manager? Yeah, right. Really good question. So let's first talk a little bit about what you said at the very end, which is what are different levels? What do we expect from different levels? So I'll give you what. a typical fang interview or fang career structure might be like and and i think that there are a lot of parallels between this and other organizations so at the junior level
At the level of someone just graduated from college, we expect this person to handle tasks. So the manager gives them a task, they do the task, they come back, and the manager gives them another task. And then this mid-level engineer at the next level is operating more at the feature scope.
feature has many subtasks there you're expected to break down that feature and this is where we get our first glimpse into ambiguity so the mid-level engineer there's some ambiguity as to what are the tasks that are required in order to
break this feature down and execute it. But I expect you as that mid-level person to be able to break down that feature into their subtasks and execute them independently. And then at that senior level, that next level, we're operating on projects. They might be, you know, multiple months long projects. They might also be
other people involved and a project has many features and you might delegate some of those features to other mid-level engineers or junior engineers and the ability to break down that project into its subsequent features to get the right ones and then coach the mid-level and junior engineers as they break those features down into tasks and execute on them is what we're looking for for a senior engineer and again the level of ambiguity has now increased
And in general, ambiguity increases as compensation increases. So the CEO of a large organization has a very ambiguous job. They can do... Many, many different things with 100,000 people that work for them and the billions of dollars that they have at their disposal. And the reason that they're highly compensated and a lot of it's expected of them is because of the level of ambiguity that they're operating at. So just come back to my little ladder.
feature tasks features projects and then goals so that staff level person the person who is the equivalent with the manager in a sense the person who has whole team responsibility is thinking about goals for this team What should the goals be for the period of time that we're operating at, like quarters or halves or years or whatever? And then how do we get those goals broken down into projects and then delegating those projects to the senior engineers?
I think that, coming back to your question, what does a good answer look like? Well, a good answer looks like you telling a story about how you took a project or a task
of the scope that is required of the job. So if the job is for a position as a senior engineer, then the project that needs to be at project scope, the story that you tell me needs to be at project scope. If it's for a junior engineer, then I expect that that task description and that response about that ambiguous thing to be task at the task level or
or or pushing the feature level right that's an ideal answer it's like oh you i see you're reaching for the next level and maybe you were successful maybe in some ways and maybe you made some mistakes and that's really common for that person who's who's who's reaching for that next level So getting down to going even deeper, what is a good response? Well, if you've chosen a task or a story that fits with the scope that you're being hired for, then I want to see...
how you address that ambiguity. And I think this is where a lot of people fail. They'll just say things like, I got this feature, I broke it down, and then I execute, I built it. And they kind of yada, yada, yada over the most interesting part of the description of the story, which is, okay, how did you break it down? How did you think about it? Did you talk to anyone else? Did you make a list? Did you use the task system?
that was available to you. And I think that those kinds of signals, those kinds of actions are the kinds of repeatable actions that we're looking for as a hiring manager. So you're never going to, as a hiring manager, I know you're never going to build the thing that you built in the past. So if you ever built some payment system for this company, you're never going to do that again. And I'm not hiring you to do that thing again. What I want to assess is what repeatable actions.
did you undertake when you are taking on that project that I could then see you doing once you get onto my team. So those repeatable actions for the ambiguity questions are more about
they're more about how you broke down that ambiguity, how you resolved whatever was unclear to you at the beginning of the project. So as a hiring manager wanting to use a behavioural interview for this and asking about ambiguity, you should be... looking and assessing the candidate based on what level of scope they talked about whether it's task feature project or goals and initiatives and then you also been looking at the level of detail they give you whether or not
They have demonstrated some repeatable behavior. Okay. I think that's really useful advice for a lot of hiring managers that don't know how to do behavioral interviews well. Swinging it down to the other side, you talked about a little bit about how somebody can answer those questions.
How would you advise somebody to prepare for a behavioral interview? Yeah, I'm going to answer this question in two different parts, because I think there could be some of your audience that have a behavioral interview in the next week or something, and they're really... Really trying to get ready. What do I do? So I'm going to answer that one first just to give people some action items they can take away.
And then I think I'm going to give the answer, secondly, as someone who has more time to prepare and who can think a little bit more deeply. And I think that this first person should return to the second track when they get a chance.
But if you are under the gun and you're about to have a behavioral interview, then I think first, making a list of the projects that you have accomplished. And ideally, you're keeping this list as you go through your career. And if you haven't done that, I would recommend that you start. uh the people call it a brag document i like this this phrase yay me file yay me i did this thing i love that framing
So keep that up. So ideally you have a list of projects. And then you need to choose a favorite one or one to talk about that you think really demonstrates your... your abilities. And the advice I give people to choose this favorite project is you need one that is a sufficient scope. You need one where you were heavily involved and you need one where you made a large impact.
So sometimes you're, for example, like you're heavily involved in making a one-line change that had a big impact, but it wasn't the very sufficient scope. It didn't demonstrate a lot of actions. But if you were involved in a really big project that had a huge business impact,
but you were kind of mildly involved. You built a couple of tasks. That may not be a good project. So choose this project where it's intersection of these three different axes and prepare a story. And we'll talk about this, I'm sure, but prepare a story that talks a little bit about the context.
of what's happening, talks a lot about what actions you took, talks about the results that you generated, and then have some kind of reflection of what you learned from this process. So a favorite project. I can tell you like five nines. with confidence that you're going to get a question like that then you're going to get a question like tell me about a time when you resolved a conflict so you need to have a conflict story to talk about
And then the last thing I would say is spend a little bit of time preparing for this very first thing you say, which is usually some introduction of yourself. People call it the tell me about yourself, team A. So prepare that. And I'm sure we can talk about how you can do a great job preparing a teammate. Then spend some time practicing those. So I would record them with a camera or whatever with a friend and practice yourself telling those stories.
So I think that's like the, you know, the last thing I would say is prepare some questions for the interviewer. You're very likely to get questions at the very end of the interview about that you had a chance to talk to the hiring manager or the interviewer themselves.
So that's like your crash course. How can I get something that's really fast? And the reason that that's the ones I picked is because those are typically the ones that have high confidence that you are going to be talking about and at the beginning of the interview. And when you can set that initial first 10, 15 minutes where you're connecting and the person is saying, yes, this is the kind of engineer I want to hire.
much more likely to hire you than if you were fighting uphill for the next 20 or 30 minutes, trying to convince the person that you have the skills and past experience. So I think if you have more time. then it's more of an expanded version of what I talked about. You do need to identify work and spend some time talking about all the interesting projects and not just projects that went well, but also projects that didn't go well.
And then you need to align these. You need to identify what are the key contributions that you made inside of each of these projects. And that's what we're talking about here. about earlier, these repeatable actions, these inflection points, these times when you made a decision, time when you gathered information, time when you prioritized, time when you built something, time when you went and talked to someone, when you resolved a conflict.
a time when you talk to a customer these kinds of where you tested something and you made a decision so these kinds of key inflection points those are the things you need to identify in each one of these stories And then once you've identified those things, you should be able to align those projects with some key signal areas like we talked about earlier, whether it's empathy or ambiguity. And I have some worksheets that we can. you know, link to for the audience if they want to to help you.
categorize these stories that you've that you've built and that categorization is useful for just for your own sake but also useful in the interview so if you have a remote interview you can have the spreadsheet up over here and then you can kind of you know mix and match like oh this is a question about ambiguity let me go
figure out. Half the battle in the behavioral interview sometimes is just remembering the stories that you want to tell. So if you've spent a little bit of time categorizing them in advance, then that can be really valuable for you. uh then i would i would journal about these projects so now you've got some bullet points and some alignment with signal areas but spending some time journaling about what it is that made this project successful telling a story to yourself and you'll find um
some kind of flow there, some kind of organization, some kind of interesting way to tell the story. And usually I use, I would recommend people using that format that I talked about earlier. I didn't say the name at the time, but it's called the Carl format, context, actions, results, learning, learnings.
And that's great because it does give you this arc that's centered around what you did and what you accomplished. And that's a really good format for folks to tell the stories in the behavioral interview, but also to use as a journaling tool. And then I would say there's like the next phase, which is to get those key questions really nailed down. Favorite project, conflict resolution, and tell me about yourself.
If you can really get those things done well, then I think you'll be really well prepared. And then practice. So if you have more time practicing with yourself, videotaping, going with a friend, there are some wonderful... services that you can pay. They're not necessarily cheap, but you can get an interview with an experienced interviewer in practice.
Those are really valuable, especially if you're going to be applying at a thing. They have interviewers who are actively or have done many, many different interviews at those companies, and that can be great. Oh, I forgot to talk about... I think that last step is preparing questions for the interviewer because you know which role you're going to be applying for. And then if you do know anything about the company, then go ahead and adding that.
that alignment to the stories that you're telling so for example if you know you're applying at amazon then having all your stories categorized by amazon leadership principles would be would be what you want to do So that's a lot of things. I'd love to have it to dive into any detail. Cool. Thanks, Austin. So I think I'll start from Carl. For years, a lot of people have talked about the star format.
What we see as a difference, why Carl versus star? Yeah, so if you've done any kind of behavioral interview, perhaps if you put in behavioral interviews into Google, it'll tell you about the star method. And the star method is situation, task.
action result. And it is a pretty good format. It's been popular since the 70s to tell stories in behavioral interviews. And it gives you this nice flow where it sets up the listener with some context and then talks about what happened and then talks about the result. And if that's what you have and that's what you have for the interview in 30 minutes, great, do it. I think that is a great way to respond to interview questions. But I do think it has a couple of weaknesses.
that can be remedied with this context action result learning CARL format. And one of them is because the difference between situation and task is kind of ambiguous, especially as you get more more senior i don't know you know people can spend time trying to slice like when's the situation and what's the task and and people can end up spending too much time on the context because then because situation and task are both context setting
kinds of uh of responses or kinds of periods in the storytelling process so when you combine this into just saying you know what this person needs to understand the actions and in order to understand actions they need to understand the context so give them enough context to understand the actions i think that's a really helpful framing
I think more important is Star Formats leaves out an opportunity for you as an interviewer to share about what you've learned in the process of accomplishing this project. And that place of showcasing your learnings is both giving signal on your growth and your ability to have introspection and take feedback and take on action items from things that you've accomplished.
is also a place for especially senior engineers to to give me a little wisdom what is it that you want me to take away from this and how have you become a better engineer a better leader a better person because of what you did in this project and i think taking that opportunity to do that
can really help to cement your scope in the listener's mind. Yeah, I like that example there for the star versus car. I mean, when you start the situation task, particularly if you start talking about a leadership role. Situation task doesn't quite fit though, does it? Because the situation might be, I had these two people that were having a conflict. We had these two teams that disagreed.
There isn't really a task as such. We're just trying to make the organization work. The task is to resolve the conflict. How is that helpful in context? Yeah, absolutely. Cool. So going back to the questions then, the three key ones you picked out. Let's say you walk into an interview with me and I say, hi, Austin, tell me about yourself. How do you answer that? What's a good answer look like? Yeah, this is really valuable to prep because you get it a lot in.
You get it throughout the interview process, not just in the behavioral interview, but you get it when you're talking to a recruiter. You get it when you might talk to some hiring manager chat just really early on. You might get it in a coding or a system design of any interview. Sometimes just tell me about yourself.
That's a very good introduction when two people are talking to each other. So when you're preparing Tell Me About Yourself, you want something that's pretty tight and it's sort of an introduction and you want it to be short. And you want it to have three different parts. And some people have called this like past, present and future. And I like that kind of framing. So you need to set the first thing is to set up in the person's.
mind listeners mind who you are something like okay my name is austin i've been an engineering manager for x years And then I think it's nice to add a little bit of personal context there. And I love engaging, you know, mentoring and helping people grow, right? Some kind of personal hook there that helps the person remember you in a sense, right? They may be doing a lot of interviews.
but also gives them something to think about as they're asking you follow-up questions. So that's that first part. It's one sentence. That's the past.
The present framing can be something that is a big accomplishment that you have done recently, ideally recently. And this is something like... you know in my current team i've had an opportunity to build this project has produced this business result something like that and this is kind of like how many can i put some feathers in my hat as i'm talking about myself And oftentimes these are the kinds of projects that you want to follow up with later and you want to get a chance to tell later.
seeding those projects into the listener's mind is really good. And I think that I just want to emphasize that the key part here is not to describe the project in detail, but to give a quick understanding of what the project is. Sometimes it can be useful, especially for...
like mid-career engineers or junior engineers to talk about this tech stack that they were working on so i was built this project you know java and then it brought about this business result so that's the part that most people fail too failed to include. This is the same kind of advice you get on resumes when you're asked to add, okay, what was the performance impact or what was the revenue impact or what was the engagement impact for this project that you worked on?
So having that really helps to, one, set the scope of which you're operating and how much impact you have in an organization. And two, I think it grounds your work in business value or grounds your work in the real world. And a hiring manager is hiring you not to just code and use technology. They are hiring you to bring about some change in the real world. And they want to see that you connect those two things. So the last thing is this future.
And this is probably what most people leave out, honestly. They kind of, they sort of talk about themselves. They say something about themselves. They may have said what they've done or what teams they've been on. And then they kind of peter out. And they're like, they don't really know how to end. And it's a really strong way to end.
hit the ping pong ball back to the, to the interviewer is to talk a little bit about what they want to get out of the role or why the role is interesting to them or where they're going in their career. And what, what that is, I think is less important as than it, than it.
true for one thing that it talks a little bit about you helps to set up the listener to understand what you want to get out of your life what you want to get out of your career and that it's that it's it fits with the role so if it's i'm applying to a full stack role and i tell you that
I really want to be really interested in back-end optimization, and I really want to have a position that's like these things don't fit together, right? So the future-looking thing should fit with the role that you're being hired for. Okay, cool. So tell me about yourself. Do you want to do a favorite project? I did want to come on to a favorite project. And I was going to admit.
before I ask you about this, that this is one that I have messed up myself and I see a lot of people mess up. So maybe we take it too literally. Somebody says, tell me about your favorite project. Well, this was a cool project. Go off into the detail. But it might be a project that was something we did as a personal project. Might be a project we did in 20% time or whatever the equivalent is. So it might be a project.
that we did in between consultancy roles. And it doesn't demonstrate the things that we should from this. So first off, let's correct people. It doesn't have to be your favorite project. That's not what's being asked us here. It's tell me about a project.
that you have something and we want to phrase that how to give them the best answer often yeah totally so i i think that this question could be asked tell about your favorite project could be tell me about a project that was a great impactful tell me about something big that you shipped
Right. So this question could fit in many different forms. That's one thing to say. And then what you're getting at is actually a superpower of a behavioral interview candidate, which is to pause for a moment after you've received a question. and then try to understand what is this person really asking me and i think that this skill will pay huge dividends during a behavioral interview and so for example this one yeah they're not actually asking you like what is your favorite thing
What are you interested in? That's probably not what they're trying to get at. They're trying to get at, do you have the right scope and have you delivered the right impact for the role that I'm hiring you for?
And so if you align on that and you say, oh, that's what you're looking for, then you will go back and do what I said earlier, which is you will pick a project, which is at the intersection of something you were deeply involved in, something that was large scope and something that had large business impact. And the reason that you pick that is because those are the projects that typically demonstrate the most and the deepest actions, which are repeatable.
at the level at which you're trying to be hired at. So this is where you demonstrate the most disambiguation, the most conflict resolution, the most proactivity, the most communication skills, the most empathy, all those things. So this favorite project
uh is an opportunity really for you to shine you don't get that many opportunities sometimes in behavioral interviews to talk to me about whatever you want but just tell me about yourself and tell me about favorite project it's it's they're very open-ended questions and you can take the interview wherever you want to take them
And this is your opportunity to showcase the thing that you've done. So it's okay for this particular response to be kind of long. Usually this is an early question. So someone is the behavioral interviewer is willing to listen to you for some long period of time. And if you're organized, and we'll talk about that in a second.
Then it could be seven, 10 minutes. There have been some very senior engineers I've sat in interviews with, and it's been like a 20 minute. Basically, we just asked this question and we dove into different little parts of it. And they told me this big, long story. It was really fascinating.
And I think that if you do well and if you communicate well, this can be a sizable part of the interview. So let's talk about what that means. So I think we talked about context, actions, result, learnings as call format. And I think for a favorite project or any time when you're telling a longer story, it can be helpful to set up the context. That's good. But then think about what are the primary buckets of actions in this six-month project or three-month project?
You had more than one decision. You had more than one conflict. You had more than one opportunity to be proactive. And so if you bucket your actions into subparts, right? verticals, you can call them, or sections of the conversation, then that can go over really well with the listener. So you might say something like, Give some context. Oh, hey, I was at this bank. I was working on this authentication refactor.
something like that. I'll give a little context as to why you want to do this. Oh, there were a lot of errors in the existing code base, and we wanted to add these additional features or additional single sign-on or something, support, and we couldn't do that with the existing code base, so we had to refactor it. And in this project, there were three or four interesting parts that I got to contribute for. First was the design phase. Then I had a chance to, you know.
execute and solve some really interesting technical problems. Then there was this really complex testing phase. And then we had this follow-up part where we had to listen to users and make some significant changes. So already I've outlined. where I'm going to go, give me some breadcrumbs in terms of what's going to happen. And then I dive into each one of those. And there's like a mini Carl story for each one of these sections. So for this design phase, well...
You know, we talked about this is the setup of the team. There were this many engineers I was talking with. This is what the code base was like. And then I took these actions. I collected the existing feature list into a document. And then I proposed three different architectures. And then I sent that.
out to the team. We had some asynchronous communication. We had a meeting. We talked about this. We had built this. We needed to build three different prototypes to understand what the right choice was, right? And then at the end, we chose, this is the result part, then we chose blah because of you know these trade-offs right and then you talk
about some learnings that you had. And I think it was really great for it to give an opportunity to have all the people on the team to reflect on the architecture, not just the most senior people. So it was great to have a chance to send that out even to the junior engineers and have them take a look at it. So then you move on to the next part.
And I think it's really valuable to organize these responses into these sections because it's kind of like slides in a talk. Sometimes you might not know what level of detail to provide, and that's a frequent question I get in behavioral interviews. When do I stop talking?
Maybe I'm rambling on, you know. But when you organize it in these different buckets, then there's a natural kind of like next slide. So maybe people have gone to sleep on your previous slide in your presentation. But then when you hit next slide, they're like, oh, OK, I'm going to listen. Pay attention to what you're saying again. So when you say. something like, okay, and then the second part was, what was the second part? This hard build that I had, difficult.
technical solutions then they start to perk up and they might you know listen to you again so this kind of structure is both helpful in terms of communicating the actions that you've that you have done in this project but also good at keeping you focused and keeping the interviewer engaged in the response.
And then following up with that big result, like, okay, at the end of the project, we shipped this authentication service, and we had these business results, and we were able to add these additional features, and it didn't take very long because it did the refactor. And then you can provide some kind of like...
general learning about maybe this is your first big project that you led or something like that. And you can talk about what you learned. So I think that, that kind of Carl was the mini Carl's. for each of the sections is a really good way to structure long stories. So if I was interviewing Amazon, for example, I might go in there with, I worked on this project, it was six months long, this was a challenge we needed to face.
And there were four other challenges. One of them was dealing with a customer and I start talking about something that's tied to their customer obsession value. And then maybe I say, and another problem i have is nobody stepped up to own this part of the project was critical so i stepped forward and i start talking about meeting amazon's ownership value and then i might say the third part
We didn't know how to solve this technical challenge. So I went away, pulled some papers, researched it, learned all about that. And I found out about, I don't know, graph algorithms and how to do rooting across a graph. So we're demonstrating there, learn and be curious. So that's the kind of thing you mean is that you pick out the story, identify several other values. I'm afraid I don't know the meta ones, but...
picking the Amazon ones as an example. So you identify some of those, prepare your car stories and go in and prepare for that. Yeah, exactly. I think that's even more advanced. So what I was saying was just organizing based on what you have done. But I think that's even like...
Better way to approach it, which is if you do know that the company values certain things, making sure that those buckets align with some of the values that they talked about. That's a pro move. I love that, John. I'm going to steal that. And if they don't have...
And if they don't have those values outlined like Metal and Amazon do, if it's, say, a smaller company or a company that doesn't have that, or maybe the interviews aren't aligned, you can perhaps look at the job spec and get some ideas of what they describe as the values when they say...
You are a good fit for this role if, read through that section and perhaps pick out some stories and tie them to that. So we talked about projects there. I think another stumbling block a lot of people have is recency. So they always feel they've got to talk. And again, this is perhaps a fault of interviewers as well. So I've seen a number of interviews saying, tell me about your last project. And that's not necessarily a good example for this.
Should people talk about their last project? Does the project have to be recent? What's too old? Yeah, let's talk about that in two different parts. So the first part, which is tactical part, sometimes people will ask you questions and you may not have...
You may either not have an answer to that particular question. Tell me about a time when you had a conflict with a product manager about a feature that you wanted to build. Well, maybe I can't have that specific conflict. So what do you do in that situation or this situation?
That way where you don't actually want to answer the question or you would prefer to answer a different format of the question. And I think that you can, you should feel free as an interviewer to guide, as a candidate to guide the conversation towards where you think the interviewer.
will find your most valuable actions and your most valuable contributions. So for the first one, let's say you don't have a conflict story about a product manager. Then you say, well, I don't have a conflict story about a product manager, but I do have one about how I had a conflict with my manager. Let me tell you that.
story. So again, we talked earlier about the ability for a candidate to align the question that was asked with the signal that the interviewer was trying to acquire. And then you go and give an answer, which gives them that signal.
So that's the first thing. And then let's talk a little bit more about this specific question. Sorry, Austin, I hate to interrupt, but can I pull something out I think is really important for people there? Just to ask you another question, what is the goal when you're trying to interview somebody there?
Are you trying to rule them in or rule them out? Because I think that's a key thing that a lot of people miss. So apologies for intuition. I think there's a highlight. Well, I think this depends on the interviewer, honestly. So I think if you're a good interviewer, you are trying to assess. whether or not this candidate has repeatable actions, has the traits that will make this candidate successful in your team. That is a good interviewer.
I do not think all interviewers are good interviewers. And I think that there are many interviewers that are simply looking for mistakes, looking for reasons not to hire people. They might be insecure or arrogant themselves, and they, maybe those things are the same thing, I don't know. But they are...
They are just looking for opportunities, looking for reasons not to hire people. I do think that in any interview, you want to be careful with red flags, which is something that we haven't talked about. And we can dive into that maybe later. I think that it's very difficult sometimes to be a candidate in a position where the interviewer is looking for reasons not to hire you. I think that the way to handle that in this situation is to attempt to present yourself.
And those actions, those traits that we've talked about, those contributions that you made in the best possible light and try to give as many of those as you can in the conversation. Even if that means pushing back a little bit with the interviewer in terms of, hey, you know, I don't have that.
that answer or I don't have something like that, but I have this thing over here. And I think that that's all you can do. I would also encourage people that if they were to get a rejection from a behavioral interviewer.
This doesn't always mean that you're a bad engineer. It could just mean that either this interviewer is not very good and maybe you don't want to work there. Or it could also mean that you're just not a fit for this role. Maybe your traits are better in a different role and it doesn't mean that your traits aren't good.
It just means that maybe this role or this job, this company, is looking for different things than what you have to offer, and that's okay. Yeah, so to make that actionable, I think what I would recommend is that... Assume everyone has the best intention. Assume the interviewer is trying to get the thing. So change the question and say, I don't have a good example of the product manager one, say, but I have a conflict with my boss, as you suggested.
And assume that they are looking for a good signal and will be open to you playing back a slightly different scenario because they're looking for a positive experience. They're looking for signal out of this. And it's better that you give them a chance to find that signal rather than you just say well that didn't happen to me
Yeah, I like to use a signal exactly right so I like to use this It's not a very great metaphor, but I like to use this metaphor of jewelry store So if you are selling gems then you want to sell them from a jewelry store you have great lighting in the jewelry store all the gems are in glass cases you can see anything you want do you want to see the watches do you want to see the earrings do you want to see the rings it's all there for you to go check out in the jewelry store
versus say the mine where like a giant hill like yes there are some gems from my experience some like things that i've done in the past that are great but they're in the mine you have to go dig around and find them i hope you find them that's not a very good approach to being a candidate so as a candidate
When you have this opportunity to say, look, I have all of these interesting stories, which one would you like to talk about? This is an example of that, where we are redirecting the interviewer towards a story. In the glass case, that could be really interesting for them to hear. Yeah, I love that analogy because in the mine, they're covered in dust, dirt, mud. They're not polished. They're not clean. You're going to miss so much.
You can't rely on the interviewer to help you find things about you that are great. So apologies for the introduction. I'll let you continue the original one. Yeah, what was I talking about? I was talking about... There was a couple of original ones. Remind me what I'm saying. We were talking about the recency and the stories. Recency, yes. Okay. Yeah, so when we are talking about how recent stories should be, then I think that there is a sliding scale between...
recency and impact, recency and quality of the story. And by quality, I mean like how much of your... are you demonstrating? Many of these repeatable actions are you demonstrating inside of these stories? And so I do think the older the story is, the...
the less attractive it is from that perspective. But I would try to balance those two things. So if someone asks you about a recent project, for example, like what you were saying, if this is early in the interview and really what you think they're going to get at is, what's your favorite project or what's your most impactful project, if you think that's really where they want to hear and what you haven't had a chance to tell so far, then I would pick that story that really makes you shine.
It has a big scope, big impact, lots of repeatable actions inside of there. The kind of story that you would tell an interviewer if you were in an elevator and they only had a couple of minutes, like, what do you want to tell me that would make you hire me? I would try to go for that one first.
If they press you on something more recent, then I think it's fine. Then they're looking for what have you done recently? And then now they're looking for something different. Now they're looking for something about growth, something about career progression, something about how you're thinking about where you want to go and what you're learning recently. I think that there is the sliding scale. And you've got to like where, what's too old? I think this depends on level. A lot depends on level.
So if you are a junior engineer, then I think picking something or presumably you don't have that much to choose from in the first place. But also, I think something that is in the last six months to 12 months is going to be pretty valuable. I think if you're a senior person and you have 10, 15 years experience, I think going back to something that's three or four years old, I think is okay. I think when you can start to get into that like seven to 10 range.
Now I start to have questions like, what have you been up to? Why have you not contributed significantly in a more recent time? But I think in three to four years, I would expect that maybe there are really projects that shine every year. you know, two or three years, especially since these projects are likely going to be a year long projects. I don't know. What's your take, John? What do you think? You're killing my dreams here, Austin. Absolutely killing my dreams because my...
My favourite, my most fulfilling and the project that I have had the most impact with is getting on for 10 years old now. And it's... I would say a once in a lifetime opportunity. And yes, I've done impactful things since, but I probably won't get that same opportunity again in my lifetime. So it's one I enjoy talking about. There were so many great things from that.
period so many terrible things as well it had it had conflict it had challenge it had amazing innovation and i have so many stories from that and it was the most fulfilling and the most horrible lull of my entire career so well here's a great example of how we can apply the jewelry store technique to to to use choosing a project so sometimes people think that oh so i've been asked a question i need to answer the question
I haven't asked a question about this project. I need to provide a project answer. But in reality, you could provide kind of like a meta response. You could say something like, well, I have a number of projects to choose from. There's one from 10 years ago where...
Like you said, once in a lifetime opportunity can make it sound really juicy and interesting. And you say, well, I also have a couple more recent projects that also have these attributes, blah, blah, blah. And so this is the jewelry store approach, right? Someone says like, well...
it's valentine's day today so i'm buying this for my significant other i'm not sure what i have well do you want uh this do you want to watch do you want uh you know do you want to ring like what would you like and i think that offering that
choice to the interviewer is a way to ensure that you're giving them the signal they want to see and so they may choose that older story and but now it's there on them right so now they've they've chosen the older story they're not going to say something like well
has old story you know not i don't want to hire this person they made the choice it's their responsibility so i think that and then they may hear the older story and then want to hear the the more recent stories so i think that's an opportunity to apply this this jewelry store technique and still get the
chance to tell the stories that you want to tell. Cool. I think that's really useful for a lot of people. So the other one we talked about was the conflict story. How would you approach that? What's a good example? Because a lot of people, and maybe this is just from...
my experience interviewing primarily British people in our culture, quite often don't want to talk about conflict. Do I want to admit that I had a conflict with somebody? Do I want to say that? How much do I disclose? So there can be that kind of... awkwardness and maybe oh you know we disagreed about where to go to coffee because they don't want to admit to a conflict yeah yeah so they're trying to answer the question but not make it sound too bad because the conflict might be bad
So how do you handle that? What, what level of depth do you think people are in the conflict? How, how extreme can the conflict be? And what would be a good example of a good conflict to choose about conflict and how to handle it or how you handled it? This, like you point out, this one is very culturally dependent. So I will answer from my perspective, which is an American who lives in Silicon Valley. And I think there is this ethos of like, wow.
hush it out you know this problem and we're gonna work it work it through you know that's like uh that's the that's the ethos that exists here you may have to adjust this for what kind of conflict is expected in the culture that you're a part of
And this is a whole separate section of how do you as an interviewer assess someone's ability? And we do this a lot at Meta where they're coming from a totally different culture, not a Silicon Valley culture. How do you get at that signal to understand if they'll be successful?
in a totally different engineering environment. But back to your question about choosing conflict stories. You want to choose a conflict of significant scope. You want to choose one that has a significant impact. So for example, where to go to coffee, not super like business. It doesn't have a lot of business value attached to that. So you want to pick one where the stakes are high.
Ideally, you want to pick one where you were right. So I think you can tell a story if you're a good storyteller, especially if you're someone senior, especially if you demonstrated really good conflict resolution skills, which we'll come to in a moment, if you were wrong. But ideally, you were right.
in this story because I think it makes it sound better. And then one where you demonstrated conflict resolution skills. So what are conflict resolution skills? Those are actions that you take along the way of resolving the conflict. So things like I brought data, things like we had meetings, things like I had conversations, things like I was empathetic, things like, you know, I may have looped in this person or that person at the right time.
things like the follow-up was good so you know i didn't i had a good relationship with the person afterwards so those kinds of uh of actions are the ones you want to choose let's get to this other question like which so what is that like what's that conflict look like So sometimes people think that I'm asking for some kind of emotional fight experience, right? Where they had, there was, you know, a lot of emotions. That's not necessarily, that can be the case. Sometimes that happens.
And then if you tell that story, then now you're telling me that you can persevere through difficulties and you can work with difficult coworkers. And that's valuable signal. But that's not always a complex that exists. Sometimes conflicts are simply disagreements. oh, I want to use this framework. Someone else wants to use that framework. What are we going to do? It's not a heated conversation. You don't dislike the person. They don't dislike you. But there was some kind of...
decision-making process that needed to take place, and you were a part of that decision-making process. And so that's the kind of stories I'm looking for. When you're telling these stories, This is where I want a higher level of detail than I want for other stories. It's because I think a lot of the conflict resolution skills are in the drama of the interaction between the person. So in a favorite project story, I might not say something like,
Well, I was thinking about the people on the team and I thought about I should message this person, but then I should talk to that person in person. It's like a very detailed decision that you're making. A lot of times in some big story about a project, that level of detail is not really valuable.
but here that's where the good stuff is that's where the interest is that's where the drama is okay you understand how to work with people you understand what different people needed in this in this conflict situation and you took the action that was appropriate you know for that situation and why
So giving a little bit of soap opera kind of back and forth is really valuable for the conflict story. Oh, and I'll say one more thing, which is sometimes people have a hard time fitting this into a star or Carl format. Especially the result part, like what is the result of the conflict? And oftentimes what I get from mentees or from candidates is simply like, and yes, we decided on using framework Y for XYZ reasons.
And okay, that's good. That's part of the result. But really what I want to know is the result of the conflict resolution skills. So what's the state of the relationship after you solve this conflict? So yes, we got to this result, but if they never wanted to work with you again,
That's not exactly demonstrating great conflict resolution skills. So include in that result the people parts. What's the state of the relationship afterwards? Yeah, absolutely. As you like. So many people miss that. We'll get to, you know, we did X.
But there's nothing about, well, how was that relationship? Are you still talking? Are you still friends? Could you work together again? Or will you never be in the same room again afterwards? And that's so important, isn't it? Because we're going to do another project. We're going to.
tackle the next issue we're going to have to get together and share knowledge again and we're going to collaborate as a team again yeah cool so i was going to ask you about what's an insightful question to ask an interviewer A lot of times people will spend time prepping for behavioral interviews. They'll go online, they'll answer a bunch of questions, but then they get this one and they don't know what to do.
When I was at Meta, I would put some stock into what questions people would ask me. Let's get some poor questions that frequently I would hear. Things like, tell me about a day in the life of an engineer. It's pretty, you know, it's like we go to some meetings, look at some tasks, write some code, write some tests, kind of go to lunch. It looks kind of like any other part. That's not very insightful.
I think that what I want to see from a candidate is that they have given some thought to what the position is, what the company is, maybe who I am, especially if I'm the actual hiring manager that is going to be supporting this candidate. And so good questions are things that are acquiring real signal on whether or not it is a good fit for the candidate. So things like
Tell me about recent challenges that the team has experienced and how you resolve them. That could be kind of like more of a strategy question. This could be especially useful for interviewing at a startup where you're not really sure if the company has the right business model or whatnot.
you could talk a little bit more about what is expected on the team. So how have you, what have you seen that's been successful in the engineers that you have supported? What's the key traits of in the first six months of an engineer on your team?
You could assess the manager themselves. That can be valuable. This is a little dangerous territory, right? When you are turning the tables, it depends. I think this works better for senior engineers. I think it works better if you're confident in that you're right for the job. I think it could turn around into a reverse interview where you say things like, well, tell me about a time when you coached an engineer at my level and coached them to the next level. How did that work?
And that's a good way to get really good signal on whether or not the manager is a good manager. I think this kind of depends. You may have to assess the person's personality, the interviewer's personality, before you ask a question like that. But if you get the sense that they are an empathetic and a high-quality manager, they'll probably respond well to that. They want to be challenged. They want to have somebody who is challenging them. So those are kinds of good questions that are assessing.
in a deep and insightful way whether or not you as a candidate are right for the position or right for that manager i've had some interesting experiences there because every interview i've done in the last 20 years i've looked at how i manage on linkedin i've read their profile in detail
And I've come prepared to ask them questions about their role, their past experience, or things that they've posted on LinkedIn. And the majority of them have been utterly surprised that I know this stuff. And several of them have been completely...
unable to answer questions about things that they have on their LinkedIn profile. So it's been a real high up there when I've asked those questions. Yeah. Yeah. I think that's, then you have an interesting choice as a candidate and this sort of depends on where you are in your career and what you need.
Maybe you take the job because you need to take the job. Maybe that tells you something about the manager. It tells you something about the company that you're working at. Maybe that's not the company for you. In several cases, it's been the reason why I've walked away and ended the interview at that point and said, thank you, but I don't think there's a mutual fit here. It's been quite eye-opening. Pivoting slightly now.
All over social media, you'll see everybody talk about paying for the DSA style interviews paying for system design interviews. And you'll see many people say that. Those interviews are a bit of a waste of time because people are obsessed with DSA. And honestly, as a software engineer of nearly 30 years, I haven't.
spent very long actually inventing algorithms because they're in the standard library. They're in the tool sets we use. And most of the time using the right one from the toolkit is better than inventing a new one. However, you know, for people like me, when I've been at small businesses or smaller enterprises, just a few billion, not quite big tech size. We don't have the problem that big tech does. We're scraping for candidates or lucky to have 10 candidate CVs to choose between.
You're not facing that in big tech. You may have, I think somebody told me the other day, 18,000 for a single role. So you need a filter. So these things exist as a filter, but there's also this industry that's sprung up around telling people how to pass the DSA design interviews, how to pass design interviews.
And there seems to be a lot less emphasis on behavioral interviews. So how important are the three in perspective? How much does the behavioral interview drive somebody's leveling decision in big tech? Yeah. Well, great. Multi-part question. First, let me say that I think that there is some, it makes sense that there's some more focus on DSA style interview prep. I'll say that because oftentimes the first experience that, especially at big tech company.
The first interview is like a phone screen where you're solving a problem. So if you don't even get past that part, then you can't even prepare for the system design and you can't prepare for the behavior. So I think that that's one reason why that has become such a focus for people on social media or people in the industry.
the other reason is is because i don't think this is necessarily a good one is because it's easy to know if you are right so in a coding interview you can put the code in the computer especially really code you can then determine okay yes i did the problem correct and that's That's great. Any kind of preparation experience when you have a feedback loop where you know you're doing the right thing, I think that that is one reason why it's so popular and why there's so much focus on it.
is because it is in a sense like easier to prepare for right or more direct path to preparing for system design is getting there i think with alex hugh's book published in 2020 about system design interviews where he's collected his like bite bite go system design approaches and system design examples i think starting to systematize a little bit the the preparation for that interview and so i think we're starting to see more more structured approach and more conversation about that
I would say with behaviorals, there's a couple of reasons why it's not focused on. And I also think that that's changing. And that's bad. It's bad that we don't focus on it. So I highly recommend people. One is because it is hard to know if you got it right.
So if you're telling a story about yourself, did you tell a good story? I don't know. You know, did you tell it correctly? Like most people don't know. Most people have not been a manager before. And so they don't even know what a hiring manager is thinking about.
They might have designed some systems, like seen some systems and understand kind of how some technical trade-offs, how that works. And they've definitely seen the computer execute code correctly, execute coding correctly. So I think that this ambiguity level of what is a good response is another reason why.
People have had a hard time putting energy into preparing. To your question about how much they matter, they matter a lot. They matter a lot, especially when you get to senior levels. The way that a... an hiring manager is assessing your level is by understanding what you've done in the past. They're also understanding your ability to describe complex systems in the system design interview in particular.
Coding is not usually a place where we're assessing level. Honestly, the people who would prepare or who would perform the best on Coding interviews would normally be interns and people who are junior engineers. They just got out of school. They spent a lot of time preparing for this DSA. The senior engineers would sometimes actually perform the worst at coding interviews. But we would look to the system design interview and look to their behavioral.
And then especially at super senior level, so like the difference between a senior engineer and staff or the difference between a staff and a principal, that is not typically in a system design interview. Maybe for some specialists it is, but a lot of times the designing a search engine
Maybe they communicated a little better. Maybe they got to the quote unquote right answer a little bit better. Maybe they had some better trade-offs to talk through and more interesting experience to bring in that conversation at the system design level. But the difference between a senior engineer, I had this project, I was coaching one person. We executed this project. That story is told in the behavioral versus the staff engineer.
I was responsible for this multi-year goal for 10 different people on the team. I brought this person and coached them up from a junior all the way through a senior engineer. So that stories are just vastly different. And there's no way to get that level of scope in the other two interviews.
So behavioral interviews for sure would be where we would look as a hiring committee chair, someone who would review packets at Meta and decide on hiring them and decide on their level. We would often look to the behavioral interview as that differentiator. And I would also say that in 2025, there are two factors that make behavioral interviews really important. So one of them is the rise of AI. As AI produces more of a code, it solves more of the technical problems that we have.
then we need to engage with AI. That's communication. So we engage with AI with English language and your ability to describe problems and your ability to coach. In a sense, you're coaching a junior engineer when you're... working with Devon or some kind of agentic AI that's doing work, you are coaching a junior engineer. So your ability to communicate is really important and communicate technically. And then if more and more of a code is produced at this higher level of abstraction,
then more and more of your time might be spent doing things like coming up with ideas, being creative, being proactive, understanding what should be done in the business, being able to connect the business value of what you're doing as an engineer to the work that you're doing or engaging with others, right?
So I think that behavioral interviews are getting more important because of the rise of AI. And the second thing I would say is because we are in a time in the market cycle and there have been layoffs and there are many candidates in the market. Being able to differentiate yourself by telling stories and telling memorable stories about yourself.
That place to do that is in the behavioral. And so if you want to make an impression on the hiring manager, if you want them to come away impressed with you, this is a great opportunity to do that. You get to talk a lot in a behavioral interview. So whatever you want to talk about.
That's going to stick in the hiring manager's mind. Cool. Thank you, Austin. With that in mind, what are the three top mistakes that you've seen that people should avoid making in a behavioral interview? Yeah. I would say that the... Biggest mistake is probably not emphasizing the actions that you took. So we talked a lot about what are these repeatable actions that you have taken in the past. And so especially for mid-level engineers, they tend to describe the context.
the results but then they they they skip over this how did they get there and oftentimes they don't really know they don't always know haven't thought about how to spend enough time doing introspection to understand what made this project successful was it that I considered data when I made the architectural choice? Was it that I built this prototype? Was it that I ran the tests, AB tests in a certain way? And so emphasizing the actions, I think it was number one, number one thing.
I would say that picking the wrong project, we talked a lot about that. So if you are given this open-ended question about favorite project or most impactful project, and then you spend a lot of time talking about something that is not representative of your scope. representative of the level of the job that you're applying for, that's burning through a lot of clock time and not giving the interviewer the signal that they want to see. I think this other thing of not being able to...
which we've talked about already, not being able to identify the underlying signal that is being acquired in the question and then being able to adapt the response is one that is really common. So if you just. You can say things like, I don't have a story for that. Versus saying something like, well, I don't have that story, but I have this story. And then I would say that variations of what I said earlier, which is this.
first impression, what you say in that first few minutes, how you present yourself and you tell me about yourself. And then that first favorite project thing, if you're setting the stage and really building that rapport and establishing yourself as someone who will be successful in that first five to 10 minutes.
You know, that's a huge opportunity and a big missed one. I think a lot of people, a lot of hiring managers probably making that decision about hiring you in that first 10 minutes. Cool. Thank you very much, Austin. I think there's been a lot of really useful information there that will help a lot of people. I think we could talk for hours more and mine a lot more information from there and pull a lot more of those stories out of your mind and find a lot of value for people.
I'm sure you don't have time for me to sit and do that for the next three hours. So as we can't do that, how can people find you and how can you help them? What can you do for them? How should they reach out? Yeah, you can reach out to me by following my sub stack. I have a newsletter which is focused on behavioral interviews. And every week you'll get some...
reflection on how to better structure your stories or how to better choose stories or what interviewers are looking for, even how to be a better interview. So a lot of value added getting out of the Substack. I have LinkedIn. I also have a small YouTube channel if you want to go check it out. All about behavioral interviews. So follow me there. Perfect. Awesome. Thank you very much, Austin. Thanks, John. It was fun. Fun times.