Software Engineering Interviews: HOW And WHAT To Focus On

Transcript is auto-generated and may contain errors.

all right it is Monday the 13th I'm headed to work here I got a topic that I'm pulling from Reddit it's an interesting one I've talked about this kind of thing before but I figured it's top a Reddit might as well talk about it um so how are we all preparing for interviews these days this person says and this is for people that have been in the industry for a little while so I've been at my current job for almost a decade I haven't done any serious interviewing since before the pandemic starting to get ants in my current position want to dedicate some time to studying so that I can feel to interview in a few months so I think that's I think that's wise um I think personally like I don't do a good job of this but I think it's good for people

to basically be ready to interview um I don't want to say at any point because that might be like a little extreme but you know to be able to be comfortable interviewing um within you know like a few weeks to a month or something I would say is probably a good spot to be in for me like I haven't interviewed since before Microsoft right so I would need to go dedicate a lot of time to it so what resources and studying strategies are people using these days particularly if you already have solid years of experience under your belt um and then they talk about cracking the coding interview considered the Bible uh does seems outdated now you know leak code is still a popular answer there similar sites or resources that people are using so I'm going to talk about this from my experience um

let's get on the road here I had a bit of a rough start I was I'm trying to get to bed a little bit earlier saying my bag is too heavy on the passenger SE it's definitely not the heaviest it's been so stop beeping at me car um trying to get to bed earlier because I have to wake up at 5: for CrossFit why is it saying that it's really confused thinking that there's weight on the seat there's nothing on the seat anymore um but anyway if I have any sort of sleep disruption with my current sleep schedule it means like I drop below six hours of sleep and then I I cannot get up to go to CrossFit to function and I don't have any other physical activity aside from going to the gym so I'm trying to change that to get an extra

hour of sleep so in bed by 10:00 instead of by 11: this front passenger air airbag is disabled okay well good thing no one's there but there's literally nothing in this SE so what are you talking about um but yeah like I think at 10:00 I was trying to help a user on board to Brand ghost they're saying they're getting errors and when I looked into it it was like the LinkedIn API was telling me uh like they're throttling us like too many requests I'm like well what the hell I check on the portal we're nowhere near close to any API limits on any single API that they have so that's super confusing um and then I had another user overnight that was like hey I'm trying to refresh my LinkedIn account doesn't work they're being throttled um so I had to go open a

support ticket and be like hey uh why are you throttling us if none of the things show that we're near any API limits so um it's kind of ridiculous like the apis that we have for posting stuff are still going totally fine but um that they're throttling us on authentication requests so very bizarre so anyway got to sort through that but it um kind of chewed up that extra hour of time that I was trying to get so back to bed by 11 and then I had someone this morning that was being kind of ridiculous on LinkedIn they were saying uh and this maybe is a good rant if you're interested in a rant on this let me know in the comments and I'll consider it I'm probably going to get pretty heated um but there like I talk about software engineering management like similar

kinds of stuff on LinkedIn and social media and this person commented and said most people don't need to be managed and like I mean I think they're looking for they're looking for problems uh sort of commenting on the post to say that because it's like completely at odds with the things that I'm talking about um so I gave them a bunch of examples of and like there's I mean a million examples but gave them a bunch of different things where it's like these are things that I help people with like that's part of my role and uh their response was essentially something like you know none of that is helpful and like can tell by the response like it from oozing from your managerial PS is what they said um then they ended up deleting their comment so I asked them like why did you

why did you decide to delete that right like you're such a you're such a tough guy on the internet um by the way the interesting thing is this person uh does contract work so um perhaps they've never actually been integrated on a team or had to uh work in a business sort of uh trying to advance their career so I could understand maybe if they're like hey that type of work is ever been in alignment with me okay so yeah there there's your opinion but uh I don't think statistically that's an accurate statement to say that most people don't need to be managed in fact I think one of the interesting things we hear is that people will leave uh Bad Bosses or leave people that don't manage them so um I don't know maybe I don't know anything and I've been kind of just

wasting my time for 12 plus years but um interesting take so um back to today's topic if you have other questions that you want answered please leave them in the comments I'm happy to do that or send me a message on social media just look for Dev leader or Nick centino on LinkedIn uh happy to do that I've been trying to when I can if I find something good on uh on Reddit I'm trying to like drop a note to the author to say I'll make a video um reddit's a helpful spot for promoting things but I'm not allowed to self-promote so if you're watching my videos and you think they're helpful maybe you want to share them on on Reddit uh helps me uh but uh I've I don't want to risk getting banned on any subreddits for self-promotion so I shant do that

okay so prepping for interviews I think we have three different categories of things with respect to interviews uh regardless of your level um and I would argue even regardless of um your role and that's from my experience um and I think the thing that differs the most is the uh the level of involvement or the level of scrutiny maybe we can call it that go into each of these categories I thought that person was going to turn there's two left turn lanes and they were in the lane to my right and I'm already in the second left turn lane so no space for you um so the three areas are going to be your um your coding questions your uh sort of like system design questions big on and then your behavioral interview questions and all of them are important um and even like as

an engineering manager uh I've talked about this before when I was applying for big Tech positions so Microsoft Google Facebook Amazon uh they all have coding rounds even for managers um I think except I might have this wrong I think Amazon didn't um one of them didn't and I don't know if I just happened to get lucky and none of the interviews as interviewers asked me that um but I'm pretty sure Amazon didn't I have to get in a different Lane here this is very bad these people are going under the speed limit we don't do that here um like I'm still just about to get to the speed limit kind of crazy um so all three categories are important um and I would say like my my perspective on this stuff is the more senior you become the less and not only that like

if obviously if you're an engineering manager kind of working towards that direction um your time in code is less important because most management roles don't involve that I'm assuming this person's uh individual contributor so their coding skills are going to be important but I would say even as you're becoming more and more senior I'm personally less interested in trying to sort of scrutinize or gauge someone's coding ability in an interview the more senior they are and that's because a similar thing starts to happen like I'm going to need some proof that people can code right I'm going to need some proof of that but in my opinion if I had an hour with someone I don't want to spend the whole time just trying to make sure that they can write code because there are more like valuable things that I would rather be trying

to gauge uh again if you're brand new like you know early in career or Junior midlevel even um I need to get a little bit more proof of that because a lot of what you're doing is going to be that but as you're more and more senior there's going to be a lot more like expectations around like uh system architecture you're going to be in a position where you're leading projects right you're like the point person on them so you may genuinely find yourself writing less code because you're doing a lot more coordination and leading certain things um the the the type of impact you're having at higher levels requires that I can see that you're doing some of these other things more effectively so like that's where I need to see better system design I need to see better on the behavioral interviews so

uh you you'll hear me talk about this a lot but when I talk about most things I try to uh not do them like uh binary onoff black or white I like to talk about them on spectrums so if we had all three of these categories and we look at them on spectrums I would say uh if we take someone who's like a you know uh early in career right on a spectrum I would want to gauge their coding ability much uh much more so that would be higher on that Spectrum uh their system design probably less not because it's not valuable but because one they probably have less experience toing it less experience doing it and two I don't know if I said toing it uh and two um the expectations that they're doing that in their role at that point are probably lower

so I don't need to grill them as much on that I don't need to see as much so that'll be lower on the Spectrum and then behavioral interviews for me are always um like that's always a big component uh I personally have a very strong belief that uh software engineering has a lot more to do with um the interactions between people people than than maybe some people will um admit to or acknowledge and that's just because working with software engineering teams I have seen people that probably score very well on the coding part or probably score very well on the system design part and um they're a challenge to work with and then as a result we're not we're not getting the benefit of their skills and those other areas so to me the behavioral part is always uh is always important and then I

would say the more senior that you are um honestly the more and more important it becomes if you're a senior developer um what I would say is that uh like I you know the expectations around coding like it's almost like they need to be there but I don't want to spend the time in the interview trying to gauge that right uh the like I I will still do it but it's like I want to spend more time on system design and behavioral interview stuff so anyway that's this perspective from like how I gauge going uh through the interview process but those three things and and the reason I wanted to do that story is to kind of like paint a picture for you that if you were to go you know prep for interviews like those are sort of the priority areas in your time

allotment that I would recommend that you look at personally but the other thing to factor in here is that you might personally be better at some of these than others with respect to interviews so for example I think most people in uh like most companies unfortunately when they have coding questions they're usually like aite code style question I don't like these types of questions I think that it's uh like it's I look at them kind of like when I went to University and we had exams it's almost like the questions would be kind of like a trick and then the argument was like well if you really understand the um the domain or the the problem space like you should be able to like pick up on the trick and I'm like well that's I feel like that's kind of a thing to say because

it means that if I don't happen to get the the trick then you're saying I don't know anything because I literally will not be able to score any points on the exam and I find that like with lead code style questions the way that people gauge these in interviews can be the same like and I've seen this firsthand because a lot of places will have their developers doing the interviews to kind of crowdsource them right and I've been in these interview sort of like syns and people will say like no that person did bad and you might have like two people from the panel that are like oh they seem to do pretty well in mind like what did You observe and it's kind of like well I gave them this question and there's a trick to it they didn't get the trick and then

we're kind of sitting there like so so what like they they couldn't find a trick your question and you're so they're not going to be able to move forward because what are we testing here right like we're testing people that can find tricks like that seems like to me so um unfortunately a lot of places do ask questions like this though so I do highly recommend that you practice lead code style questions I if you see my other content I am not a fan of lead code at all um I will add in just because I know some people love it um if if you find that it's a great for you to practice and it keeps your brain sharp and you have fun doing it like by all means I'm not saying like you're not allowed to I'm just saying that I think it's

not a good representation of building software and that's what we do so like I just don't like it for that reason but if you want to supplement with it great um and I think too like for interviews it's a must I have said this before when I was interviewing in big Tech I hadn't like like this person who wrote on Reddit I hadn't interviewed in 8 years and I was going for a manager position and I still said I have to go grind lead code questions you might be so going back to what I was saying you might be someone that is already strong in lead code questions because you enjoy doing them and that's like sometimes you'll spend some time doing it great that's awesome you're one step ahead in my opinion from the interview perspective cuz a lot of us just don't do

that kind of stuff at work and we don't enjoy doing lead code questions but then we have them on interviews and it's like it's something that we have to get better at doing so uh that's one thing the lead code questions um the system design ones are kind of interesting I actually this person was asking about resources um I'm sure there are lots of really good resources out there I'm not sure of any off the top of my head unfortunately um so what I was doing when I was studying for mine was I essentially when to go look at um you'll see like high Lev things like how how Uber has like their system and how Netflix does their feed and how how Twitter Works their feed in tweets and how Instagram is able to you know have like their system work um so you

can find examples of this stuff online and I think the point that I found helpful was not to like try and memorize like like what does Netflix do like how does their system work exactly because like in system design at least I feel like that's not the point I've definitely seen people that have like memorized like lead code style questions and they can basically blast them out like it's like it's muscle memory but with system design I don't and number one for the lead code that's why I don't like lead code as well it's just like it's easy to kind of gamify if you're like just very good at doing those and you've seen lots of questions but with system design I don't think it's about memorizing as much or you can't use that as like a as like a hack and um so like

memorizing What U does or what Netflix does I don't think is as helpful but I think understanding those systems and why they made decisions is helpful right um you'll see things like um I think like the concept behind cues is really important and uh like eventual consistency is really important because a lot of the time we're talking about these really big distributed systems right you need to talk about um the different aspects that need to be prioritized in those systems um and you need to think like so that could be um latency that could be um like I was saying the eventual consistency kind of challenge that could be resiliency um like there's a whole bunch of stuff uh throughput so I think understanding what types of building blocks we have and how they can sort of affect those different things can be really helpful

um and when we talk you know things like resiliency and stuff like that I mean there's many building blocks that you can put into place for that kind of thing um you know it's just like understanding the pieces that you have to work with uh I think goes a really long way so if someone was like um you know sometimes you'll hear examples of like design a payment system or they'll give you a system that that should have some type of payments included and if you're trying to design this system and not thinking about the fact that like at different points things could fail um and someone's sort of transactions in play like are you going to build them twice is the building not going to go through and they're going to get the thing um they're trying to get a resource like a movie

seat or a ticket and now like 10 people bought it at the same time so like you have to think about when you're putting these components together how can you address these types of things so um I mean sometimes if you're thinking about them in a single process you can kind of rationalize them but the extension of that is thinking about a bigger system with many processes potentially um across different like across a big geography potentially um and you can talk about parts of the system going down too so what I found was really helpful personally was trying to take those examples like the Netflix systems or or Twitter or Uber and then basically what I would do is think about what they optimized for and then try to like kind of change some constraints if that makes sense and this is actually how I

ask these system design questions is like coming up with something basic like we're going to go design a system for buying movie tickets and then we'll talk through it and then when people design things I'll say great okay okay now that we've talked about why you made these choices let's change the constraints it's not a trick question it's like let's just you know enhance the question with something else like this is how you would design it for this reason what if I said now that this other thing was important what part of your design would you want to change right and then getting to see people um how they would modify different components of the system so going to pass this bus man it's too much so I like that kind of style um and I think something that's like really valuable when you're doing

system design questions is like it's pretty common that um and it happens in the coding ones too but especially for system design a lot of the time the questions will be left pretty open-ended so someone will say and this isn't always the case we just said an example like let's design a a system for buying movie tickets and um you'll say okay cool and you might your gears might start turning in your head because you were practicing some stuff at home already and you're like okay I know I'm going to have like probably something like a saga in there for and I might need like a queuing system and like you're kind of Designing but the trick with a lot of these is like if you just start putting stuff down on paper in terms of the system components you haven't actually asked them or

clarified like what things are important now you might have some ideas but I think it's extremely important to practice clarifying these things so like is latency really important are we talking about having uh these types of events where like a movie goes uh you know comes to theaters and like you know everyone wants to go see it and now we have to have uh we need to sort of plan for our system to to have like a ridiculous traffic surge right because how you design your system at steady state versus that might be completely different you might need to think about other mechanisms you need to balance that stuff out so it's very very important to to be doing that oh man this truck is in the way okay we're going okay there was a really big truck that was basically blocking all the spots

for me to merge in but when I looked ahead I could see that more people moved over so we had a little slice to merge so anyway I think that's how I would recommend practicing those system design ones but there's lots of resources so you can go understand like you know what compon components do we use for like what types of databases work uh in certain ways when we're talking about like acid when we're talking about eventual consistency when we're talking about being able to replicate data um what like what kind of patterns do we have like circuit breaker patterns like things like that for when Downstream systems are are um not available right like does the whole system fail uh like there's so many things to consider so I think it takes if you're not used to this kind of stuff understand the building

blocks and then make sure in the interview make sure you're asking the interviewer about the constraints they want optimized for we had to get in front of that Tesla there's no way that Tesla's getting in front of us um okay and then the last group is behavioral interviews and I realized I didn't realize I was going to spend so much time on the other ones but behavioral interviews are extremely important um I have a course on behavioral interviews on dome train uh I don't plug my my courses and stuff as much on this channel but I figured I should mention them like if you're interested you can go to doet tr.com uh that's a a site run by Nick chapsas who is a very popular uh C sharp.net content creator uh most courses are on there are C and.net related but I have a bunch

that are career focused uh with a another co-creator Ryan Murphy but we have one on behavioral interviews it's like 6 hours long we're both engineering managers at larger tech companies uh with over a decade of experience each so um I would recommend that if you're not sure where to start but one of the biggest things that I can recommend for Behavioral interviews is understanding that there's a point to the question being asked and when you're in behavioral interviews it's almost never about the technology which is I think really challenging for many software Engineers because you'll hear questions that are like tell me about a project you worked on when you know some circumstance happened so what do we want to do okay Mr or Mrs interviewer I worked on this really cool project here's what it did here's the system here's the technology choices we

made here's why we did that here's some of the Nuance details about how this thing works and why it's so cool but like I hate to break it to you they just don't care it's like there's a certain level of detail that's helpful for framing it but beyond that like it's unfortunately you're sort of um sort of wasting time you could be focused on kind of getting to the point of what their question is um so I think that like my biggest piece of advice is making sure that you ahead of time when you're practicing behavioral interview questions like understanding what those questions are after okay so um I made a video this morning when I was talking about some of these already so if you watch the previous one that I posted you know some of this will seem like repeat but um you

know if someone's giving you questions about you know tell me about a time you worked in a team and then they're tacking on to that like and then the project was um falling behind schedule or there was a conflict with a peer or there was a conflict with the person leading it or or pardon me or like tell me like what worked really well on that they're they're not after the details of the project itself like they don't need to know that it would you picked postest for that that you um that like it needed to be done in uh in Rust like you might love those things and they're fun to talk about but when they're framing it like you're working in a team okay so that means you had to be working with other people they're trying to get you to talk about

the interactions with other people then they give you the scenario that's like there was a conflict okay so how did you resolve the conflict with a peer right did you just avoid it did you just pretend it didn't happen did you go confront them and you were mean to them like did you just say like screw it I'm talking to my manager or did you like you know maybe Behind Closed do send them a message or have a conversation and say hey by the way like I noticed that we were not aligning on this I just wanted to talk through it and see if we can get on the same page so I can understand your perspective maybe we can agree to disagree but we should at least clear the air on this maybe that's a good strategy maybe you tried that didn't work and

they were actually really mean despite you trying to do this you got feedback from your manager tried it again blah blah blah but like that's what they're after they want to see how that you're you're navigating those things and like it almost had nothing to do with the project or the technology it's a behavioral interview question right so um I I'm saying this in like totally acknowledging like I I I'm a software engineer at heart right like I love Building Systems writing software I write code all the time outside of work I I tried to write code for like 15 minutes this morning before uh you know I I got in the car um like I I love writing code and I love building things but it's not always the time and place to be talking about those details so the other piece of advice

that I gave in the video this morning around behavioral interviews is this idea that like I think it's really important you practice your stories and understand them and I don't mean I said this again in the video this morning I don't mean like you become a good Storyteller by making things up uh or embellishing uh I mean that you have an understanding of the stories and sort of the key parts from your experiences right so that what you're able to do very effectively is you have a bunch of these sort of um experiences that you can draw upon and someone then says tell me about a time when whatever and ideally you have a couple of different scenarios from your experience where you can say ah I can go talk about X or I can go talk about y um and I say a couple

because if you're like me uh I get stressed out um and I blank out so I don't do well on things like written exams because they're very uncomfortable for me so I will blank out um and interviews like I'm I get nervous during interviews I've been on you know the giving end of interviews for over 12 years but I have certainly given more interviews than I have done for myself I understand how they work but it doesn't mean I don't get nervous so my preparation is making sure that I have a high level of comfort in the stories that I want to be able to navigate so so what might work well for you is thinking through some eventful things like in terms of deliverables projects collaborations things that have gone well things that didn't and maybe even just like Point form like making like

a note uh like a list of like what happened in each of those things and then what you might be able to do is do like a bit of a mind map and say like okay well this was a story that had like uh collaboration aspects this was a story that had um you know friction or this was an example of me like demonstrating leadership or you know whatever it happens to be but kind of like annotating or tagging your the stories that you have with um you know some of these things that people will be interviewing you for and that way you can recall them a little bit easier so that's my advice uh I think all three things are super important uh I think depending on your experience level I would kind of shift the focus but ALS so depending on what you're

comfortable with you may want to shift the focus as well because like I said if you're awesome at doing Elite code and maybe not awesome at behavioral interviews maybe shift your focus to to get good at the thing that might hold you back so I hope that helps uh best of luck with your interviewing I know like I said I know it's challenging it's not something that uh I feel comfortable doing but interviewing is a skill right the more that you do it the better you'll get so if it's hard and you're like beating yourself up over it like oh man I bombed that interview I did so terrible that's okay the next one you'll do better and that one still might not be good but it'll be better and you'll keep getting better you'll keep getting more comfortable okay it's just like any other

skill hope that helps I'll see you in the next one take care