FAANG Engineering Manager Behavioral Interview

Watch someone solve the faang engineering manager behavioral interview (medium) problem in an interview with a FAANG engineer and see the feedback their interviewer left them. Explore this problem and others in our library of interview replays.

Interview Summary

Problem type
FAANG Engineering Manager Behavioral Interview (Medium)

Interview question
Navigate common behavioral interview questions for engineering management roles, focusing on decision-making, team dynamics, and leadership challenges. The candidate must demonstrate their ability to handle complex situations, make tough decisions, and lead teams effectively while showing growth, humility, and technical understanding.

Interview Feedback

Feedback about Secret Zebra (the interviewee)
Advance this person to the next round? Yes
How were their technical skills? 4/4
How was their problem solving ability? 4/4
What about their communication ability? 4/4

1. don't sugar coat
2. pick difficult stories
3. use STAR format

Feedback about Hyper Penguin (the interviewer)
Would you want to work with this person? Yes
How excited would you be to work with them? 4/4
How good were the questions? 4/4
How helpful was your interviewer in guiding you to the solution(s)? 4/4

This was super helpful. Much of the advice was new and tailored to me, which gives me followup and solid things to work on. I love the focus on going good to great. Lots of solid examples on where I could improve.

The only growth feedback I have is I probably would have preferred to leave time for 1 more question (going through 3 questions total) vs some of the more structured learning. Maybe the interviewer could link to resources for some of this learning so more time could be on the interactive work?

Interview Transcript

Hyper Penguin: So thank you for your time. Um, we have about 1 hour and, uh, definitely we can go in a certain way. Um, I have something in mind, but why don't we start with, uh, you? If you could tell me a little bit about like what's the interview coming at what level Which area? Those will give me some ideas. And exactly how would you like to go through for this session other than, of course, we can analyze some more question and answer if you have anything else other than that.

Secret Zebra: Awesome. Yes. So, uh, I'm applying at [REDACTED] is the most, most upcoming interview, but in general, I'm applying to larger sized companies as an engineering manager. I think I'm a fit probably for normal or senior. So I'm applying to both. And this is my first time doing an engineering leader set of interviews. My background prior to a couple of years ago was all startups where I was a founder. So I guess in that sense, the investors were interviewing me. And then I joined [REDACTED] a couple of years ago. As an IC and then pretty quickly transitioned to an EM. So I have practiced being an EM at a larger company, but I've never interviewed.

Hyper Penguin: Okay, I see. I think, yeah, those are very good context. So you already have good leadership or management experience, and the interviewer who will be interviewing will know that already. So they might go a little bit deeper than for other average engineering managers. It's a good context. Yeah, thank you. Um, and, um, of course we'll go to— here is how we are thinking. I'm thinking is that we'll start with one simple mock interview question, then you will answer just like any other interview, and then we will analyze. And frankly speak, there are ways where we could So that analysis is the value-add, actually. You may agree or disagree with some of this stuff, and then we'll have more time to go through several other mock questions. Also, for each of those, you don't have to go too deep like the first one because we'll get some general things out of this first one. That's one way I usually do. Is there anything else you have in mind that you'd like to talk about?

Secret Zebra: No, since this is my first mock interview, I'm interested in kind of covering whatever comes to mind first for you. I think, you know, based on looking at what sent me to prepare, it looks fairly generic. Like they said, discussion themes, execution, measuring impact, team autonomy, cross-functional partnerships. So I imagine it's like relatively generic. So I trust your intuition there.

Hyper Penguin: Yeah, relatively generic. Okay, I think I got an idea. So let— so here is what we go through. So without giving you any, any idea so that you are not biased, just to see your current baseline, I'll ask you one question and you answer if, if you do— you didn't know anything else and it's just an interview date. So let me pick a question. I'll write down the question, uh, in the text box so that in case you have problem understanding, you can read from there. So question 1 will be, tell me about a time when you had to make a decision that changed the course of a project. That's the question. A behavioral question. Yeah.

Secret Zebra: Okay. Now let me think. The one example I have is from my time at [REDACTED]. There was a project that was started actually before I was hired. And the project was creating an onboarding system for [REDACTED] Studio. So [REDACTED] Studio is the software that creators at [REDACTED] use to make games. It's relatively complicated. So the idea of the onboarding system was to help people learn how to use [REDACTED] and get started. This project, the feature set had ballooned over the course of about a year, and as such had not shipped. It had one engineer working on it the entire time, largely alone, without pairing with anybody. And of course, this set up a recipe for management not being happy with the project. When I came in to lead the knowledge team at [REDACTED], they also partnered me cross-functionally with this project. Which is related to learning, so it's related to knowledge, but it was on the studio team at [REDACTED]. And I came in and assessed, you know, the engineer that was working on it, best practices that were— engineering best practices that were not being used. I interfaced with the product manager, and there was a clear gap between the product manager and the previous engineering manager on timelines. And I worked with the project manager to really cut down the feature set based on the engineering timeline of adding those features. And ultimately, this changed the course of the project in terms of the feature set nearly halving, but also us being able to set a reliable timeline, which was 2 months. Into the future, uh, where we did ship, um, and also created a roadmap, um, that really prioritized what features we thought would be more impactful and we would learn more from. Um, so ultimately we did ship on time in 2 months. Uh, we did increase the stickiness of new creators using Studio, um, by a couple of percentage points, uh, which was higher than our goal. Of 1 percentage point, which translates to tens of thousands of users, right? And the creation velocity of those users also went up, which was a sub-KPI. So people were creating things faster. So ultimately, we got the timeline of the project under control.

Hyper Penguin: We shipped.

Secret Zebra: We hit KPIs, even though we didn't ship the full dream of the design and product team yet.

Hyper Penguin: Okay, thank you. And any learning out of this?

Secret Zebra: I think the biggest learning that I had, you know, I had come in and cut timelines before, you know, running startups. We were always making tough decisions. I actually think a learning that I didn't expect out of this is how important it is that an engineer isn't working alone on a project for so long, right? This person hadn't paired with anybody. They had certain people they could ask for advice within their team, but they certainly didn't have a peer on the project. And that was one of the big changes that we made. I said, look, this project is going to be tough unless we have at least 2 engineers on it. And so we got 1 more engineer on it, and it was multiplicative, right? Those 2 engineers did 4 times the work because, you know, this poor guy was probably lonely, didn't have a ton of motivation or anyone to work with on it. So that really changed the morale and kind of engineering foundation the project just by, you know, giving someone a peer.

Hyper Penguin: Okay, I see. Thank you. So let's analyze your answer. So yeah, thank you, uh, for your answer. So let's still go through this. So the question was, tell me about a time when you had to make a decision that changed the course of a project, and you actually answered a time where if you would not be there, the project was going in a different direction. So you came and you changed the course of the project. So the answer is to the point. Um, the format of your answer, the way you started, I liked it. Is there— this is more from my time at [REDACTED]. By the way, are you familiar with the STAR format?

Secret Zebra: Um, I am. I don't know that I used it just now, but I am familiar with it.

Hyper Penguin: Well, you loosely followed the structure, which is perfectly fine. You can even be more structured on it, but what you did is, I would say, is good. So the— we will go with this STAR format. I'll just write it down so that it's a note for you. STAR methodology of answering the Methodology. So the first one is S, which is situation. You usually— so what happens is you have to know what's your goal to answer this question in terms of time. So usually that will depend on if your interview is 30 minutes, 45 minutes, or 1 hour. So when 1 hour, you take relax, you take a little bit longer time. When it's 30 minutes, you try to answer as quickly as you can. When it is 45 minutes, you go in a pace, not too much, not too late. So you will know it ahead of time. I'm assuming mostly it's 45 minutes.

Secret Zebra: Yeah, I think that's safe to assume.

Hyper Penguin: Yeah, right. So the situation, you— if that is the case, you usually want to take to answer a behavior— these are behavioral questions, right? There are different type of questions, we'll talk about it. But behavioral questions are questions where you say, tell me about a time, something from your experience. They want to know that happened or didn't happen, but from your experience, instead of a, a question, general question, what is your name, How many years you have worked or what you want to do in future, those are not behavioral questions. Behavioral questions is from your past experience. They want to know something. Tell me about the time. So these are mainly the heart of the main interview questions when they are hiring an engineering manager. Even if they are very good at other sessions, will matter less. And if they are not good enough in this section, they will get filtered out. This is kind of the primary qualification criteria. You have to be good at answering the behavioral questions. Now, in a session of 45 minutes, or even maybe 30 minutes, and definitely in 1 hour, uh, there will be a few questions that are not behavioral questions, other things. But majority of the questions, at least the interviewer would like to ask you 3 behavioral questions. Maybe 5, in some cases even more, 3 to 5 questions. So just to know your situation, I am, and so on, so that they are able to gauge you properly. So in that sense, you want to answer it in general within 5 to 7 minutes, each of the answers. So that's number 1. Have it mentally in your mind is that the time you are going to take approximately 4 to 6 minutes If it is a project, then you have to discuss as much as you can, which is usually 3 to 4 minutes. But that is if you are not interrupted during the answer, during your session. What does it mean? That means like, I do I asked you a question and you answered in about approximately 5 minutes, and I didn't interrupt. You finished, and then at the end I asked you a follow-up question, right? So that is without interruption. But sometimes what will happen is that, uh, you start talking in 1, 1 and a half minutes or 2 minutes, then you say, what about this, this, or this? Conversation happening. But if you only talk your view, that would be that 4 to 6 minutes in a particular interview. That's your on an average. Some questions will take a little bit longer. In that case, some other person will be the food sometime, you know, and so on. And those are something the interviewer will usually give you hint. Okay, so now that's a general guideline. You don't have to follow it very strictly. It's a general guideline. Now, considering it's a 45-minute interview, 4 to 6 minutes longer, ideally 5 minutes. So you put for each situation about 30 seconds. About— it may be in certain cases, if the context, if the question is very specific or a little bit complicated— tell me about the time when there was 3 people, one junior for other team, and you joined only 3 months, you know, like that very complicated question. There, to unfold the context or tell the context, you may need a little bit more time. But apart from those exceptional cases, in general, you should be able to, yeah, tell the S, which is situation, in around 30 minutes. What do you cover in this 30 seconds? Sorry, around 30 seconds. So basically, within the first 30 seconds, you don't want to give the answer of the body. You only give context. Now let's go to your answer. You see, let me give an example from my side. That is what you usually want to say is when— in my last company, two company earlier, one year earlier, and so on. Where— like, where were you working at that time? let's say when I was working at Salesforce in San Francisco, or when I was at [REDACTED] in [REDACTED]'s headquarters, or you don't have to even tell the geographical location. When I was working at [REDACTED] is good enough, which is what you did. So that's one part of the context, right? But then you also want to give a little bit more context other than where, where you are. If possible, you can say, I was in a new team, which is kind of what you say, is that a project started before I was new in it. Within 30 seconds is better. So within that, inside, and in this context Do you want to also talk about your manager who gave you a responsibility, or the team member, or Scrum Master, or something like that? So basically giving an idea about the team or your role in the team so that the interviewer can judge you, evaluate you based on the— at which you had to do the action or the steps that you took. So the more they get the context like you, you can say it was 6 years back when I was there. So they know that you are a junior engineer at that time and you had to do something bold at that time. So that context gives the clue to the interviewer that you— so that they evaluate you within that proper context. So that's why where you worked, a little bit about the team, like team size or the company size, and your relative position within the team. Like you are a veteran in that team, you are working there for 2 years, or you join Nimu and it's a 5-engineer team, others are front-end engineers, you are back-end engineer, you know, those are kind of context. Or others are engineers, you are the engineering manager, you are the test engineer, or you are the product manager. So giving that context as a starting point, around 30 seconds. So you, you may have more information that you can give in 1 minute That's not necessary because time boxing is important here. Remember, 4 to 6 minutes, ideally 5 minutes, right? And you want to spend more time on the body or main body of the answer other than the S-T-A-R, STAR, right? S-T and R, these 3, less time. A is the action body. You want to spend majority of the time there. So that's why 30 seconds, within that, as much as you can give, good enough. So you covered about 10 to 15 seconds. 15 seconds, let's say, it's good enough. Like maybe one more line is okay, but this is okay. Now next trick, you talked and The volume is fine. I have no recommendation to make any adjustment here. You're good. The way you are talking in generally, the answering, just continue this. No, you don't have to worry about it. I'm assuming it's your natural, like you are not pressing yourself to talk in that tone and so on. So it sounded very natural. You're good at that. So many people actually, I give some recommendation in that area. I have no recommendation for for you. You are good. Now after the 30 seconds, mentally you are now moving from S to T, the task. Task is— here again you don't give the answer, you kind of reiterate the question, which is what you did not do. But that's okay. Sometimes what people do is S and T, they match this both together as one, which is situation or situational task. So you kind of— if I evaluate you in DEX format, you kind of skip T or you merged T and S together. So what do you want to say in task? In task, there is one psychological thing that works well during interviews, which is the question that the interviewer is asking. If you use the exact words, some of the exact words that the interviewer has asked in your answer, the interviewer feels, the questionnaire feels that you are answering to the point. You are answering exactly what they asked you to answer. Although even without using those words, in my case what I asked, you did not use those words, but you still answered my questions to the point. But some interviewers feel more closer to the answer when at least a few words from their question you use. So yeah, that makes sense.

Secret Zebra: I actually even noticed just, just, you know, listening to myself reflecting, I was like, uh, you know, I don't think I mentioned the exact decision or decisions that changed the course, at least not with those words, right? And, uh, yeah, so that makes a ton of sense.

Hyper Penguin: So for example, in this question, you'll have to find out which are the words that are a little bit more vibrant. So tell me about a time when you had to make a decision. So decision is a vibrant If you say it, interviewer will know. Anywhere if you use decision, the word decision, interviewer will know you are talking about the decision of this word from this sentence. Change is another one. Course of a project, or simply project. So these are some vibrant words within this sentence. So let's say you possibly have used the word about, which is also in here, or time. but those are less vibrant words. Even if you use those, the interviewer will not notice it, that it's from the question that they asked. But they will subconsciously will be able to recognize it if you use the word decision, change course, or project. Sometimes you can even use exactly the words course of a project, but sometimes maybe you don't want to use it to make it too obvious, like you don't want to make it too obvious. So then go very close and use 1, 2, or 3 words from there that I am on the right track of the question, answering in the right track. So that's one thing. Um, so in the task is a good opportunity for you to answer in that way. For example, in this case, one of the thing you could say that from my time at [REDACTED] project started before I was hired, you can say that And now I'll tell you, uh, I'm going to tell you how I changed the course of a project while onboarding robots for the first time. So I am going to tell you how I do everything, which means you are not answering it, you are saying what question you are thinking of. So task is like problem statement. So the interviewer already told you the problem statement. You are reiterating the problem statement. That is task. So you gave context, then you say, yes, now I am going to answer you what you asked. That is task. So again, task is you can get it done in 20 seconds, maybe, maybe 30 seconds, but usually 15 to 20 seconds. You should take even less than So within situation, try to keep it below. Let's say you took 40 seconds in situation, 20 seconds in task, that's fine, right? Something like that. E for task, again give 1 second more. So again you are giving an opportunity. Now the new paragraph, this one is A. A will be action. This is your actual answer that you already gave, and you answered it very well. Um, when you onboarding, what was the complication, the scope, you tried to understand, you talked to the product manager, and so on. All those are part of the body, and I found it very clear what you say. Um, the length of action um, can be 80% or even 90% of your answer. So maybe approximately 4 minutes, let's say 3 to 4 minutes is fine. In certain cases, it may go up to 5 minutes, so you have to figure that out. But 3 to 4 minutes, the A, action part. Now, one thing you want to do, it's a story, right? Like All these behavioral questions, you are actually telling a story that in that time there was something, I had this problem, then I figured I should do it, and this was the result. It's a storytelling. So these, you have to have a lot of story ready before you go to the interview. So maybe 10, 10 story you can have ready, maybe 15, maybe 20. So depends, because, and not All the questions will be common, that will be— you already remember what you did in your career, these stories, right? But you have probably hundreds of stories. You don't want to write down or rehearse all those hundreds of stories, but 10, 15, 20 interesting stories in your career. Like, this is one story where you went and then you changed the course of a project. It's a story. Like this, you should have some, maybe a dozen or two stories ready.

Secret Zebra: Hello?

Hyper Penguin: Hello, do you hear me? Yes, do you hear me? So looks like somehow the text probably went away. I don't know if you were able to copy it, otherwise we have some good things there.

Secret Zebra: Oh, weird. Yeah, I still see it, so I'll copy it right now.

Hyper Penguin: Yeah, you copy it right now so that we don't lose it. Okay, yeah, all right. So that is now the start of the action. Another thing you want to do in the— let me make the action or the body of the story that you are doing a little bit tough. So this is one important thing where you are an IC or an engineering manager. You have to show that the situation you faced was not an easy one. It's a hard one. Why? Because if it is an easy one, maybe they need to hire another engineering manager with lower pay than you. The reason they need someone experienced like you is because you can solve hard problems consistently over time. So these stories or examples you are giving, you have to show in one way or another in that action, in the body of the answer, the 3-4 minutes, that it was not easy for you to solve it. So now when I was listening your answer, I felt like it came naturally to you. It was obvious that you will say why it is this and that, and you will add more resource and change it. So it didn't feel like you had to work hard, there was a chance that you would fail, you are sleeping, or the team would fail and you have to rescue and so on. But you don't want to make it unnecessarily too difficult or too hard, just a little bit of balance, not very easy. So that's your selling point, is that this is why you need people Engineering manager really can— that makes sense.

Secret Zebra: So in my answer—

Hyper Penguin: oh, sorry.

Secret Zebra: Yeah, so in my answer, maybe I made it sound a little too easy.

Hyper Penguin: Correct. Okay, cool.

Secret Zebra: That makes sense.

Hyper Penguin: Yeah. So you want to show some uncertainty, that you had some confusion. I didn't feel like you are confused. You went, you methodically checked, and you did the next step. That means based on a skill and experience, it was easy for you. And you want to pick stories where, if despite your experience and skill, it was not easy for you, and hence because you are able to learn from it, you grow as an— with every story, with every experience, you grow as an That's what you want to demonstrate. Versus if it is easy, you didn't grow, you already knew it earlier, it was within your capacity. So that's the thought process, but you don't want to say it loudly, verbally like this, but the intention is there, pass that message.

Secret Zebra: So, you know, I tend to sugarcoat things, and I, I think there were hard decisions involved in that that I could have talked about. So that makes sense.

Hyper Penguin: Yeah, yeah. So this way, what will they see is they will see your resilience, that you struggled, you are confused, you knew that should I be so hard on the team, but then if at times you have to be hard on the team, I'm a leader, if I have to make— set the bar high, right? And all these things. So like as if you are gauging the pros and cons of your decision, and then finally you make the decision. Is that you also had second other thoughts in mind? Is that, am I doing it right? Maybe I should double-check with my manager, or maybe let's see what others are writing in the Slack channel. Is it too contradictory or too much rebellious, the decision? You know, those kind of things. But then eventually I did what's right for the team or for the project or for the company. For our business or our customers. So that confusion helps, but slight, not too much confusion. Then that goes against you, is that you may not be able to make hard decisions. If you show it too much, they will say, okay, this time probably you gathered the courage to make the right decision, but who knows, maybe next time you'll not be able to, you know. That's the, uh, problem. Yeah, now that is it actually. And apart from that, I think your body, everything is good. Yeah, maybe one more thing you can bring is because you are an engineering leader, and so you have to show that you are a people person. Of course, you are a technologist, you are a good engineer and so on, but another thing we engineering managers or engineering leaders are, are we are a people person. We focus a lot on others in the team, not just engineers— product manager, DevOps, CEO, customer, health coach, receptionist. So you want to show that you are interested about others in the team. So I think you already brought it in your answer, like you are talking about talking to the product manager, feeling a little bit, um, sad for the lonely engineer. Those are good signs that You are a team player. You are not only thinking about yourself, you are thinking about others. Bring those— you already brought those two characters in your story, right? If you— if I think in story, you are three in that character story: you, the product manager, the engineer. And if you get an opportunity, bring maybe one, two more. Like, I double-checked with my— the chief marketing officer was talking about quality. Something like this, more like, say, and engineering engineer for whom you had to do it, and a little bit of focus was on the product manager. You three, focus should still be this, but multi-line mention, characters. Company or the customer shows that you, you think wide. You are not vertically deep inside that problem only. You are horizontally thinking about managers, the CEO, the customer. So introduce characters. This shows you are team player or you have more self-awareness around you, what's happening. So try to bring characters once in a while. Like, I and that engineer were talking, and then the other 3 team members in the team, they were cheering us. So we already know there are other people also in the team, you know, like putting your— you are noticing others are supporting your conversation or your decision, so there are other people, that type of thing. So bringing some focus outside of you Main focus will be always on you, right? What you did, that's what they want to know. But a little bit of showing that you are a team player, some way or other. Maybe not all questions you'll get a chance to do that, but whenever you get a chance, do that in the A action. But apart from that, I have— I don't have much to tell you where to improve in the A side. And then after A, the last one will be R, right? And R is for result. Result. And again, between A and R, give a 1-second pause. Often they may ask you the question here, uh, the interviewer, like, but what happened after that? Or something like that, which you are— the fact that the question is for you, so you get a chance to tell what you are thinking to say in the R. But let's say they don't say anything. Again, once again, you wait. Then you say the R. R is the result. You say the outcome of your decision or the story. If it was successful, then say, so this way it worked out well for the team or for the business, or we were able to meet, which is what you told. So we hit the KPI, we delivered it in 2 months, and so on. So those are the results. R. Although, because when you say, you said as part of the action, you didn't give a gap, it didn't sound like an R. But I think your tone changed at the end, that you are in a conclusion mode. That itself tells you where of the R side. So I could catch that your main answer is done and you are now recapping or reviewing or putting a summary, which is actually R. And R also, about 30 seconds is fine. Result. So what do you want to do here? About 30 seconds. Um, summary, summary, review, pass or fail. Pass means did it work or it didn't work? Because let's first take one pass. In this case, in your case, it was a pass. It was a success. So the whole team, the project moved on from there in the right direction. So that's past. Now there will be some questions interviewer will ask you. They want to know your failure. You have to have failure, otherwise you don't have humility, right? You have to show in some cases failure. And sometimes you probably want to— if they ask you 4 or 5 questions, maybe only want to talk about failure one or 2 of them, no more than that. Otherwise they'll say you fail very frequently. That's not the impression you have to give either. But failure shows humility. That's why 1 or 2, maximum 2 and minimum 1 failure you want to answer in some of these stories that you're showing. Now, past time is past. It's just say this is what I did. Failure must stay for me. Because you passed, like it worked according to your plan. Still, I asked you, is that okay? Was there any lessons you learned from it, right? So, and you say, you can say when you pass what is, what lesson you learned, or did you grow as a leader out of this story or this situation or this decision. But for failure, it is a must, otherwise they will think you will repeat this failure. So anytime you— and so I will not be making the same mistake or something like that. You don't have to exactly say I will not make this mistake again, but you have to give that impression that yes, I failed, but as part of the failure, as I was able to identify the failure, I learned from it. And because I learned from it, I grew as an engineer or as an engineering manager or as a team player. Which means, what do you mean by you did grow? Means I will not make that, repeat that mistake next time. I will be better for similar kind of problem. So that's how we grow, right? So for failure case, definitely you have to tell your lesson and that you do, you Give that impression that you are not going to make that mistake again, you have learned from it. So D, C, R, result, summary. Um, here also, in case you missed to put in the task one or two words from the question, this is another chance in the R side when you're summarizing. They address the original questions like, this is how I changed the course of a project, or how I tried to change the course of a project, although it didn't end up the way I wanted. But I learned from where I could have done better, so from next time I didn't make the same mistake again. You know, that type of thing. This is more or less the format.