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

Practice answering behavioral interview questions effectively, focusing on technical decision-making and conflict resolution scenarios. The challenge involves structuring responses using the STAR methodology, selecting appropriate stories that demonstrate technical leadership, and communicating soft skills while highlighting engineering expertise.

Interview Feedback

Feedback about Ice Squab (the interviewee)

Advance this person to the next round?

How were their technical skills?

3/4

How was their problem solving ability?

3/4

What about their communication ability?

3/4

- Good pace of communication. However, try to pick words from original question in your answer. - good story selection. However, see if you can add some technical aspects to your story more

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

I learned a lot of really good tips to get better for future interviews, thanks so much!

Interview Transcript

Hyper Penguin: Okay, thank you. So, um, this is a behavioral interview. We have about 1 hour or so, so I was thinking that you can go in one of the two ways. So one is, um, you have some questions, you have certain mock questions or ideas, something that you want to discuss, and we start with that. And whatever time we have left, we can go with some more questions that I ask you. Yeah. Uh, the other way to go is what I have done more in the past, is that we— I start with a mock question you answer it, and then we two analyze together that answer. And after that, see what kind of questions you have, and then whatever time we have left, we fill that with additional mock questions and so on. So do you have any preference how you want to move forward? I see.

Ice Squab: Um, yeah, we can do the second one. That sounds good.

Hyper Penguin: Yeah, yeah, I think that sounds good. Okay, so before we go to that mock question, You know, in every interview they will ask you, tell me about yourself. So let's start with that. I'll take notes as we talk so that I can add at the end of the interview session in the review report. So tell me about yourself in 2 to 3 minutes as an engineer or as an engineering leader.

Ice Squab: Yeah, I can certainly do that. So I have 6 years of experience as a software engineer and I've been doing like full-stack and mobile development, focused in product engineering currently, but I also have some background in machine learning. And yeah, I have some experience, a few years of experience as a tech lead for various like projects and work streams. This can be up to like 5 engineers and different cross-functional partners as well. So right now I'm on the [REDACTED] team, which is a [REDACTED] app within the [REDACTED] app, and I've been tech leading the reliability team on the more technical side, dealing with bugs and crashes, and then also more on the product side, I've tech led, I've led some like explorer and information architecture projects dealing with engagement and [REDACTED] home UI.

Hyper Penguin: I see. So you have approximations, you are a full-stack developer, you did also mobile development and machine learning model development, is that correct?

Ice Squab: Yes, that's correct.

Hyper Penguin: Okay, awesome. And, uh, what are you looking forward to in your next company, in your next role?

Ice Squab: Yeah, I would say I'm looking to continue kind of doing full-stack development, but maybe grow in a more technical, both technical and mentorship capacity. And on [REDACTED], I've had that, I've had the luxury of being able to challenge myself, but I think it would be great to try different companies, different tech stacks. Um, I just personally like, uh, being challenged and always just growing, so, um, and just seeing new things.

Hyper Penguin: Yeah, I see. Nice, thank you. Uh, what happened? I'm not seeing the toggle. Um, by the way, the interviews that you, uh, that you are practicing for, are those 45-minute interview, behavioral interview? Um, I would say some are 45 minutes, some are an hour.

Ice Squab: Um, yeah, it's just, it's dependent on the company right now.

Hyper Penguin: Yeah. And what are the company sizes? Are those startups or public companies, large companies?

Ice Squab: Yeah, so right now I have, um, [REDACTED] and [REDACTED] are pretty big, and then, um, I have two kind of mid-sized companies, [REDACTED] and [REDACTED]. And then I have a sort of also kind of a mix of everything.

Hyper Penguin: Mix. Yeah. All right. Anyway, behavioral interviews are very generic way you can approach. So I think I got a good idea. Um, so about do tell me about yourself, um, I think what you can do is you can say it in a time series manner, like your Oldest experience first, and then you come here, and then touch base just 5 to 10 seconds on each of those. But say a little bit lot more on your last one, the most recent one. Spend some more time there when you're talking about yourself. Um, what, what you want to tell is the team size, the company size, what was your role, and what you learned, or any significant project that you delivered, and then move on to the next one. This is what I learned in this, but has to be very quick. No scope for detail explanation, nothing, because those will come in the actual behavioral interview questions. These are not questions, it's just introducing yourself, right? Um, and then it's always good to say what you are looking forward to next, is that I'm looking for similar full-stack engineering capacities where I can basically go on my website and so on. Yeah, so, but I think more or less your— these ones are good. So we'll move to the mock question. So mock question number 1. So let's start with these. Um, tell me about a time when you made a technical decision that changed the course of a project or a feature.

Ice Squab: Yeah, let me think about that for a second. Yeah, sorry, give me one second. Yeah, I would say maybe I can talk about a project called [REDACTED] Media Feed that I led. So that was one of the big projects I worked in maybe like, oh, 1 or 2 years ago, I would say. In this project, we were building kind of a timeline of [REDACTED] users' [REDACTED] posts that you could interact with and like or pass these users from the feed. And so I think the big, the biggest decision I made here was when we were discussing with the product manager, data scientist, design, et cetera. I think it was a question of how much can we get done, how many, like, what are the features that kind of are on the North Star? And there's a lot of features we discussed, like, could you make the post snap onto the viewport when you scroll, or could you add direct messaging onto the timeline, or directly liking or passing the candidates on the timeline, for example. And the decision I made here was to seperate this out into MVP versus milestones. And because of this decision, we were able to ship the MVP first before the end of the half. Whereas if we had all of these features all in the MVP, we wouldn't have been able to ship this until the next half. But then these features I moved and prioritized over the next half. So we were still able to get those features out, but we were also able to move quickly and validate MVP as soon as possible.

Hyper Penguin: So if I got it right, the, the decision where you made was identifying the important features, so filtering out necessary part. Was that what you are— are you saying? Is that the main thing?

Ice Squab: Yeah, exactly.

Hyper Penguin: Question is, um, you made a technical decision in the course of a project or a feature, and I see the technical decision that you said you mentioned more as the biggest decision. You say whether it's technical or not is not clear. It looks like the decision you made was which features will be impactful for the product success. Or was there something like you decided this library we should use, this tech stack we should use, or we have to scale it this way, and so on? So in what sense you think this is technical? It may be just a product feature filtering prioritization decision you make, no?

Ice Squab: Yeah, I see your point. Um, yeah, actually, yeah, I guess think about it. Yeah, the reason I kind of thought this might be technical is because I guess, yeah, it kind of touches on engineering feasibility, but yeah, I think you're right. This is more like a product challenge rather than a technical challenge.

Hyper Penguin: For example, I'm thinking Could the product manager also come up with a recommendation? Know how to code, could they also come to this if they have enough experience developing products?

Ice Squab: Yeah, I see. Um, yeah, I guess like, so I guess what you're saying is like, um, for this question, when it talks about technical decision, it should be like specific or technical enough that it's like, um, like something from a strictly engineering—

Hyper Penguin: if there's a technical question or technical piece, it's mainly about the role that you are applying for. Let's say you're applying for senior full-stack engineer in a company, and so then the technical part will be something that a senior full-stack engineer will be able to do, not a product manager or not a QA engineer.

Ice Squab: Right, right.

Hyper Penguin: So what I'm thinking is that your answer, if you don't have any better story, this is okay. You, you can get it done with it, but I'm trying to see if you can have a great story rather than just a good story. And one of the things, uh, what during behavioral interview we are trying to figure out is that are you a good team player? Yes, fine. But also, are you technical enough, you know? So if you are answering something and if someone is saying, tell me from your engineering experience, your front-end development experience, or your technical experience, what you have done, that means they want to hear your technical experience, excellence. A little bit. Also, not like an engineering manager should not be able to come to the solution that you came with, that type of thing. So I think your— this answer would be fine if you would also put a few things along with this. What are those few things? Let's say you say, while doing this, I figured out that our latency of the page is high, so I also worked on improving the latency. Or I see that the workflow is very complex, so I decided to go for a SPA, Single Page Application architecture, you know. Or I decided to implement MVC pattern here. So something technical that usually an engineer will have knowledge of. If you can bring, then the— your story will be stronger. To the interviewer. Sounds good.

Ice Squab: Yeah, um, let me think. Um, yeah, I could, I could, uh, I, I think I might have a different answer based on what you're saying. Uh, like, should I really try this question or—

Hyper Penguin: No, no, no, we are analyzing the question. I think the question you already answered. That's fine. We are just analyzing them.

Ice Squab: Um, yeah, but I think that makes sense. I think like, um, yeah, I think that's the problem is like when I was like practicing for behavior— this— the behavioral interviews, like most of the complexity that I encountered during my career is more like product-oriented. But yeah, I can think more on like the technical things. I can, uh, try to spend more time.

Hyper Penguin: Or even if it is product-related, that's fine. But you mention the name of a few technologies. For example, let's say this type of problem suits very well for React components, so I decided to use React to solve this problem. You know, you say that thing, that viewport and so on, and you say one of the biggest thing I did was being able to figure out what's necessary and what's not necessary. And on that, the technology Tech stack that I chose goes very well with my workflow or my decision, and that's why I went with this. So somehow you put your tech or engineering or React or a programming language, whatever you are using, AngularJS or whatever. If you can put something or single, single page application or this GraphQL, whatever you want to put it there, if you put some touch, that will be helpful when the interviewer is trying to know your Tech— they use the word your technical experience or engineering experience because they want to hear some tech word from you, you know. For majority of the questions, they will not have it there. You don't have to say those. But for questions like this, this one was deliberately— I chose this way so that I can hear some of your technical expertise. Right, right. Okay, yeah. Mm, okay. So let's go to the, uh, full analysis now. So that's like the story selection. Oh, one feedback about story selection is that you have about 6 years of experience, so keep thinking on all your 6 years and see what interesting things happen, both your success and failure within the team, and something related to you. It has to be you. You are the main protagonist here. It's a stage drama storytelling. You will be doing storytelling centering around you, but you also want to bring other characters in that storytelling. Your, for example, you talked about the product manager, you talk to product manager. I liked it. You are bringing the other characters in your story. So anyway, um, that's, um, one. Um, the format, have you, uh, are you familiar with STAR methodology? S-T-A-R.

Ice Squab: Yeah, I am, uh, familiar. I, I, at least on my resume it's on all STAR format, but I guess I haven't thought about it as much for like behavioral interviews.

Hyper Penguin: Yeah, I see. So if you put in STAR format, the answer is usually a little bit structured, well structured, so you don't have to be too much out of line of your natural style to to adopt with STAR methodology. If it's a little bit difficult, it's not going with you, that's okay. But, um, if you put it in a STAR methodology, the answers are more structured. It's— it sounds better, it sounds more professional, more competent. So see if you can try that format. So in the STAR methodology, the first S is for situation, right? You want to give the context of the answer. So what you want to say in your— this answer, what I see is that you said you worked on that [REDACTED] video, uh, timeline of [REDACTED] users and so on. So before saying that, tell when, where, and who were involved. So in this case Start with that, in my last company, or the company before my last company, or 3 years back in the— in, in a company, in a startup. Basically you're telling the when and where, exactly where this story you are about to tell that happened. And then you can also say who else were involved, but that's not necessary. You can say the company size, like it was a startup or a large company, was it [REDACTED], or if it is the startup, or you are one of the top— yeah, you are one of the first 20 employees of the company, or you are working on a team of 10 engineers, or you are working on a diversified team where there are full-stack engineers, backend engineer, product manager, and so on. If you can give that context a little bit, that helps when you are answering the main body of the answer. It will help. So try to put— say, start with situation, which will be usually 30 seconds to 1 minute. That's what you want, right? Out of, let's say, the whole answer will be 5 to 7 minutes. And then T, you can skip T, or you can say what it is. Task, uh, task will be reiteration of the problem statement. So the problem statement was what? Was, tell me about a time when you made a technical decision that changed the course of a project or a feature. So then you take this word and put it into your first-person narrative in your way and say, so I'm going to tell you about how I made a critical decision to change the course of this, this project that I was part of. You see, you are not telling the answer, but you are telling that what you are going to say. That is the task. What is the problem statement? And if you use some words from the original question that the interviewer said, that's even fine. So interviewer will think you are going to answer to the point. So, but between S and T, or A-S-T-A-R, you can give a 1-second pause. Think of each of those as a paragraph, like line break or a paragraph break, one paragraph to next paragraph. You give a 1-second gap between each of those major ones. Why? So that the interviewer can jump in and ask you some questions. Usually interviewers don't want to interrupt you, so they may not ask you question until you are done with all your 5 to 7 minutes full answer. But this is an indirect invitation from you that if you want to interrupt me, now is a good time. So how you do it? Just a 1-second pause, intentional. So Say nothing and then start the task, and then 1-second pause, then say action, 1-second pause, and then result, and so on. So anyway, that's one technique how you can engage the interviewer in the conversation in your answer. Okay, uh, but let's go to the A. So task will be usually 10 to 15 seconds. Task is just 1 to 2 lines reiterating what you are about to say. Or the problem statement narration, that's it, not the answer, the problem statement. Now the main answer is A, action, which is the body of the answer, and this should be 4 to 5 minutes. And then finally, result, it will be about 30 seconds. In results, you want to say the summary, closing, or any lesson you learn, the lessons learned. So again, this is 30 seconds to 1 minute is fine for results. This is the overall format, answer format. Now let's go to your answer and see what you said. So you went, you talked about the product. I like the way you put it. And if you put separate these out of MVP, we are also quickly able to move to MVP. I think what you are saying, these are fine. These are nice. I would just like to hear some more tech stack word from you, technology word, or like what you did for testing, or what was the percentage, or the— I— what kind of framework or tools you used. So because you are an engineer and you are applying for an IC, in your words, a lot of tech word, tech stack, those should come out when you are answering something. Naturally should come up.

Ice Squab: Yeah, yeah, I think that makes sense. Um, so yeah, I guess like STAR format technical. Okay, yeah, I think that makes sense.

Hyper Penguin: Okay, then the last one is R, result. In the result, you want to reiterate the story that you said at a high level. So from— so I, uh, in, in this company, from this project experience, I grew as an engineer because I had to make a difficult or a critical decision at an important moment in the project, and that paid off, so I am happy about it. Something like that. You are trying to reiterate and close it. That's outside of the body of your answer. It, it should be kind of like a repetition in the summary side. And if you failed In this case, you are successful, right? You made a good decision. But there will be stories where you fail. If you failed, you have to say what was the lesson learned. Even if you are successful, you can still say what were the lessons learned. But if you failed, it's compulsory to say what the lessons learned, so that the interviewer knows that you learned and grew out of this experience, so you will not make that mistake again, or you will not fail again the same way. So that is the, um, result part. Now let— we can move into the next mock question. But, but before I move to the next mock question, uh, tell me if you have questions around this. What questions come to your mind?

Ice Squab: Um, no, actually I think that makes sense. Um, yeah, I think like in the future if I get asked this in the interview, like based on what we're saying I think like, I think I have a, like a more technical decision that I make, 'cause like, yeah, like this one, when I think about it, like, yeah, I think what you've made, what you said makes sense with like talking about like tech stack and technologies, but yeah, I think maybe I'll save this for like a more product-oriented decision question and for like technical, Um, yeah, I might like look through my resume again and like my previous projects just to see because exactly, yeah, I think like currently the answers I've like prepared are mostly, um, like yeah, more on the like a product side. So yeah, that's a good thing to think about, I guess. Yeah, right.

Hyper Penguin: A few other things that you can put in your answer is, for example, let's say Dialogues like this is that I am an engineer who cares a lot about scalability, or I am an engineer who thinks clarity is kind. I, I believe in maintainable code, so I put a lot of effort on making sure the code is clean or the code coverage is high. Something like this, because these are behavioral interviews. You have to sell yourself. You have to say which ones you are passionate about. The interviewer would like to know about those things. Everyone has a natural tendency or passion around certain things, right? You don't have to be passionate about everything. So try to bring what you are passionate about in your answer, right? That makes sense.

Ice Squab: Yeah, yeah.

Hyper Penguin: All right, so let's go to the next question then. Yeah, mock question number 2. Mock Q number 2. Tell me about a time when you had a conflict with a team member and how did you handle it, resolve it?

Ice Squab: Yeah, I would say, um, for this one there's kind of multiple people involved, um, but, uh, primarily it was with, um some leadership and people on another team. So, yeah, I guess starting from the beginning, my team, I was leading this project called Information Architecture. It was one of the milestones for this work stream to change the layout of the [REDACTED] homepage, and what we wanted to do was we wanted to put some entry points into other features at the, at the top of [REDACTED] Home and also change the feature, change the entry point to be smaller buttons that can be more visible and easier to access and enter into. And so that was a big change we wanted to make on the [REDACTED] Home page. But another [REDACTED] team called the [REDACTED] Growth team at the same time was building this feature where they would put a dropdown of notifications at the top of [REDACTED] Home. And this was a project that we weren't aware of and they weren't aware of our project as well. And so we were fighting for space at the top. And when this was escalated to [REDACTED] leadership, it was looking like they were favoring the [REDACTED] growth project and not our project. And I, in other words, how do we get to a point where I can make sure that our workstreams project is shipped without, without like conflicting with this growth team's project and also making sure I try to win over [REDACTED] leads and [REDACTED] growth team. So yeah, I thought a while about how to deal with this conflict and I think there's a few directions that this needed to go. So the first thing was I kind of stepped back and thought about what this project was and what we needed from it. So there's kind of multiple parts of this project. So I mentioned that this was reshaping the entry point into different [REDACTED] features. And so moving it to the top would give them more visibility and then changing the design into smaller, lightweight buttons would also increase the discoverability and just make it easier for users to be able to access these features. So we had to think about this, right? And what I decided was there was a compromise where if Leeds weren't willing to back down on this, I still wanted to ensure that this project would be able to ship. And that meant that if, we moved the feature down to the bottom of the [REDACTED] homepage so that the [REDACTED] growth feature would still be at the top, um, there is a bit of room where we could potentially ship both. Um, so that's kind of, um, the lines of what I was thinking. And so, um, what I did was I worked with the product manager to come up with a, a trade-off of all the different, uh, possibilities of how these two projects could interact. Either we don't ship our project, or we do ship our project at the top, or we ship our project at the bottom. And it was kind of like a table where our proposed compromise was like the middle solution. And there's kind of like a— like the best of both worlds was how we were trying to frame it so that we could show that this is still allowing us to ship our project, but it wasn't making the other project compromised. And so that was the compromise I first proposed. And then more on the technical side, I proposed a plan where we ship both projects before the end of the half, but then we run a backtest and we also defined joint metrics. I met with the growth team's POC to talk about what both of our project success was and how we could, um, devise an A/B experiment to, uh, do a backtest on both of these features. And this way we're also still able to ship, um, both projects before the end of the half instead of having to wait 'til the next half to run an A/B experiment with the backtest now, we could ship first and then with an optimistic viewpoint that it wouldn't have metric regressions, we could run the backtest after the end of the half. So I would say the way I dealt with the conflict was twofold. Kind of compromising where I thought that the— there was some room to be compromised and still get our project across. And the other one is just proposing like a very detailed and technical plan to make sure that everyone was satisfied.

Hyper Penguin: So basically what I'm saying is that overall I see that the structure of answer for this question is better, like you did better than the earlier one. So that's good. Uh, let's look at the story. First. So on this story side, what I see is that two teams wanted a real estate in a home page, uh, two different features on the same application. So there, there was a disagreement on who is going to get the precious real estate top of the page on the home page. What is not clear is, is the conflict between the two teams Or between you and another team lead and engineer? It's not very clear. Can you tell me what was the conflict? Yeah.

Ice Squab: Um, I would say, yeah, I realize that's not clear. The way I want to tell this story, um, in an interview is a conflict between me as the lead of this project and the lead of growth. And I guess technically [REDACTED] leads, but primarily like, yeah, like I guess the leads and I wanted to talk about how I worked with the product manager, but maybe that was confusing because I didn't really like delineate like the conflict versus like the resolution or like the parties involved in those.

Hyper Penguin: All right, so let's say always make sure that you have the question in mind. What's the question? The question is, tell me about a time when you— not your team— you had a conflict with a team member. A team member, not a team. Again, that means you have to build those characters. You have to talk about you, your role, and that team member who— so maybe you had a conflict with the whole team, but there must be someone who was more vocal in that team, or was the team lead, or the main person deciding, or the main technical person. So you highlight on that person, although you talk about everyone in the team, but you highlight that person. So that's why the— you have to answer actually to the point. Your answer was more like generic versus you want to be specific to what was asked from you. Uh, you had a conflict with a team member, and how did you resolve it? You explained the how did you resolve it part very well. So that part you say is that you went twofold. Uh, one is compromise and another is that we are a meticulous project plan so that we don't have— yeah, step into each other's toes, right? So now that is the technical resolution, but we also want to hear by resolve, how did you handle it from a behavioral skill, soft skill point of view as a team member? That means You assured that team member, like, we have a plan, we have no problem, we will go ahead with it and we'll support each other. You know, that's how you resolve, like, through communication. So you have to use some buzzwords, is that we resolved it using delegation or using communication or using Crucial Conversation. You know, how did you resolve it? We would like to know. I know that from your answer we can derive under which category your resolution falls. But you always want to give— use the buzzwords, the key tags like those, is that through mutual respect or through frequent communication and collaboration, through cross-functional collaboration, through frequent meetings, or through delegation, or through these, we have been able to resolve it. You know, you want to exactly say it in a way so that the interviewer doesn't have to interpret. That's another way if you can improve. So use the keywords, buzzwords like open communication, cross-functional collaboration, etc., when explaining how you resolve the issue. And then let's see, and then let's see, you say Chenxi entry point similar, we were, yeah. So I liked the way you staged the story. So I felt like it is, I am being able to easily visualize that you are building a feature, another team is building a feature, both of you have to share the home page, both of you want a real estate, who is going to get it? You know, the tension. So you built that tension well. This is how you should be doing. It's like a story, it's like a drama. You are building the tension. And then what happened, you narrated, is that looked like after some conversations, looks like leadership started favoring the other team's idea to be put into the top one. So I understood still we can do something about it. What can we do? And I came up with these compromises. That, okay, if they are going to get that, can you put it in the bottom? So, you know, so you have been saying it in a nice way, so continue doing it. I'm saying probably slightly in a different way, but it's the same. You also did a good job. Okay, let's see what else. That was a compromise I proposed. We ran A/B testing. Yeah, the solution that you explained, those are good because those are technical things, like you ran an A/B testing. Or that back, back project, you said something like this. Those are good. So this shows that you are an engineer day to day. You are in an agile delivery framework. You are, you are familiar with this. Every week you know how to go through an iteration, deliver your feature, and so on. Let's see, uh, you also did the ending summary well. Like you specifically said, so there are twofold ways. I like that. First this and second this. This is very good. This is ideal summary. So I would say your this answer was relatively better, but the main feedback will be is that your answer is not clear. The story doesn't say conflict between who and who. I can interpret many different things from your— from what you said. It's not clear. That's one. And you can use a little bit more of buzzwords or key keywords. Some examples I wrote down: open communication, cross-functional collaboration, delegation, you know, empowerment, crucial conversation. These are, yeah, keywords or buzzwords that managers, leaders, they all know to do it. So your familiarity is helpful with this. Any questions? Yeah.

Ice Squab: No, I think, I think everything you said makes sense. I think what I'm getting out of it is like, uh, when an interviewer asks a question, I like should pay attention to like every word because I think sometimes like I kind of answered the vibe but not like the exact thing. So I think that makes sense. Yeah, right.

Hyper Penguin: Yeah, like to the point, to the question you want to answer instead of reinterpreting the question in a way in your mind and then answering No, exactly what they are asking and try to answer exactly every word they say to ask the question. So basically, you know, with every word, one or two words, the whole question may change. So that's why you— even one of the way is to ask the interviewer, do you mean this? Like, do you want to know about this? Reinterpret and confirm that this is the question they asked.

Ice Squab: Yeah.

Hyper Penguin: So use each of the, uh, words that they they are using. Follow carefully and see if there is a strong word there. Like conflict is a strong word, right? Uh, resolve is a strong word. So that's the thing, you pick and you try to use those words in your answers. You can use alternate words, but if you use those words, interviewer will psychologically feel like you are answering exactly what they are asking for, to the point, because you are using exactly the same word. So it's psychologically they feel closer to the answer. Okay, um, another thing you can do is— this is good answer what you give, but you can make a good answer a great answer by doing a few more things. One of the things is that if you can use reference of different books or industry incidents, um, uh, for, um, or articles or something like that. Those are popular or well-known or established theory kind of thing. These usually happens when you actually do a lot of reading, you have a lot of experience, many years you have faced different type of situations, so you can draw some examples from outside. So for example, let's say book name. In this particular question, let me see, it was about conflict, right? So you can probably say is that, um, there is a book, Crucial Conversations, where they talk about the importance of how to resolve a conflict in an open-ended manner. So I tried to follow some of their recommendations, like I was open-minded. I decided that we should cut to the cheese, exactly straight, uh, to the point, like Radical Candor by Kim Scott, where you care personally but challenge directly. So I, I was very open to receive as well as give feedback, you know, this type of thing. If you can bring examples of books, articles, or other incidents, like, remember the incident of Steve Jobs when he was kicked out of the Apple board and then he came back and reconquered Apple. Similar— or Steve Jobs didn't let iPhone come for first several years until it was exactly perfect like him. That's the passion about, uh, perfection on the user experience, right? So as a full-stack developer, I have that passion. And you know, just in some way, if you bring examples like this, that says that you, you have a wider knowledge base. In this particular question, probably there is nothing much you could do, but just keep an eye open if you can bring some outside experience knowledge or industry knowledge or book reference, article reference into your answer. That strengthens your answer, makes it a— it makes a good answer a great answer, basically. Yeah, um, that makes sense. Yeah, yeah, go ahead. Okay, so let's start with the next question. We have some time. Yeah, go ahead.

Ice Squab: Okay, sounds good.

Hyper Penguin: Yeah. Oh no, no, that's it. Yeah, okay, okay. Yeah, so let's go for the next one. So this one What are the characteristics or attributes of an ideal team player, in your opinion?

Ice Squab: Yeah, um, let me think about that. Um, Yeah, I would say, in my opinion, it's not as important how technically proficient they are. I mean, of course it's important to a certain extent. But no matter what, every new team you join or every new company or whatnot, you're always gonna have to learn like the specific languages or tech stack or like the specific codebase of the team. With that context, I think for an ideal teammate, there's a few things. So first is just being open. And just learning. I think it's always a red flag if a teammate isn't asking for help or onboarding, like being open and just like moving quickly but also relying on other people. Because I think, in my opinion, no matter what, even the most senior people have to learn. Specific details about like the codebase or the product that they're working with at any given new team. So I would say, yeah, that's the first thing. And I would say second thing is just like problem-solving ability. I think with teammates that are junior or new teammates, sometimes what I see is, Instead of like, sometimes instead of failing fast and just relying on help, they just keep to themselves for a long time, and that is often a waste of everybody's time because they are not communicating, right, that things are not going well. But sometimes for other teammates who ask questions all the time without doing any of their own research, that's also bad because that's also a waste of people's time if you're not trying to figure out things for yourself. So I think just like with especially senior engineers, they're able to problem solve and figure things out with like a balance of being able to ask for help but not also like trying to figure things out themselves. So I would say that's the second thing and probably the final thing is just being very communicative, especially like, I guess like there's always structures of the team that allow for that, for example, standups and like update trackers and such, but I think beyond that it's important to just communicate, especially with, I know there's always like a debate of like, documenting codebases very closely versus word of mouth kind of style where details about the codebase are not documented but passed off as knowledge. I think especially with faster moving teams and projects, it's not always possible to document everything, but there are decisions and ideas that are pretty important that may need to be figured out that aren't necessarily well documented on paper. And for those, I think, like, the teammate, if it's a new teammate, they need to be able to ask questions. And if they're an existing teammate who's worked on a large project, in turn, other people need to be comfortable asking them about their specific projects as well. So yeah, I think like, to sum it up, I would say openness, problem-solving ability, and communication.

Hyper Penguin: So basically, uh, the— what Patrick Lencioni is saying in that book is that an ideal team player has to be humble, hungry, and smart. So who is humble? So humble is someone who shows humility. That means they may be good, bad, whatever it is. They are usually good team members, right, on their work, but they are pleasant to work with because they are humble. The opposite of humble is a brilliant jerk. They are very good, but then it's very difficult to work with them. So you show humility while you are trying to coach, mentor, help others, or learn from others. So this is a— if, if your team members don't have humility, then over a time this team will not gel well with each other. That's why humility, this is important. So when you are interviewing, look for humility in people, in the candidates. The next one is hungry. Hungry means here you— they are not looking for a 9-to-5 job. They take ownership, they go extra mile, they challenge the status quo. You tell them to do something, they find a better way to do They say, why this way? Have you thought the other way? And so on. These are hungry people. And then SMART is emotionally intelligent. So they know how to work in a group setting, how to care about others, when to show empathy, when to become a little bit more direct and radically candid when giving feedback and so on. Or when they go into a room, they can understand the mood of the team, the room. And so on, you know. So that is Humble, Hungry, and Smart by Patrick Lencioni. You can just do YouTube and find out what it is. The Ideal Team Player, like you can listen to a 5-minute book summary and you will understand. The Ideal Team Player by Patrick Lencioni.

Ice Squab: The book is called Ideal Team Player, you said?

Hyper Penguin: Yes, yes, by Patrick Lencioni. Um, has to be humble, hungry, and smart. As per— this is one way of answering. Now, definitely doesn't have to be— you can answer in, in your way, in different ways, but this is one very ideal way. And when you are referring a book and a management guru like Patrick Lencioni, your answer will have lots more credibility to the interviewer. Like, it will be a great answer, strong answer. So look for— yeah, right. So can you tell me, uh, do you have some more time? I know we lost a little bit of time for connectivity issues. We can go 5 minutes more. Do you have time?

Ice Squab: Um, yeah, I have another mock interview at 4.

Hyper Penguin: Um, then that's fine, that's fine.

Ice Squab: Yeah, yeah, yeah, yeah, that's awesome.

Hyper Penguin: So overall, my recommendation is that I think you, you, your speaking is well, your voice, your pace is well. You have to think a little bit more around how you can pick the words from the interviewer's mouth, exact words they are saying, and reuse those words in your answer so that you are to the point. And pick strong stories. That matches very well with the question. And if you don't find strong stories, that's okay. Find something closer and try to work with them. That's fine. But always look out for strong stories, and you can actually make some stories ahead of time at home with pen and paper at home sitting down.

Ice Squab: Yeah, that makes a lot of sense. And yeah, I think also I thought I knew like the STAR method, but I think Uh, based on what you're saying, I could probably use it more too. So yeah, no, um, that, that all makes sense to me.

Hyper Penguin: Yeah, there will be some questions like this. What are the characteristics of an ideal team player? This is not a STAR candidate. STAR candidate is only when you're saying something from your experience in the past, an event happened or an experience happened, right? This is more open-ended standard question. There you cannot use STAR, but in other places you can. All right, I wish you the best for for your interview.

Ice Squab: Yeah, yeah, thanks so much. That was really helpful. I appreciate it.

Hyper Penguin: Yeah, thank you. Bye. Thank you. Bye-bye.