Engineer to Manager: Big Career Move!

Transcript is auto-generated and may contain errors.

Hey folks. Oh, I got to plug this thing in. We're going to experience devs for the topic. And um this is still going. Awesome. Okay. Um usually I plug it in and it restarts. The topic is about someone who is promoted into a manager role from a senior engineer and um they're going to be switching companies. And now they're curious like they never had to interview for the manager role. So they're like, "Hey, I want to be a manager the next place I go. Like how do I how do I navigate this? Like what do I have to do for the interview?" So they were saying, "I think that I need to do uh coding practice. I think I need to do system design practice. And I think I need to do behavioral interview practice. Is that right?" And so I wanted to talk about this because um this is like I've lived this life and I live this life.

So uh I figured it'd be a good one to go through. It might not feel super relevant um for you right now, especially if you're not uh you know, if you're not an engineering manager or going for that kind of position, but I think it's still helpful to kind of hear different perspective on on what it's like to go apply for roles and stuff. Um, and you know, mine's only one lived experience. Your mileage will vary. So, um, to start things off, I think this person is right in terms of the areas that they're talking about focusing on. And, um, this is based on my experience as an engineering manager applying for big tech roles at least. Okay, so that's the thing that I want to clarify here. For me, when I have applied to engineering manager roles, uh, they've only been in big tech and Oh, no, we got to get through this light.

We did it. Okay. Um, that means that similarly, I mean, over a longer time horizon than this person was kind of referring to, but like originally when I was an engineering manager, I didn't interview for the role. I was put into that really early in a startup, right? So like I hadn't I hadn't interviewed for that. Um I interviewed as a software engineer uh you know a good number of times especially from internships had to put me through a lot of uh interview rounds. So I had done that but not as an engineering manager. So for me when I first applied for engineering manager roles, this was after being an engineering manager for like uh seven or eight years kind of thing. So when I started applying though, this was only to big tech companies. That's not necessarily true. I applied to some others that weren't big tech, but I only interviewed at big tech companies.

And um so that's Google, Facebook, um Microsoft and Amazon. And all of them all of them did those three groups except sorry I say three groups um like uh sort of like elite code so data structures and algorithms type questions, system design questions and then uh the third is like you could generalize it as behavioral interviews. But it's like behavioral interviews, project management, the behavioral part. Um I think Meta does a good job of explaining how they break it down further, but it's like um behavioral interviews cover the range of it, but they also have like they want people focus. So how do you grow people? How do you manage people? How do you lead people? How do you grow teams? How do you manage people out that are underperforming? But then there's also project management because it's a huge component of uh engineering management as well.

So um those kind of get broken out. Now Amazon was the only outlier to this. Amazon is the only one that did not ask me a coding question. In fact, I don't even know if they asked me a system design question to be honest. And this stands out to me because um like I do not test particularly well. This is something that's uh sort of always been the case in my life. Um I think when I was like a lot younger, like you know, we're talking What? Why is my tire flat? Really? It's not flat. It's low. Oh man, that's a good time to get notified as I'm about to get on the highway. It is colder out today. Like sign I just watched the pressure go up as I'm driving. So I think it's cuz it's cold. So we're probably on the the cusp, but I got to pay attention to that.

Okay. Um, sorry. That's uh, like I said, timing is uh, timing is everything. So, getting on the highway and being like, "Your tire's flat, not good." I think it's just low in comparison cuz the cold weather. Um, yeah, even as a kid, like going to write tests like super stressful for me. I don't like the environment going into university. uh kind I'm the kind of person I will like uh kind of blank out on tests and then like be super stressed and then it's kind of like a vicious cycle and then interviews are you know it's the same type of thing. Um, fortunately, I mean, there's proof for myself that if I practice enough, then I can be successful and this is the case where like especially when it comes to like behavioral stuff, so people management, project management, that kind of thing. I feel very comfortable talking about that kind of stuff.

I still will practice of course because I think you show we should. But, um, I feel very very comfortable. Um, it's like literally code commute. The stuff I talk about is like me sharing Oh, buddy. Come on. You got to wake up a little bit. Um, you got to uh or sorry, I I share this kind of stuff that's very similar to topics in um in these types of interviews, right? It's just that the difference is in an interview I have to understand what um the person's asking and then understand like um or make sure I have a scenario that's aligned to it more specifically. So it's uh it's already a lot of practice from doing code commute on this stuff. Now you would think here's where it gets crazy, right? You would think that uh I mean you all don't know this from listening to code commute necessarily but I I write code like every single day uh not at work but I program every day.

I've been programming for years and years uh like decades and uh I love to program and uh in my previous role before Microsoft I was an engineering manager but also coding like directly with my team. So like a technical engineering manager was the the role. So again I was I was coding professionally in my career and uh so I understand code and I write code. Now when I test for it in interviews I regularly do quite poorly and that's because of lead code style questions. So back to what this person was asking. I want to kind of bring this full circle and talk through it. Those are the three areas that they called out. So data structures and algorithms, system design, and then behavioral interviews where behavioral interviews are broken into like project management as well as like how do you lead and grow people. Okay, so those are the three major areas.

But what I would recommend to anyone who's going through this is like yes, focus on all three, but spend most of your time and attention on the areas that you feel softer at. Okay? If you're going to apply to places that you know are going to ask you all three, focus and make sure you have coverage on all three, but get the most attention in the areas that you feel softer in. I cannot speak for companies I've never applied to. So, you know, you might apply somewhere and it's kind of like my Amazon experience, right? Where they focused purely on the behavioral side. So, people and projects like that might be the case for places that you're applying to. And then you're going to say, "Well, Nick, I wasted my time. I didn't have to do, you know, the data structures and algorithms thing." Like, hey, sorry, but you got to do your homework, too.

Um, but if you are applying to a place that does all three, which from my experience, it's basically the big tech companies. Amazon is an exception and maybe that's changed, then then get coverage on all them. For me, like I was kind of saying, it would absolutely be on the lead code style question. So, data structures and algorithms because I do not test well for that. Uh and then it would also be system design which sounds kind of funny uh because system design is something that I feel more comfortable in but um I have found in test scenarios a similar type of thing like I've always I shouldn't say always I generally share the the perspective and on this channel and other social media platforms and stuff as well like Um, I feel like lead code often involves like knowing tricks and stuff like that and it's kind of uh I think kind of dumb.

Uh, I think that you can absolutely ask system design questions in ways that don't feel like a trick. And I think that you absolutely can ask system design questions in ways where it's almost structured to be tricking someone. And um you know it's most of the time in system design questions the there's an expectation on the interviewe to be asking clarifying questions like you should be trying to ask questions to understand the system you're building and I think that's a good thing. I think that's good. And I have found I feel like more recently companies are doing a better job of like of like letting interviewees know that like hey like you are expected to ask questions right like if you don't tell people that then it can feel like a bit of a trick like hey am I expected to just know or if I ask questions am I going to be penalized so I think they're doing a better job of saying you're expected.

Um, but I still think that you can ask system design questions in ways where it's like um, like if someone's trying to get clarifying questions in the beginning, as an example, and say they get I'm just making this up. Say they do like 80% of the way. Okay, so they ask clarifying questions and they get like 80% coverage, which is like that's not it's not bad. 80% is like considered an a an A minus, right? That's not bad. Um, now if the missing 20% is something critical or is going to ultimately affect your expectation of the design and it's never been clarified and then you hold that against someone in their design. Like the problem is that 80% which looked good and only had a 20% miss. Maybe that changes your expectation later and they only get like 50% of of a design that you're happy with because it never got clarified, right?

So like if you don't reguide people back to um you know what the expectations truly were even though they missed asking the question or you don't evolve your expectation of the design based on that then like people get crushed in these types of questions and I've I've been on both sides of that where I've missed stuff in the beginning and then someone will say by the way like you know we didn't talk about this but this will be a constraint so let me introduce that to you so you can design for it. And I've been on the other side of that where it's like I've gotten through like almost an entire question. And then someone went and by the way, we talked literally back and forth in the interview where it was like they were they had the opportunity to interject cuz I would pause

and say like, "Hey, anything that you want me to to to clarify here or adjust?" And it was like, "No, no, keep going." So get most of the way through before they say like, "Well, what about this?" And I'm like, well, if I need that constraint specifically, then like I have to change my entire design and there's like a few minutes left. So, what would you like? Um so I I personally need to spend a lot more time proportionally on uh data structures and algorithms and uh and then system design sort of second compared to the other categories which personally really bothers me because um again speaking from my experience my role is almost entirely the other category almost entire entirely.

Um, so I find it very interesting, and this is just my my biased personal experience that I find that be um at least what I've lived through in my interviews is that the behavioral interview questions um some people might find that they're like, "Oh, I feel like I'm being tricked." But I've had a pretty good experience in those. Um I've had like I think the biggest issue I've had is where um you know I don't have a relevant example that comes to mind or I'm blanking like so that's obviously one thing but um I think really the biggest thing is not knowing based on the body language or feedback from the interviewer if I answered it in a way that they were expecting. So feeling like confused by that. That's probably the biggest issue. But um but I find that like they almost always seem like very fair questions and I feel like they're assessing my skills in a in a meaningful way.

Whereas data structures and algorithms and um and system design I often feel are are really not uh especially like the lead code style questions. Um, if you're trying to assess whether I can program based on a lead code question, I just feel like we're we're not talking the same language. And um so for me it's uh it's frustrating because from a preparation perspective I have to spend a disproportionate amount of time on practicing something that not only is a lot less relevant in my role like a lot less relevant. It's also being um tested through a mechanism which I feel like is extremely inadequate for doing so. system design is similar but better because like I said I feel like it's less uh I've had better experiences where it feels like there's less tricks and then uh the the most important one in my opinion

is like leading and growing people and project management and uh I have found that I've had uh like very fair questions so I I spend very little time preparing for that. Um it's my preparation for that kind of stuff is mostly just making sure that I have uh like stories fresh in my mind, right? So going through like literally listing out everyone on my teams that I've ever like worked with and just thinking through scenarios that I've worked with them on um challenges or growth opportunities and then big projects that I've worked on as well. So I like doing that and kind of uh making sure that those things are fresh in my mind so that if someone's like, "Tell me about a time where you had a failed project." I'm like, okay, like top 10 projects I've worked on or whatever or spent time on.

And then I can go, well, this one had phases or it failed in these ways. If I've already used that example, I can jump to another one, but just to keep them fresh. But, um, as I'm pulling up to CrossFit here for this person, yes, all three. Your mileage will vary where you need to spend time and effort. And um and I think based on you know where you feel comfortable. Oh boy, you parked super close. Um and also what the companies are looking for. But I think that's it. I'm just going to get parked here and then I am off to go probably do something that's going to hurt me at CrossFit because I'm not very good at it. But that's okay. Bye.