What do hiring managers look for from software developers in interviews?

Transcript is auto-generated and may contain errors.

All right, folks. We're going to experience devs subreddit for a topic today. This one is as a hiring manager. What things are you looking for from an engineer in interviews? So, I figured we'd talk through that. Uh, a little bit of background for me. I am an engineering manager at Microsoft. I've been there for 5 and a half years. I've been an engineering manager for around 13 years now at startups and big tech. So, um, been hiring engineers for, uh, basically my entire career. So let's chat through this. Um I think like first thing that I want to call out is that in um when we talk about hiring and interviews and this kind of stuff, it's going to be a bit of a show in terms of the variability, right? Like I could tell you one thing that's like a complete truth for me and how I navigate that.

You might talk to the next engineering manager and they have a completely different perspective. It's kind of it's kind of unfair for people because you're you're going to have too much variability. uh and you know even if we have stats pulled up and we said like you know 80% of engineering managers look for these three things or something you might go in go into an interview and have someone who is the other 20% be like well dude what the hell right so I just want to clarify that in the beginning that all of this is my perspective this is how I approach things and I don't want you to hear what I'm saying as if I'm suggesting that this is the the rule for that all engineering managers follow and if you listen to what I say then you know it's going to be perfect kind of thing cuz it's just like that's impossible unfortunately.

Okay, so let's talk about um like the technical stuff first cuz I could spend the entire time talking about behavioral and project stuff. It's really cold. I'm shivering. Um I think on the technical side like two things that we can look at are um like coding and um and system design. But and I say these as two categories because often if you're go doing big tech interviews like you'll have things broken out this way. But the the wrench I'm going to throw into it already is that even for these two types of things, um I don't look at them the traditional way or kind of like I don't look at them the way that I've been interviewed because I don't think that it's super effective. And let me explain a little bit more. So when we talk about coding interviews, right, most of the time you're going to have something that's like a lead code style question.

and someone's going to give you like a word problem and it's like you know uh usually you're asking some clarifying questions to make sure that you understand the scenario. Um you walk through a few things and uh and then you would start writing out your algorithm and explaining what's going on. And so I find that with lead code style questions, we end up getting um what feels too much like either you can do great by memorizing things, which I think is kind of useless. Um or you can you can you know bomb in the eyes of the reviewer or the interviewer, sorry. Um because you like didn't find a trick, right? like you know your your runtime was good but it wasn't you know the you didn't find the little mathematical trick that you could have done to like optimize everything and have it done

in negative time like I've and I say this like I probably sound a little bit bitter because I've been you know been in interview panels in interview loops where people are giving feedback for candidates and saying things like oh they didn't they didn't find whatever optimization so like you know it's a no for me and I'm Like I don't I don't think that we should base someone's hiring like on finding a trick. It just like it it feels like the complete wrong focus to me. So when I'm asking coding interview questions to assess technical ability on coding, I am honestly just looking to have a conversation to see how you think through problems. It's almost like exclusively problem solving. Um, I don't give a what language you use, right? Um, I've definitely been in interviews earlier in my career. This is kind of crazy.

Um, where we would interview people that have been like, "Oh, I've been a software developer for like seven years." And we go, "Great, pick any language you want and, you know, answer this question." And we realized that I know it's like on a whiteboard or on paper. This is kind of before everything was remote, but um they they literally couldn't write things like if statements or uh or for loops like the some of the most basic primitive things. And we're saying look, you can use any language you want. If you've been a developer for 7 years, there's probably a language that you know how to write if statements and for loops. And we picked really um like the questions were like trivial, right? like fsbuzz or fs pop depending on how you want to call it and we noticed that people literally could not write code.

So my coding interviews the like I feel like the bar is pretty low in terms of like um you know can you write actual code um well we use a lot of online stuff now right? So, can you write code into an online editor? Like the bar for me is pretty low on that because, you know, we're going to use different languages. I don't care if you know C sharp or C++ or C or Rust or whatever, whatever. Not whatever. Um, and so like I don't need to like sit there and assess like do you know the intricacies of this language because we're going to be going between other things and the reality is like you're going to learn it, right?

like we are at least at Microsoft and I feel this is the case for a lot of you know companies that aren't just startups trying to to fight to stay alive like we have the resources to train you on them so if we use C and you don't know C don't worry um if you understand object-oriented concepts you know some of these basics like you'll pick up the language fast uh especially if you know another programming language already Um, so when I'm doing these interviews on the on the coding part, I'm just looking to see like how you're thinking through problems, right? I don't use trick questions. Um, really simple. Like it's still data structures and algorithms approach, but no tricks. Uh, I don't I'm not going to say, oh, like, you know, you didn't find the the Uber optimization here. Uh, but I will say like, hey, if we wanted to change um, you know, this API signature, right?

So, um, you're not taking in a materialized list, it's an innumerable, or if we wanted to be able to filter on things like like what kinds of effects would that have, right? And when pe I use very similar questions when people are more senior, what I like doing is asking questions about that and saying, "Cool, imagine that you've delivered this, you know, uh, API into the codebase. Now, it's being used across a bunch of projects and now you want to enhance it. you want to make changes like what's the approach here, right? Like walk me through what kinds of things you would consider if you needed to go change, you know, some library function that's used in thousands of locations across hundreds of of different projects? Do you just change a signature and cross your fingers? Like, do you introduce a new one? What what considerations go into that?

And what I like about asking questions like this is that one, it's more relevant to what we actually do when we're building software versus, you know, magic around like some bit shifting or some I don't it's just not what we're doing. Um, and then there's not like a single right answer. And that's what I really like because in software engineering there's also not a single right answer for like basically everything we do. It's always a pros and cons analysis and depending on what you are valuing it shifts right so I can ask someone a question about you know the the API path and someone might say you know I would prefer that we don't have to introduce a new one. Um, and it would be like great. Well, why is that the case? Like, tell me about why.

And they might say like, um, you know, you know, if we're able to go, if we own all the code that's going to touch it and we can do it in like a sort of a sweeping change, then I would prefer to do that because if the build system can handle it, then we're not going to have, you know, this these legacy APIs that are obsolete sitting around that more people might call. Like, I'm just making this up, right? The point is that if they can walk through that and explain the logic, then I can sit there and go, great, thank you for explaining that. Like, what if what if that's not the case? What if the build system doesn't do that or you don't own all of the pieces? You have uh customers that depend on this. And just seeing how they they work through things like that.

I like seeing how people think from the perspective of working with code. I don't care that you didn't find the magic optimization because you can you can profile stuff in a real environment. We can talk about what the actual constraints are in a real environment. If you don't know how to do it, you can literally ask AI. Like it's to me it's just the wrong focus. I I care a lot less about like the the the I don't know how to say this like the the the list of facts that you know and I care more about like how you apply uh problem solving and navigating pros and cons analysis. So that's on the coding part. The system design stuff is almost the same, right? So when we're talking about building systems, the parts that I do keep consistent probably with a lot of like um I don't know other interviewers in this front is that I want to see that you understand the big building blocks, right?

There's it's too easy to just throw out buzzwords. So like cool, you want to you know, oh, we need a queue here. Okay, well great, you know, let's go through your design and then tell me tell me why the Q was helpful here. The the reality is again like there are a million ways to go build a system and for some of these big distributed systems that we talk about there isn't one single right answer. It's not like you know it's like oh the Uber system design do you think that on day one Uber just like snapped their fingers and they were like this is the design for Uber we got it like absolutely not. So to expect that someone could go design the whole system in like I don't know 30 minutes to an hour that's taken these companies you know years to build. It's silly.

So I don't have that expectation when I'm interviewing. I want to talk about like if you were to start and try to draw out the pieces like tell me about how these things connect. I want to hear about resilience. I want to hear about security. These things I put more weight on depending on what, you know, teams and stuff and the scenarios I'm interviewing for. I want to hear about eventual consistency. I want to hear about performance, how things scale, but like there isn't a single right answer. So, I don't expect that someone's going to like have, and this is why I hate these types of things in like traditional interview settings. Like, you could go online, go try and memorize all of these system designs that they have published for like Netflix and Uber and like having a social media feed. You can go do that.

There's tons of resources online for it. But I would much rather just listen to how someone's thinking about the different challenges, right? If we're talking about this thing has to scale to like support millions of requests, okay? Like if it doesn't, can you save a lot in complexity by avoiding that, right? I want to hear like both sides. I don't want to just hear like the final answer because again I think that when we're building real systems this is why like we talk about well I mean we've seen like the big swing between microservices and monoliths and back to model you know back and forth or whatever but when the answer is always you know the right answer is always the final answer I think that that's so silly because then you don't understand the other end of it so then you have all these

people that are like, "Oh, we have to go with microservices because like that's the thing that people said that was the right thing." And it's like, "Well, why is it the right thing?" It's always contextual, always. So, do you need Reddice and do you need to be able to like press a button and be able to scale uh scale to like, you know, a billion active users? And it's like, probably not ever for most of the things that you build. But if you did, what would that look like? I want to know both sides of it. So I like walking through my system design questions that way. Uh I tell people in the beginning of my system design questions. I will be changing the requirements as we go. I tell them that upfront so that it's not a trick so that they don't go wait a second like I designed this and then now you're you've changed it on me.

It's like no no you know I'm giving you some requirements and I'm I'm telling you upfront that I want to change them later on to see how the system adjusts. And again a very similar thing is for more uh you know more advanced developers. I like saying assume we built this system and it's been in place like as you've designed for three years now we're having some scale challenges or now we need to shift to something else like how how would your design change? How would you go roll this out like because this is a much more complicated thing than building a green field system. We can all sit here with a piece of paper and an internet connection and go, you know, design Uber. It's not like that's not mysterious, right? Like it's a solved problem. It's been documented. This is why people memorize all this for their interviews.

I just don't think that that's interesting. So, in both my coding and system design questions, I like looking at how people problem solve. And then I like trying to put a bit more of a a practical application on it, right? Like let's focus on the theory and more on cool if we have something like this and we need to make changes, how does that start to look? And there is no single right answer. So when I'm evaluating people, I'm I'm trying to listen to the the pieces that they're trying to consider, right? And then when they say, "Well, you know, I think that this is the better approach versus this one." It's like, "Cool. What are you basing that on?" And again, it's not that it's right or wrong, but if they're like, "I just don't know." Then it tells me that they've tried to memorize something or they're kind of just using buzzwords, but if they can say, "Well, this is the reason why." And then I go, "Great.

If that was not the reason why, would how would your design change?" Because we're going to be building where it's not always the same. I need to understand that they can move between this stuff. Okay, I'm almost at CrossFit. Um, the third is, and this is what I focus on most of the time, and I mean, if you're more curious, like literally watch any of my videos, cuz almost all of them on this channel, I'm talking about, you know, behavioral style things, project things, communication. So, in interview loops, if given the opportunity, I won't even do um coding in system design. like if there's other people, focus on that stuff. I'll focus purely on behavioral and project stuff. Um I really like talking through conflict resolution. I like talking about how um how people drive influence, right? Depending on your level, it's more important. If you're brand new, that's okay.

You know, if you're early in career, I don't expect that you know how to go influence an entire team or organization to go make changes. But if you are more senior, I I do want to dive into that. I want to hear examples of like, hey, uh when you disagreed with something, how did you approach that? Right? Whether that's a timeline for a project, how dependencies work, a system design, how does that look with a colleague versus a different team? Um you have a manager that's telling you it's got to look like X. Like how do you have that conversation? you just, you know, say, "Okay, like, guess I have to do what my boss says, or are you able to have a conversation through this?" Um, when you've had to give feedback to people, you know, how do you do that? Do you just not do it because you don't want to hurt anyone's feelings?

Have you done it, accidentally hurt someone's feelings, learn something from it? Right? I like asking questions. I spend a lot of time in my interviews trying to make people feel comfortable. I don't know if people actually do. I think that they do based on how they talk back to me. Um, but I think that that's incredibly important. So that when I ask questions like, "Hey, can you tell me about a time where, you know, you were working with someone and they gave you feedback, um, and it was really hard to receive, like how did how did you navigate that?" Um, or you had to work with a difficult colleague, like how did you approach that? Um, if people don't feel comfortable talking to me, then I feel like they're either going to kind of uh get flustered and not really be able to answer or they might kind of me.

And I would much rather them just feel comfortable and be like, "Hey, man." Like I've had people that were cursing in interviews and not not like at me uh just like because I could tell that they were they were so loosened up in the conversation that they were like, "Oh man, like uh yeah, this was really difficult and whatever." And I can tell that cool, I' i've reached a point with this person where they're able to like just feel pretty natural talking to me. And I don't care. Like I'm an adult. I don't care if they're cursing. I curse all the time. Um, point is that I have to get people a little bit more comfortable and then I can ask questions about how they navigate things.

Um, it's similar in the sense where there's sometimes I'll ask questions where someone will say, "Yeah, I was coaching, you know, here's how I approach coaching juniors or mentoring them and you know, here's a scenario that we and they walk me through it." And sometimes they'll give me ones that are like, "It just worked really well." And that's great. like I I'm happy to hear things like that and I might say, "Hey, cool." Like, you know, I see how you did this approach. How how might you adjust that if this didn't work? Do you either do you have another scenario that you want to talk through like that? Or if you don't, totally cool. Walk me through like, you know, what would you adjust in this? Right? You're trying to coach someone and um and they're really struggling, right? They're it's been a few weeks now and they're still not getting it.

Like, what might you do? Would you escalate? would you try a different approach at them? And so I focus a lot of my time on behavioral questions to see how people interact on teams because again I think we spend all of our time doing that. Anyway, I'm at CrossFit. Hope that was helpful. Uh if you got questions you want answered, leave them below in the comments and uh otherwise you can go to codecomute.com, submit a question anonymously or just go to any social media platform, message Devleer and uh I will answer your question. Thanks so much. See you next time.