Making Tech Interviews Less Awful

Transcript is auto-generated and may contain errors.

all right folks headed into work a little bit later than usual I had uh was conducting an interview so that was a little bit unusual for me cuz on my current work schedule I'm doing a bit of a hybrid approach not forced or anything uh but it's actually nice so I go in on Mondays and Wednesdays today is a Wednesday but the interview was this morning so usually I drive in uh and on those days where I go to the office I drive in right after rush hour because if I go any earlier the commute uh gets me there at the same time I'm just sitting in traffic it's really crappy Sor that Bru was driving super slow um so for now like I basically what it's like I'm going to be getting into work like right before lunch kind of thing so it'll be

a short day at the office but that's okay um the value I find at least the value for the most part when I am going to the office is is definitely there so if it's a shorter day that's cool um but I do you know I work with people in China and stuff as well so there's times where just because it's a shorter day doesn't necessarily mean um a shorter workday does not necessarily mean that like less work is getting done there's time spent uh after hours there's time like in the evenings or in the mornings so kind of just happens um like one of my meetings that's recurring pardon me every week is uh like 8:30 on a Thursday or 8 on a Thursday like it's in it's at night I don't know what it is cuz my calendar tells me so like there's

that kind of stuff that you know where does that time come from and like that's a 30 minute meeting but is it usually like overtime yeah so like you know the time gets made up so I I don't feel guilty or anything about driving in when I go to the office a little bit later after rush hour it's fine um and I say I'm saying that out loud because not any not that anyone's ever tried to make me feel guilty for it but I know that uh whether it's my employees or other people working in tax like there can be this fear of like you know what's the perception of this happening so I try to as much as I can lead by example to say like no I think that's fair um you know same thing if you got to run errands during the

day okay as long as you're like everyday is not like I need I need 8 hours to run errands every day like that's people are human there's going to be stuff that comes up it's fine so yeah so today was doing an interview remotely and I figured I'd kind of blab a little bit about interviewing and stuff cuz I it's an important topic um and it's important from like two sides right like the people obviously going for interviews I feel like that's probably the majority of people that were ever will will ever listen to this are the people that are going for interviews right and then a smaller minority of people are going to be folks that are doing interviews and that doesn't have to be managers or anything like that like if you haven't conducted an interview yet might just be because you're too

Junior and that's okay but um you know there there are people that you don't have to even be like necessarily a senior engineer to be doing interviews um so I'm hoping that as I kind of chat through different things so interviewing like you'll find Value in it regardless just so I can try and cover different perspectives as well but uh yeah so today was a remote interview um which I feel like they go pretty well like it's well structured I guess so I don't know I don't think at this point there's like too many hiccups and stuff with remote interviews uh like people not being able to get onto the call or if we're doing like a coding problem like nothing's working like I feel like that's mostly sorted out by now at least from my experience I've not been running into any types of

issues like that so which is good right we don't want to be wasting time time with you know fighting technology and things like that weird logistic issues so that's all goodness um and yeah like we break up interviews we have multiple it's so it's you know I work at Microsoft there it's a pretty common thing for I would probably say most companies but especially big tech companies like you go through multiple rounds of interviews sort of the expected thing to do now it looks different at different places right at some places you might have one in interviewer will be doing like I am or giving you technical problems to solve and you must go code them and then you'll have another interviewer in the whole interview is like okay you get a system design question um and then other interviews are like behavioral and like

kind of depending on your role and stuff like the the amount of those things change like shortest light I've ever seen in my life um so with so like for a manager for example right if when I'm interviewing for management position I still get coding questions um but if I had five interviews for a company they might give me like one coding question like so it's very light on the coding side at least for my experience they didn't like make it easier I've definitely had like challenging coding questions and and interviews as a manager so you get that and then I find most of it um is like system design and behavior old which I think makes sense as a manager right like you're going to be responsible for those things more than you will be writing code like at my job I do not

write code I haven't applied to places where I will be writing code at my job and it's not because I can't write code I write code every single day just not at work um but uh I've been managing people for 12 years now at the time I'm recording this and it's like you at least in the spaces that I've been working in if I get enough people on my team it's completely in effective to be trying to code now if you have small teams or you have like an Evergreen space or you know um sorry like a green field space not Evergreen a brand new product area kicking things off yeah like it can make a lot of sense that the manager in there coding and stuff and but it's cuz everyone's wearing multiple hats so I feel like that's a very different scenario and

I'm not currently working at startups right I work at Microsoft the teams that I've been on at Microsoft have not been like a brand new spin it up team like it kind of feels like a uh startup so that's not the case there's not a lot of space here um sorry this light's really crappy so for me like I'm going to end up getting a bunch of people on my team and I feel like once you pass like once you pass like five or six people reporting to you like if you feel like you have time to be coding things I just want to be transparent that it probably means that as a manager it's not a hard rule but probably means as a manager you're not spending enough time on other things like people and I am a strong believer that a engineering manager

your primary role is people um people have different opinions about this right like no like you need to be more technical no you're kind of like an architect position no you it's a project management like sure it's it's all of those things don't get me wrong but priority is people so Engineering Management interviews can kind of be skewed that way where you get a lot more behavioral but they still have system design kind of things because likely you're going to be responsible for some type of uh you know product or service area that is I mean if you're working in big Tech like probably some type of distributed system most likely uh or a complex architecture right something you have to support so you're going to be responsible for people that are building these things so they want to make sure that that you understand

what you're talking about I think that that makes sense um I do find like I'm trying to remember like I interviewed with Google Amazon Microsoft I had an interview lined up for Facebook when they filled the position the day of um so I didn't interview with them but out of those three that I mentioned that I did interview with one of those companies and I feel like it was Amazon I think it was Amazon I could be wrong one of those companies did not ask me a coding question uh and in fact I feel like Amazon maybe asked me like one kind of system design type question but they were heavily focused on on people type things and project type things and like I mean for me how I spend my time effectively is an engineering manager now it's on those things um I do

try to bring to the table the fact that I can program and uh that I understand reading code and navigating those things with my team like because that's what I do outside of work um but as a core responsibility like I'm not I'm not writing code at work anymore it's just it is it's not an effective use of my time and I don't mean to say that like I'm I'm better than that it's just different the role that I have in my opinion to be effective at it does not require writing code now that could change if I go if I was not at Microsoft anymore and I was working whether it was another I mean it could still be at Microsoft right if I'm working in a team that's small and has like a green field type of thing we're trying to to Pro

prototype or get off the ground like yeah like writing code could absolutely make sense right so when I'm interviewing software Engineers like today like it's uh and I kind of want to go back to this part too like I mentioned the structure for some companies is one interviewer does one thing um how we've been doing interviews um at least from my experience with Microsoft has been sort of combined like and and we get flexibility right there's there is consistency there is consistency but there is also flexibility so um there's no question Bank we don't go oh go to the the list of questions and you pick one I'll pick one uh so it doesn't work like that but we talk about what types of questions we're going to be asking making sure that we're uh from the technical side the coding side we're asking different

things uh we can discuss ahead of time the balance of system design versus uh like Hands-On coding right so if you're a brand new software developer you've never worked in the industry and we're hiring for that level it might not make sense to be asking like complex system design questions even if that person has the experience like we likely aren't expecting someone to do that at that level so there's not a lot of value in US like interviewing for that right um now that might come up in conversations and we can kind of you know extract that and say okay that's awesome that's that is a good set of skills and we can you know kind of poke and dive into it but in terms of like uh meeting the bar criteria like for really Junior people it's often not a thing um so yeah

we do get some flexibility in terms what we want to ask um but we also do like core competencies so it's not just like a okay I'm going to ask one programming question or a couple whatever uh Andor okay just a system design question it's not like that we split up the technical part so usually coding or system design some people have like some questions they set up to kind of flow in between I'll talk about this a little bit but they do that plus um behavioral and I I think that works really well because um I don't think for a lot of these types of questions you need to be spending like a you know 60-minute interview just like grilling someone on how to cat and I got to talk about this a little bit more too but um yeah like if you needed

that like how many coded questions do you need to ask because we're currently doing multile like you know a few of them are you going to double that up so that you can get the behavioral part covered too like it's just too much so I do think splitting it's good I think that that means that we can be more effective in how we're asking questions and I feel like I just feel like it's more fair to the candidate because it's already a lot of interviewing so okay a couple things I wanted to kind of go back to um from how you structure questions and stuff like that so uh okay well let me start by saying on the amount of time for a question like I don't think that the way the tech interviews are done in big Tech is effective for the most part

and I mean that from like the traditional sense like the stereotypical big tech technical interview I think is kind of crap uh and I say that because I feel like a lot of the questions are basically lead code style questions not bashing lead code but it's almost like there's a trick to this and if you know how to get the trick to optimize it like we're basically testing you that you can pick up on tricks and while that's cool like great for you if you can do that like I'm not trying to test for what I feel like is an edge case in your skill set I don't think that your career is going to be based on finding tricks in optimizations I would much rather you show me a working solution talk about how you're going to iterate on it and and what the

pros and cons are so I don't I don't think you need need for like one technical question like a full hour to like basically get someone there sweating trying to find a trick they're panicking right like I got the the naive implementation and it works but you know it's clearly not optimal and now I'm screwed because I didn't know that there's like this weird bit shifting thing like what who cares it's the likelihood of that becoming like a thing that you're doing at work that we're like thank God we h this person that knew this like trick I don't I'm not wasting my time doing that personally so I like letting candidates know who start the interview and I tell them I don't ask you trick questions and I want to get that out of the way because I want them to feel more comfortable

with me so I tell them if the question feels like very straightforward and it feels like I might be tricking you I am 100% not tricking you it is as straightforward as it sounds and you're welcome to ask more clarifying questions because I find it almost throws people off where they're like wait a second you're not you don't have some weird thing like I'm like no like cuz why why would I try to test you on that so try to be very clear and then we go through these uh these programming questions together and like I said I don't like to call them easy because that will depend on even the the day the person is doing it it might not seem easy but they are straight straight forward they're intended to be straightforward so I ask questions that way um when it comes to

like the structure of them I mentioned earlier that like some people will do a question that they can build on and go into like a system design kind of thing I think that's kind of cool um I think that can depend on the level and maybe if you want to if you do want to ask that kind of thing to someone that's more Junior like temper the expectations right maybe they nail the coding part but they they don't have EXP experience with a big distributed system but just trying to get them to see like how they think through it I think that could be great right um not trying to get them to rush the code and then you're like cool you got 45 minutes here to panic about something you don't know about you're going to leave this interview feeling terrified like nothing like

that so I think being able to kind of bridge questions keep a similar context can be good it's a lower overhead for for switching things around I feel like it's better for uh for the interviewer and the interviewee you know we can stay on topic we can build on things um and yeah I feel like if the if the candidate's already getting into the right mindset of a problem like you're you're keeping them there which is good so I do something kind of similar um I don't necessarily jump into like a system design type of thing I feel like I I can go more macro level so if I'm asking someone like a data structure and algorithm type question the most that I would do personally without trying to jump to a dedicated system design question is kind of like okay cool now you've built

this like what does it look like when we want to go put this onto machines right we're talking about this at scale does anything change like if we change some of the the constraints around where this code is going to be run do you have different opinions about how this stuff looks so kind of like a macro versus a you know we were hyperfocused right in the code so I I might steer that direction uh especially if someone's more senior just to get them thinking about that um so that's one part but the other part is that I don't change the framework of my question uh much at all between different levels of software Developers and you might go well what the heck Nick how can you do that like that doesn't make sense obviously someone who's more senior is going to need to have

a higher bar for being tested and like you're right you are right and I keep the framing the same but I change constraints so I will ask a question and I start it off roughly the same for everyone and I find that if someone's more experienced my expectation as they get through the bulk a bit quicker and then I can start adjusting constraints I can start changing parameters to the question and then I get them to navigate like how do we have to change how we've designed the code here sorry I got to watch on the road here for a sec there's a construction vehicle and I didn't know if I could move Lanes so I like that because one kind of what I was saying a little bit before it's less overhead for me I find that it helps me be a little bit

more consistent in how I'm considering candidates and things like that I'm not like all over the map but I also find it's really nice like I feel like it's a good candidate experience where they get some momentum with something and and then I can adapt it there's enough variations in the questions I have to change the constraints to make it interesting so okay now the API we're going to be using has to look like this or uh we expect a different behavior in this situation like how do you change things how does that algorithm change um how is that going to change the runtime now based on how you structured things like there's so many ways to go about it so that's been my strategy and I find it works really well um and yeah like just this whole idea of like having to have

like a million questions and stuff and have a bank for them like we don't have a question bank so there's a lot of traffic here I'm just I'm getting off the highway so this is a stupid spot you'll hear more about this um as I make these videos but I have to go from like the express lane and cut across and everyone's like pumping the brakes there's big trucks and stuff a bus no it's a garbage truck and I got to move over one more it's going let me in there we go um so yeah like I think you know today I did the same thing right in the interview was we'll set up the question a coding and I use I kind of just gauge how quickly people are going through things and then see if I sometimes I might cut them short and

say hey like uh youve I can tell based on how you explain your thought process and you've called out the edge cases and stuff like you understand what you're about to do uh especially if time short like don't don't waste the time going to go code it all out because you've already done that effort in some cases it's very apparent um so then I'll just tell that person great like let's move on to the next part and then I might add in a new constraint or changeing say great you answered it with this constraint where um you know we we have a double link list or we were adding stuff to the beginning now we want it at the end like just change the constraints around the algorithm and the data structure and then get them to to kind of work through what that means

which proba brings me to like another point about these interviews obviously what I'm saying is like my opinion right so people are allowed to disagree with that and that's cool um but the way that I conduct interviews is like I I just want to see how people are thinking about things I think this is mostly what people are after I have seen on LinkedIn uh and from people that I respect a lot I've seen people say like hey look like when I deliver things at work I'm not talking through that with someone so like it's unnatural for me to do that like that makes sense but like this is my opportunity to see how a candidate thinks about a problem if you just put the answer up on you know the the Whiteboard or up on the coding tool like I don't know if you

just memorize the leak code problem I don't know if you just I mean going to stack overflow when we're using chat GPT like technically that's a way that we solve problems in real life but I don't I don't know if we just got lucky that's the the part that I'm trying to get at is like I don't know how much of it was just like a one-off luck thing and it's another reason I don't really like a lot of these uh these styles of interviews so I do like people to explain what's going on uh I am much less concerned about how perfect the code is uh if there's small bugs here and there or whatever like if they explained what they were trying to do and even if they might catch their bugs I'm like okay cool like you caught it great like you

don't have to go code the fix for it like you explain that you know what to do great so just kind of like you kind of think as an interviewer you only have so much time with the candidate and you want to in my opinion the goal is not the goal is not to try and like I don't know like to gatekeep and be like let me find every reason this candidate sucks like like setting people up for failure that's not the goal the goal is that you have so much time and you want to be able to understand as much value from this person as possible so I think when you change the framing to be more like that then you can look for shortcuts you might like what value if someone's explained oh here's the bug I understand now here's how I would

go fix it like do I need them to go on a whiteboard or something like go prove that they can go write that pseudo code or or the the proper syntax like he just diminishing returns for how much time we have together so I try to look for shortcuts like that I think it's important cuz like I said you only have so much time behavioral ones are are interesting right I've been talking a lot about like the technical coding ones behavioral ones are interesting there's a couple other like techniques that are similar that I like to use in behavioral ones and part of it is like mention this with the the technical ones like trying to stay in the same space is pretty convenient for both the candidate and the interviewer so when we're doing behavioral ones these are often like tell me about a

time when and if you're asking four questions and you get four completely different scenarios like that could be great for a breadth of things like I'm not saying that's wrong it's totally fine in fact there's a lot of good to that but staying in a similar spot can be helpful because it's less opportunity for a candidate to feel like they have to re-explain a whole new project from scratch um you know if people are more senior I might say okay like if you want to jump around a little bit more so we can see some bread that's good but sometimes I'm more Junior folks um if they have a really good kind of story that they're talking through we might be able to relever that for different different behavioral focuses so um I find like for a lot of the behavioral stuff being able to

talk through projects is just like the basis for it it's pretty good cover a lot of ground that way but uh we do have to focus on like what did you do uh I've heard people have uh interesting opinions about this like oh if you hear a candidate only saying like I did this I did that it makes it sound like they uh they're taking all the credit and like um I get that but let me give you the flip side if if I'm interviewing a candidate and they say my team was responsible for my team did then I go okay well am I hiring your team or am I hiring you like I need to I need to understand you and I think there's a balance there right you can say my team was tasked with my team is responsible for this here's here's

what I did here's the impact I had here was my role in that and I think that's what I want to be able to to see um I find too like if candid it's if I've asked a behavioral question right and candid it's kind of framing the story and stuff if it's if they're going into too much detail it's kind of like what I was saying earlier I don't want to like like goal is not to gatekeep it's to extract as much value as possible right so if they're going off the rails a little bit into the Weeds on details I might be like hey look like no that's cool like uh what about and just kind of move the conversation along right let me get you out of that hole and then we can get to more uh more juicy stuff and you know

if that's a pattern that comes up I might take note of it that maybe some communication challenges more Junior folks might not realize that kind of thing that's fine right it's not like you fail I don't it's it's just not like that but it's uh it's more just about let me get you back on track so I can get you to have more opportunity to share like the good things that you've done so it's how I like to frame that kind of stuff but today was definitely coding behavioral um and yeah like I like to lean into like what they start telling me stories about like if I can keep building on that then that's great if it's not a helpful story I do the opposite so if they start telling me something and we go down that path if I have follow-up questions I

might say tell me like tell me a different thing and that way they don't feel like okay I'm going to use the same thing and they sort of have the same challenges uh cuz it's not going to help them I'd rather give them a better opportunity to do a better job so just uh parking here at the office and I'm going to wrap this up but yeah that was my my little spiel about interviews um it's kind of nice to be back on the the interviewing train because first few years at Microsoft I was SK I was on the loop but they never scheduled me so was like I never got to do them but I interviewed for like 8 years straight before so a lot of experience doing it but it's good to be back so thanks for tuning in and I uh might

even do another one of these on the way home so we we'll catch you on the flip side take care