We helped write the sequel to "Cracking the Coding Interview". Read 9 chapters for free

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) dont sugar coat 2) pick difficult stoires 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— 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 is different compared to if you did it 6 months back, because by now you have a lot more experience, right? So this 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. In between, give a 1-second pause. So there are some advantages of it, which is if you give a 1-second pause, that's an invitation to the interviewer to interfere. Like, You're just giving a pause, you're giving a chance. Because often an interviewer has something in mind, but he is waiting for you to finish speaking before he can ask you a question. He doesn't want to interrupt you. Now your speaking will finish after 5 minutes, so in that case the interviewer has to wait 5 minutes. Instead of that, you give— if within these 5 minutes, if you intentional pause. So the interviewer can take advantage of this. The first pause will be between S and T, the situation and task. How long? 1 second. 1 second is fine. Like, which is, the interviewer can clearly understand that you had a full stop here and you are starting a new paragraph. Sometimes these pauses will be also for you to catch up breath. Let's say in the action or body, you cannot talk for 3-4 minutes continuously. After 30 seconds, minute, maybe you take a pause. So that catching up breathing for you is also an invitation to the interviewer to ask you a question. This is how you're giving me time. So it's kind of like giving you an opportunity to ask me question or interrupt me or change the course of the question, whatever they want to do. Okay, so that's one. Now next is T. T is 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 the question 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 are 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 a— 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. Uh, any particular question on this format?

Secret Zebra: No, I, I asked them as you were saying it, so that sounds perfect.

Hyper Penguin: Yeah, okay. So now there are some questions— some interviewers, they know that candidates know the STAR format. So sometimes they don't— if you are too obvious on that format in your answer, sometimes they don't like it. So as you answer more and more questions, you will, you will be able to pick hints from the interviewer's question. The first one, you gave the specific STAR format. Did they feel uncomfortable or not? If they feel uncomfortable, maybe in the second one you don't follow the structure that strictly. That they understand it is a start. So it's not, it's not very easy to pick it up. Sometimes interviewers will give you hint, is that, are you saying it in a too structured manner, in a too artificial manner, and so on. In such cases, immediately change it to natural style. No format, no personal response. So, but in majority of the cases, in majority of the companies, majority of the interviewers, STAR methodology works better. So it's a definitely a probabilistic game, and in some cases if you don't follow STAR methodology, you may get negative points. So that's why you say the whole spectrum, right? Yeah. So that's why it's a safe bet that you follow STAR methodology at least for the first behavioral question. And unless you get a signal that the interviewer is giving you a signal you're not liking it, you have no reason to change it. As soon as you get a signal, from second onwards you could change it. Otherwise, by default, STAR methodology is a good one for interviews. Okay, so now we have some time, so one of my recommendation will be— oh yeah, there is one thing um, where you can differentiate yourself in the body. A action, which is what you answered, is what a good engineering manager will do. Now there is something a great engineering manager may do, not just a good one, which is demonstrate your understanding of leadership or the subject matter that you are talking about a little bit more. In this particular case, it is a behavioral journey, right? So you might be more than happy. So what I would add on top of the answer that you it in your body, which is what I would say is that there are a lot of scope and a lonely engineer and the product manager, they were not being actually making the decision of whether they should cut the scope or not. But once I came here, I thought that, oh, 'With this scope and this, this is very difficult,' or 'This is impossible,' or 'This is not the ideal way to do.' This is what you are— on top of it, you can add one layer, which is, you know, there is Iron Triangle of software development where in the center of the triangle is quality of the code or product. Within the three triangles, scope, resource, and schedule. What I figured in this project is that the scope is so large and the resources are— and there is a deadline. Which one to sacrifice, because quality cannot be sacrificed, which is— and you have to choose between one of those three to take off. Oh, okay. If the schedule and resource alone cannot solve the problem, even if more Still, that may not be enough for us. Scope needs to be cut. That's right. Now that you see, they know that apart from this, you actually know the theory of Iron Triangle of software development. Let's— let me tell you a few other theories. This is one, but the problem with this one is that it will take you 30 seconds to 1 minute more to answer. So decide when to use it. Like, if you have a lot to answer in your body, you may not have time to introduce it, add it to that layer. So use your judgment when you want to use theories like this. So another theory is, let's say they will be asking you, tell us about the dysfunctions of a team, or a time when you have to face dysfunction regarding team. How you build high-performing teams and so on. But there is another way to answer it, a better way, which is that not everyone will be able to answer. That's the difference between a great and good, uh, candidate. If you are a great candidate, you can bring something like this, is that the management guru Patrick Lencioni described a similar problem, or they answered this in a book called Five Dysfunctions of a It's a very well-known book, Patrick Lencioni. And in that book, he talks about a pyramid where there are 5 dysfunctions a team can go through and how you overcome it. And the foundation of the pyramid is trust— trust between the team members. And then trust, accountability, commitment, all these things. Yeah, result is at the top. So you can take a quick YouTube video look, it will take 5-6 minutes, you can review. But If you answer this way, then they know is that what you are answering is not only just from— they have read the book, you will not know. So In majority of the questions, you may not be able to give reference to it, but this is just one way. This one I'm telling you. Another, let me tell you, is they will say, um, how do you interview? How do you find the right candidate? So you'll easily say what you look for a candidate. But again, you can say there is another book from Patrick Lencioni called The Ideal Team Player. There Patrick Lencioni talks about, other than the bread and butter, let's say coding skill or whatever hiring for. Every candidate has to be an ideal and smart. And then explain what humble means, explain what hungry means, and explain what smart or people smart means in that context. And then you are again giving reference to a book. Similarly, another one, One Minute Manager. Similarly, another one, Peter Drucker. If you give reference that Peter Drucker was saying is that strategy, culture eats strategy for breakfast. So they know that you are a well-read person, you are a well-known person, you understand the leadership, not just execute as a day-to-day by gut feeling, but you actually have theoretical understanding or study or research, or you add seminar, you read books around it, you are passionate about this topic. That will differentiate a good manager or leader from a great manager. Why? Because when you run a team, your people, many of them will not know these theories or these books, so it will be easy for you to influence them. Or your peers will not know, and when they will know you are making decisions based on frameworks like these, they will be— it will be easy for you to sell. They will easily take your lead. Them and they agree with you. And that feeling, if you can give during the interview, they will know this is something, you know, someone we need in our team, in our company. We don't have anyone like this. I need this person. That's how you will become great to them rather than just someone. So I'm just giving some ideas. Yeah, okay. So, um, we still have some time. Why don't we go through Another question and then see if we have time left or not. Or do you have any other questions?

Secret Zebra: No, this is super helpful though. You know, I just, I just read up a bunch of advice and, you know, most, a lot of this advice is good and new. So, so yeah, that was very helpful.

Hyper Penguin: Thank you. Yeah, thank you. Okay, so then another common question. Hmm. Tell me about a time when you had a good performer who was not a very good team player, your direct report, and how did you handle that, engineer?

Secret Zebra: So about 8 years ago, 9 years ago, um, is when we started growing the team at a startup I founded called Common Sensing. And, uh, we manufactured a combination software-hardware medical device. And one of our first hires out of our, you know, 4-person founding team was a lead engineer. Who was amazing at that early on, but as the company grew, became clear that this person wasn't a good team player. They continued to do amazing engineering work, but collaborating with other engineers and ultimately their engineering manager who we hired, was not something they did well. So any questions about that?

Hyper Penguin: No, I think that sounds like a good example. Yeah. Okay.

Secret Zebra: So ultimately, I had to figure out how to manage this person. I wanted their engineering skills, and they were still contributing heavily to the company. They had a ton of historical knowledge about the technology we were using. And so we— both me and my founder met with this person on separate occasions. And I think part of the reason for this is that I was directly in the managing chain for this particular report, whereas my co-founder was not. My co-founder led more of the design side of the company as opposed to engineering. And so he was able to have a frank conversation with this engineering leader as more of a peer, even though he was still a very important person in the company. So I worked with my co-founder to discuss with this engineer the issues that he was having, and they were able to convene on some ideas for solutions. That ultimately they brought to me, and I was able to execute those over the course of a few months. And those included some mediation with a couple of the, the engineers that this person had the most difficulty working with. It included some self-work that this person did. I think a big part of convincing them to do that self-work was showing them how the lack of teamwork was actually affecting the company and their coworkers and the direction of our technology. So we were able to convince this person to do that self-work. And our cycles, our 360 review cycles, that we implemented at that company were done every 6 months. And 6 months later, after we had started this process, this person's 360 review cycles went up, you know, from about 2 out of 5 to about 4 out of 5. And, you know, anecdotally, we also followed up with some of the people that had the initial complaints And they said it was going much better. Meanwhile, we continued to get the strong engineering performance out of this person as they became a better team player.

Hyper Penguin: Yeah, okay, good. So this is another good example. Let's see, you again told the S, the Situation 7 EQS. That. Um, the task, you didn't say much, um, but that's okay. You use the word team player a few times, so this is good. This was in the original question. You didn't use the word handle. There was easy opportunities to use that word in certain questions, but anyway, that's good. Um, that's no big deal, that's okay. I think the separation from 'is' and then you moved into the body. You didn't say the 't' much, which is okay. Was clear, the separation was clear, and then you went to the body. So within the body, I think you are, you are again good. I would probably add one more line on, on the responses that you gave. The line is that it was a difficult situation to be in. This is that same thing, is that it's not easy. So you actually laid out all the context that was clear. Your argument as a clear statement so that there is no confusion that it was difficult for you. There is a possibility the interviewer can still think, yes, looks like he was in a difficult situation, but I am not sure, maybe this is his day-to-day style. This is probably not— he is probably not in a difficult situation, but it's very clear that you are in a difficult situation. So at least they will think. So for things like this, add a one-liner that makes it very clear so that there is no confusion in the interviewer's mind. So when you explain, so this person was good engineer but was having trouble with the team or was not caring about the team, and me and my co-founder separately met with him— you said that line, right? Separately met with that engineer. After that line, you could say it was a difficult situation, or it was, it was not a pleasant meeting for me, or I had to be very careful, it's, it's, uh, so that it doesn't turn out to be embarrassing. Something like this. It was not an easy situation. It was a difficult situation to be in, but I handled something like this. Be very clear that it was not easy for you. So apart from that, I think everything is good. You didn't add our result at the end, so you told this. So you want to always recap after finishing. One second pause, your body, then you can say so What we had here is that a tough engineer, a good engineer, a tough engineer who contributes, but had in his, in the area where he— how to do it. Recap or something. So instead of lesson learned, you are more saying recap or something. Yeah, but otherwise I, I see overall, um, because definitely you are co-founder, you, you have been working for quite some time, the type of a story you are picking and the naturally the way you are answering I feel like this will be well received by the interviewer. This is my general assessment. The area where they may try to press you is how do you do during conflict. For, for example, you are saying that sometimes I try to do sugar coating and so on, right? You don't want to get the situation too bad, you are trying to control it. As an engineer, Yes, your interviewers will try to find it, so you better have stories ready. Stories of conflict, stories of situations getting out of your control, stories of failure and so on, um, and how you learn from those and you still demonstrate very Somehow not in every answer you'll be able to bring this one aspect of leadership. You have to bring in your story. In India, first story, you brought the empathy aspect of India, like you are feeling sad for the lonely engineer. So that's good. Like this, in the second one, probably another one is the justice or rule. Or team before the individual. You can even say a rule like this, is that, you know, there is a known management, uh, your phrase is that, or rhyme is that, yeah, team before person. There is no I in the word team, T-E-A-M, right? Those kind of things are there. So once in a while, if you say this like type of thing, they will know you are a well-read person, you know many different things. That's why you will become from good to great. There will be a differentiation. Usually the interviewers try to know bad answer, good answer, and great answer. And there is no recipe for great. Interviewers can say what is bad and what is good answer, and great answer is very subjective. Different people say differently. That's where you can try out this kind of thing, something extra. Yeah, but We're doing quite— yeah, I think we're doing quite good. All right, so we are almost out of time. If you have any last-minute departing question or anything I can answer.

Secret Zebra: Besides the sugarcoating stuff, which I think in both of these questions I see how I could have done better, do you have a top kind of overall improvement or follow-up area you might suggest?

Hyper Penguin: Yeah, the other one was that, yeah, pick up, yeah, tough, tough stories. Your second one was relatively— the question itself is tough, but the stories you pick, you try to make them tough for you, for you, for me. Successfully, but it's not so obvious. Then as a value of you hiring, is that because I was there, I was able to— but if you say it directly, then it shows a little bit of arrogance or lack of humility, right? So you say it in a different way, that in my place someone else would be there, may not have been able to get this project over on time or turn this performance out to a good thing.

Secret Zebra: Awesome, that makes sense.

Hyper Penguin: All right, yeah, okay. So thank you, it was nice talking to you, and I wish you all the best.

Secret Zebra: Yeah, all right, thank you so much. Bye-bye for now.