A viewer asked what I look for when hiring senior software engineers! My answer may not reflect every hiring manager's opinion -- but I certainly do have a perspective on it!
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
hello it's Thursday January 16th I'm going to the office today which is unusual because it's a Thursday but I got to presentate real soon it's a pretty big presentation for me so I'm G to get there um we're going to go through a comment from YouTube um the question is when you interview senior software Engineers for hiring how important is it that they know Frameworks and popular libraries versus core fundamentals such as algorithms data structures and Elite code stuff if you know me this is going to be a bit of a loaded question but let's get into it um I think it's going to be kind of fun to answer um it only looks like it's like cuz it's early it's like 5:30 in the morning and I'm driving to the office um but uh I think it'll be interesting but it's going to be
quick is hopefully to get to the office um usually it's not usually Google Maps is like you're screwed um so we should be good but um if you want your questions answered leave them in the comments otherwise look for Dev leader on social media that's my main YouTube channel where I have edited tutorials uh and also videos on software engineering topics like this one but they are edited they're more succinct they're more concise if you like that kind of format you may prefer that channel this channel will be very much stream of Consciousness I'm going to be probably yelling at bad drivers and stuff because they suck um but yeah it's just a completely different format but similar topic so with that said um hiring senior software Engineers uh probably the way I answer this is going to be similar for uh for non seniors
too uh but I mean let's say like mid-level senior just to kind of bucket it all together um I'm going to start things off by addressing the elephant in the room that you may have picked up on uh when I was reading out the question but uh I do not group lead code into this at all um oh that's weird the crosswalk was flashing but there's literally no humans anywhere uh maybe they already disappeared um but I don't group lead code into this because I think lead code uh part of my Lang is um I think it can be a great tool if you find that it's like a good for you getting some mental I don't know mental gymnastics and practice and it's a green light holy what are you doing this person got to the green light and stopped it's not it's not
how that works uh lead code like I look at lead code I don't want to compare it to like doing Dooku problems um but when we're talking about lead code I don't like it because I don't think it represents the overwhelming majority of what we're doing in software development that is not to say that there is zero value that is not to say that you can't you know enjoy doing it and feel like you're you know practicing and problem solving more effectively I think it absolutely is a tool that you can use if you want to improve your problem solving skills however I don't think that it is the best use of time spent if you want to be a better software developer and as a result uh it is not something at all that I use when hiring uh and this is where my
bias comes in because someone will say hey Nick well what about all the job interviews that are out there where people are getting asked lead code questions you are 100% correct I will always tell people unless this changes at some point my career um that if you are hiring or if you're applying to places hiring software Engineers that the likelihood of you being asked a elite code style coding question is probably high but I think that that's unfortunate because I don't agree with it as a mechanism to gauge someone's abilities the reason for this if just want to spend a moment on this is that um okay so a lot of places will leverage their software engineering staff to conduct the coding interviews I don't think there's anything wrong with that um I think in practice though there's a bit of a challenge and this
is from my experience of like 12 years of hiring software Engineers um The Challenge ends up being that if you have people that are brought in to do interviews you're kind of crowdsourcing the interview process right and it I think it makes sense you're using software engineering who are skilled in the space to kind of conduct the interview but what ends up happening is that when people aren't on the same page for what we care about when interviewing which by the way is actually a very difficult thing to do you would think that it should be more straightforward but people have their own opinions about what's valuable and this is like me saying out loud I don't think lead code is valuable um some people do think that it's valuable and they think that way because that's what they were asked or because they don't
know of better questions to ask but one of the things that I've seen happen time and time again is that lead code questions typically have some type of like trick in them or there's an optimization opportunity and not all of them but a lot of them have this kind of format where if you were asked a elite code style question you could probably answer it in like a naive way where it might not be the most performant and you could make it work and then if you knew about some trick you could cut the runtime or like the memory usage into like you know by like orders of magnitude and like that's that's the the question is like that's how you you answer it is finding like this the secret and I think from my experience working with software Engineers going through these uh like
you have like an interview panel kind of going through the the results is that I've seen far too many times people go oh yeah like no that person didn't do well on the coding question and when we dig into it they end up saying it's because they like didn't find the trick optimization and in my head I'm like what are you interviewing for that how good they are at finding tricks or how good they are at building software because those are very different things um and some people will argue well no they're the same because in real software we have to look for all these types of optimizations and like sure but it's not like at some point you need working software and you can optimize it later so anyway I think that uh in practice asking lead code style questions is just a terrible
way of gauging someone's ability to build software sorry you got to merge some Lanes here okay so with that out of the way because I don't want to rant about lead code the entire Drive um the fun like the the rest of the question is I think really focused around fundamentals and like text stacks and languages and the answer is really uh for me at least primarily on fundamentals but I don't think I gauge them necessarily as explicitly that way what I'm like I'm not when people are like oh data structures and algorithms I'm not going to go test people that they've memorized data structures and algorithms uh I I it's even more like fundamental than that for me and it's like your ability to like navigate problems and communicate right so when I ask questions I'm not I'm not like okay like here we
go do do you do you have like the AAR algorithm or whatever memorized and like you can recite it to me because if if you were presented a problem on the job my expectation is not that you have a bank of like algorithms memorized but I think familiarity in exploring the problem space is important and the reality is that like you have all sorts of resources when you're building software so if you knew that you were dealing with like a graph problem and you knew that you needed to like Traverse things and then you could say like we want to do things a particular way or look for optimizations around this because of these reasons like I'm more interested in how you're thinking through it because like I was saying you're building software you're going to have tools you're also going to have a team
around you and like I don't I don't feel kind of like what the leite code situation I don't feel that you need to have the things memorized so unfortunately one of the the things that can happen and it's very common in interviews is that say you had a a question that was like a coding question you're asking someone and the requirement was basically that you needed to know like an a like AAR algorithm right for for traversing and you ask this question and the candidates like basically they they blank on on the exact steps in the algorithm what what I don't want to have happen is that this person fumbles the entire question even though they knew like If This Were Real Life they were like oh man I would want to go use a star I would want to use some like I want
to use some traversal algorithm or um if we're not talking about graphs we're talking about something else like they they kind of know there's an existing tool and they can get the gist of it but they can't remember like a step or something like that I don't want them to bomb the whole question and like personally even if I were asking a question like this I wouldn't like fail someone outright if they like were navigating this question and then like happened to slip up on part of it and then got stuck what I would try to do at that point is like ask them like hey so like like talk to me about what you're trying to do here like tell me how you know stuck like that you're forgetting a step or whatever it happens to be and then tell me about what it's
trying to accomplish because to me it's about the understanding of these things right I want to see how you think through problems and I want to I want you to communicate that thought process to me one of the other really kind of weird things that I've seen surfacing and I shouldn't say weird that's not fair something that I don't like fully agree with um but I can understand this person no lights yeah another with no lights um actually they had they do have lights on they don't have any lights on the back of their car amazing um I've heard people say and let me kind of I want to back up because I I didn't want to sort of make fun of it it's not really fair um I've heard people saying hey coding interviews are dumb because and if you expect me to like
debug and explain my problem solving out loud while I'm doing it like that's not how I work and that's not real and like no like I refuse to participate because like that's just not how I work and like part of me is like okay like I can I can get that that maybe for you to go solve things you need some some like time to think through but at the same time like I'm trying like the scenario that I'm generally trying to put front of people in an interview it's almost like look you're the one responsible for solving it but let's imagine that we're on a team working together and you're leading the charge on solving this problem right it's not about the specific code and the syntax I I want you to talk to me like we're going to be working on a team
together and basically if you are outright telling me that I cannot problem solve in a conversation then I would say that's probably going to be a weird team dynamic because sure you're going to be off on your own building stuff on some projects but some of the really key critical discussions and conversations in software engineering happened when we're working together uh just a very brief example one of my principal Engineers on my team um it's happened almost like coincidentally in a couple of 101s recently where we've been talking through something and then something comes up where we're talking about one of the designs that's ongoing and and we kind of touch on a detail and then we go down like this little bit of a rabbit hole where we're talking about the algorithm and then we start to like we're both learning different things and
we're like oh wait like maybe we should go approach things that way or maybe we don't have to do this thing Al together but if we were unable to have this conversation and discuss the problem solving through this algorithm we would never arrive at these things so like that is a key thing that I'm looking for personally so when we talk about like do I care this is again all of this is like my perspective my opinion um it's hard to give this as advice to other people like hey you don't have to worry about this because odds are you're going to run into someone interviewing you that does really give a about these specific things it's just not me because I don't I don't think that those translate into the like the software Engineers that I want on my teams and that's not I
should let me back up it's not to say that if you know those things like off the top of your head and you can do that that you're not going to fit on the team or you're not going to be a good software engineer you might be great you might be amazing I'm just saying that I'm not trying to gauge that as a requirement hopefully that's more clear okay so the Point around data structures I hope that's more clear now it's like I want you and sorry data structures and algorithms DSA I don't think that I need to get people to like recite these things and prove that they know them off the top of their head uh this is another thing that can be basically memorized and my goal is that you understand how to navigate problems like this and that you have something
memorized I would say the reality is that for senior software Engineers it's likely that they have like come across a lot of these things right and so if someone was like well okay should I have to go learn these things the reality is you if you've seen a lot of code you probably have come across whether it's graph raval stuff or other types of algorithms you probably have come across a whole variety of these things so yes it would be good for you to be exposed to these things for you to build software that leverages them to have an understanding of them so I'm not trying to say that like no there's no value you probably do need to experience things like this to build on that ability to problem solve and navigate things like that but my point is that it's more about understanding
the idea behind those versus just like regurgitating them to me because I don't need you to regurgitate exactly what it is because we could just look it up on the internet we could ask chat GPT like it's that's not proving to me the valuable skill the valuable skill as a senior to me is going to be that you understand how to go approach these things okay so uh I I just wanted to kind of elaborate on that so the answer very quickly on data structures and algorithms is like yes I think you need to understand them no I don't need you to recite them to me uh we went over the lead code part uh I don't ask lead code questions uh and then I think the other sort of aspect to this was like Frameworks and languages and it's going to be similar to
what I was saying for data structures and algorithms there's kind of like a overarching theme to how I interview and that's like uh when I sit down and interview people so like right now I work at Microsoft and C is one of the primary languages we use on our team uh by the way we do use C++ we do use rust but C is the main one on our team uh most teams in my space are using C but um when I interview people and we go through a coding question when I pull up the tool uh I can't even remember what tool we use um for for doing coding interviews uh the first thing I say is pick any language you want it's the very first thing I say to them pick any language you want because the reality is we're going to be
able to ramp you up in C because if you know some other language I'm pretty confident we can wrap you up in C and because fortunately because we're Microsoft we're a big company there's a bit of a sort of wiggle room in getting people ramped up on this stuff I've talked about this in a few videos now and I want to say it again what I'm telling you is oh man there's not a lot of space to merge there but okay if you insist um what I'm telling you is from my experience and how I navigate things there are absolutely situations like I worked at a startup before Microsoft for 8 years I mean it wasn't a startup by the end of it but in startup land you don't have such a luxury on ramping people up like you need really quick Learners like super
quick if they're not if they're going to come in and not know what language that you use so it's not that you can't hire people that don't know the language or the text stack but if you are a startup and I I feel like some people don't think about or like recognize like a startup is a business that's trying to get going many startups don't even make money yet right many of them have like some type of investment they're trying to get to a point where they have customers sometimes they have customers already maybe they don't even have investment and they're just trying to like scale up and there's a ton of pressure on the business to try and even remain in existence and I don't I think some people are like well it's a company so like therefore you know shouldn't have to worry
about these things and like that's the company's problem not my problem and like that kind of attitude in a startup is like not like the people who run the startup they don't want to tolerate that kind of thinking because a startup will probably not survive if it's filled with people like that it's just the reality it's going to be very difficult it's already going to be difficult to make it succeed so having people that are kind of like company problem not mine um it's it's going to make it challenging so um if you consider what I'm saying what I'm trying to get at is that startups don't really have such a luxury to spend a lot of time ramping people up because if it's going to take you know month to multiple months of ramping up and that person's not actually productive that's multiple months
of salary being paid out by a company that may not be in a good position to be spending money um for not having productivity and yes at some point there's going to be this weird growth pain phase where it's like we got to do it and like we got to try and suck it up and hope it works but like you have to understand that that could be a very big risk for companies okay so uh it's not that companies should never do that I got to move Lanes come on buddy it's just that it's very challenging for some startups given their financial situation and if you don't like that idea that's totally cool maybe that's not the right startup for you just something to consider so for me uh especially at Microsoft it's like don't I don't care if you know C or not
um you will likely be able to learn it pretty quick so all these people tailgating me today and and yesterday especially in like areas where like it doesn't make a lot of sense we're on a ramp right now offramp it's about to turn into an on-ramp you don't got a lot of space to be tailgating me and it's not going to get you very far give me one sec I just want to merge lanes here because it's a bit of a it's a bit of a blind spot okay so with with my teams currently like I said we have that bit of wiggle room to be able to make sure that people can learn languages um even when I was at Magnet forensics before like knowing C is helpful but like we had a lot of interns coming through on my teams uh and we
had a pretty good like mentorship culture in in general at Magnet forensics at the time I can't speak on on you know I've haven't been there for 5 years I'm hoping it's still great that was something that we always really wanted to build up but on my teams I had interns basically around the clock for eight years almost consistently every single part of the year not just summer so always had interns um and that means there's going to be people that maybe haven't even touched C before and that's okay uh and they're very Junior and we got to get them ramped up anyway but that's the thought process going into it um so in my opinion if you knew like an objectoriented language and you understood some Concepts we'll we'll get you there so um we would just spend a lot of time mentoring and
and really believed in that you won't find that everywhere um which is unfortunate but I I'm I'm trying to say this because I'm I'm acknowledging like it's very doable and in my opinion knowing one particular language and then trying to gauge Engineers just on whether they know or not they know that language I feel like is a a huge misstep and a huge M opportunity but uh like I said for some startups that could be um make or break for them on the teex St thing similar type of argument again you might have situations where startups are trying to bring people in that know a Tex stack to help like kind of beef up how effective the team can be by leveraging that text stack and if there's not familiarity they're like okay so we bring on a person and they're not going to you
know very quickly help get get us results because they have to go learn this like that's probably going to feel kind of crappy for them again I'm not saying like that I encourage startups to do this I'm just trying to acknowledge trying to give you some different perspective on this that they might be like man that's going to put our ourselves in a bad spot not because they don't think that you're capable at some point but they're like we might not reach some point if we do this uh just something to think about but for us like at Microsoft again same thing uh at least on my teams I don't care what tech Stacks you know um but the The Meta point that I was trying to mention from the previous part about data structures and algorithms it's kind of similar and that's you probably
would not be at the senior level if you hadn't used some programming languages at least one um and some types of teex stacks like like probably not it's entirely possible but the reality is like if you say you knew one programming language which is which is fine like for me I know C very well I know other programming languages but I don't actively use any other programming language not because I'm incapable of ever using it it's just that if I have to go build something I'll just use C and do it um so at least one language but if you knew Zer like if you never use something off of the Shelf to go build things that's probably going to be a little weird because the reality is you should probably not be building everything from scratch so you probably need to have some exposure
to Tech Stacks um but like again do you have are you an expert in one and um and we're hoping that it better be that one that we use and that's the only way that you're going to get hired like no absolutely not it's a like in my opinion if you're using Tech Stacks again startups would be like we want you to be familiar with it so you can be effective quickly and otherwise for me it's a understanding like what is this teex stack like what capabilities is it giving you why is that a valuable thing because that will help allow you to make decisions about is this the right Tech stack to use cuz we're going to be building software if we have to go build something new are you just going to say yep they hired me for this one teex stack we
must always use this because maybe it's not the right tool for the job and if all you know is the one teex stack and that's what we hired you for and that's all you ever care about are you going to actually learn other things or apply different ways of thinking man it's sweet no one's well one person's here what a nerd who gets to the office at 6:00 in the morning nerd me um yeah but I think it's probably my take on all that stuff so I hope that's helpful for some some perspective I got to you know read the caveat like this is how I approach stuff um the question was to me so I assume they want my specific opinion but the reality is like I don't want you to hear this and say oh everyone who's hiring will always do it this
way because no they won't so if you want my general perspective on this sorry my perspective for what probably others in terms of hiring would do I was trying to sprinkle that in in terms of saying like you may have this kind of experience at startups where they do want a specific Tech stack or a specific language I find it bigger companies you can e you have probably goes in two different directions one is that they're just like whatever we're going to tell you what we use and if you have some familiarity with something else like cool like good great you'll figure it out we'll be fine and we can use that you know period of time for you ramping up to be less effective because we know that you'll get there no problem or you have the exact opposite where they're like we have
a a very very specific role that we're trying to hire for and like we need you and to give you a I don't have a specific exam like we didn't just do this in Microsoft like for my teams but I could see this being something that we may have wanted and in terms of building rust expertise I could imagine that they would put a specific they might have like at uh not like a an immediate level like on my team necessarily but I could see that if there's a couple of spots where there's like an interest in building with rust if they were like hey look we want to hire in people that are really good at rust specifically and that's like a a strategic type of thing to say like sure yes we have PE and I have people on my team that were
learning rust all of last year and they became very effective at using rust great it's awesome but like they may have in different spots put up job descriptions that we're like we want to hire for rust specifically and that way we can bring in expertise into a team and then help the people that are learning ramp up even faster because they have someone that's kind of an expert in uh language in this case or maybe it's a text stack in other cases so it's not that this the very specific roles can't exist but in general for me hiring it's almost always like General software Engineers so I hope that helps uh again reminder if you want your questions answered put them in the comments below if you have uh specific scenarios where you want it to be kept Anonymous just look for Dev leader on
social media uh send me a message there uh and a friendly reminder that I have uh my main Channel Dev leader which is where all of my edited videos are if you made it to the end of this and you're like I hate this format then uh Dev leader is probably a better channel for you to check out because it's similar topics but um on that I have live stream that's at 700 p.m. Pacific every Monday unless like this Monday is a holiday coming up but I'm not going anywhere so I'll be streaming and uh we go through topics that are similar to what's on this Vlog so uh it'll be about software engineering if you want to know generally what the Topic's going to be uh I put out a newsl every Saturday it's called Dev leader weekly you can find it at weekly.
deev leader.com uh yes CA because I'm Canadian and I got a Canadian domain in 2013 um you don't have to subscribe to the newsletter if you're like newsletters are dumb I don't want stuff in my email like every Creator's doing that you don't have to subscribe to that's fine I'm just letting you know the topic will be presented there so you can go there on a Saturday Sunday or even Monday and go check out what the topic is and that way if you're like hey this seemed interesting I might want to tune into the live stream then you can or you might read it and say that sounds dumb I don't want to be on like part of the live stream for that that's cool too but that's where the Topic's going to be if you want to check it out it's weekly.
deev L.C and I think that's it so I hope that helps thanks again and I will see you next time take care
Frequently Asked Questions
These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.
- How important is it for senior software engineers to know frameworks and popular libraries compared to core fundamentals like algorithms and data structures?
- I primarily focus on core fundamentals rather than frameworks or popular libraries when hiring senior software engineers. I want to see their ability to navigate problems and communicate effectively, rather than just memorizing specific algorithms or frameworks. Familiarity with fundamentals is important, but I don't expect candidates to recite them perfectly, as they can look up details when needed.
- Why don't you use LeetCode-style questions in your software engineering interviews?
- I don't use LeetCode-style questions because I don't believe they represent the majority of real software development work. These questions often focus on finding tricky optimizations rather than building working software, which I think is a poor way to gauge someone's ability. While LeetCode can be a useful tool for practice, I don't consider it a valuable metric for hiring decisions.
- How do you approach language and tech stack requirements when hiring developers, especially at large companies versus startups?
- At large companies like Microsoft, I don't require candidates to know the exact language or tech stack we use because we have the resources to ramp people up quickly. I encourage candidates to pick any language they want during interviews. However, startups often need quick learners who already know the specific tech stack to be productive immediately, as they can't afford long ramp-up times. So, language and tech stack familiarity can be more critical depending on the company's context.