The Other Side of Software Engineering Interviews - Principal Engineering Manager AMA

All right, we're seeing if things get connected here. Hope the answer is yes. Okay, Instagram up and running. Let's see if Substack is going to do the thing. Substack's doing the thing. Okay, we're probably good to get rocking and rolling here. So, welcome folks. If you're new to the live streams, these are very much AMA format. So, please, if uh you're comfortable, jump into the chat. I'm happy to try and answer questions. I you can't see the setup that I'm looking at, but I got I got three screens and there's chat windows everywhere. So, uh please by all means, if uh you have questions about software engineering career stuff, even if it's not related to the topic we're going through, please drop it in the chat. I'm happy to try my best to answer. And uh there's usually people that join that are smarter than me and that way they can share their perspective as well. So, um, you know, and if that's you, right, if you don't have questions, if if there's people asking stuff that you feel like you got some experience, please, please jump in. I'm happy, uh, to give people that opportunity to share their perspective, too. So, welcome. Uh, I do these streams every Monday, 7:00 p.m. Pacific. So, if this is your first time, uh, welcome. And hopefully this goes well and I'll see you next week, too. And so generally the way that these flow is I have a handful of YouTube channels and one of them is called Code Commute. And code commute is where I do sort of like a Q&A type of format. People can submit questions and uh then I try to make a vlog entry where I talk through them. And so you know you can submit something that's totally anonymous or if you comment somewhere it's public anyway. Um and then I go through try to share my perspective around uh you know whether that's my experience if it's in something in software engineering and then after the week goes by uh on a Friday I kind of look back for the week see what the most engaging video was on code commute I write a newsletter for that on dev leader weekly and this week's is going to be the other side of engineering interviews. I'll just drop a link in the chat. Folks that are on Substack, you already know where to look because you're on Substack. For folks that are not, that's just at weekly.devleer.ca. And uh so this one's going to be about uh software engineering interviews. Uh I'm going to talk about sort of being on the other side of that, being the the interviewer. Uh we'll kind of go back and forth a little bit, but I wanted to talk through this because well came up from code commute and uh you know I had a couple of things recently where when I was reflecting on this it felt like kind of like something struck a chord and I was like I feel like I want to talk about this and and kind of talk about my opinions about how software engineering interviews go. And so if you're interested in knowing what topics come up on the live stream, like before they happen, basically watching Code Commute, it's a good way to see the topics and then at weekly.devleer.ca every Saturday when I put out that newsletter article at 5:00 a.m. You don't need to go subscribe to get the emails or anything if you don't want to, but you can check Saturday, Sunday, Monday, and you'll see what the topic's going to be for the live stream. So we'll jump into things. uh you can follow along if you want to pull up the uh you know the newsletter article. It's you could treat it like a blog post basically, right? Um I'm just going to share my screen briefly so you can see what I mean, but this is the article. Um I had a hell of a time with this one uh to get the thumbnail. I'm not artistic at all and everyone's been talking about Nano Banana from Google and how it's so amazing and I was like, you know what? like it's my turn to use Nano Banana and have all of this awesome success like everyone is saying. I have never been so infuriated by an AI tool since AI tools have been I was I guess that's really not that long. Um, it was the most frustrating thing that I've ever touched and I never want to use it again unless they completely change uh away from how terrible it is. Um, I've had some bad experiences with like AI agents kind of doing silly things and getting frustrated by it, but this was like insane. Like uh telling it to the first one I had was a thumbnail. I got to talk with my hands again. Sorry. I have an Italian background so it happens. I talk with my hand. So I I had split the image in half, right? And it was like I wanted to show like two sides to the interviews and so it drew you know it split the image in half and I was like awesome. And I'm like okay so do this on one side, do this on the other. It's kind of painful but it started to get it. I said great. I want you to put a red arrow going from one side to the other. And it did it. It put a red arrow, a tiny one in the very middle of the screen. And I said, "You need to make the arrow bigger." And I asked it three or four times. Didn't change anything except you can tell if you're looking at the phases in the picture. They're they're slowly deteriorating. And so I'm like, "Okay, like you need to make the arrow." I'm like, "Maybe I'll be specific. Move it up 50% and make it 200% the size." So it moved it up. It made it 200% the size. And then it wrote 200% under the arrow. I was like, "Okay, one step in the right direction. I want you to remove the 200% text." And then it just rem it just put it back. So it made a small arrow directly in the center of the screen again. And I'm like, "Okay, I going back to Canva for this." Um, so my my silly thumbnail, my thumbnails are not great, but this one was made in Canva. But like I said, you know, the we're going to go through this article. Um, I'll try to paraphrase and stuff and and give like slightly different perspective as I go through. So, it's not going to be word for word, but um, okay. So, I have some some frustration with with, uh, how software engineering interviews go. And, um, Taylor in sorry, in the Substack chat says, "AI is just AI has destroyed my life." What do you, Taylor, what do you mean by that? What What has AI destroyed for your life? I feel like I was I was already like going bald and uh definitely uh AI has solidified the the fact that my hair is never coming back. But um for for this topic, the I have a lot of challenges or things I dislike about software engineering interviews. And you sort of at a high level with the some of the you know the meta point or the takeaway from this whole talk is that um this is a sweeping generalization of course because I realize not every company is the same but I feel that a lot of software engineering interviews are set up in a way that does not assess candidates in a way that is sort of doing anyone a favor for how they'll perform on the job. And so a couple of factors or you know points to bring into that are that like the things that we are quizzing people on especially on the technical side um I feel like is often not aligned. If you've watched my videos before you'll know I don't like lead code questions lead code questions are a perfect example of that. Um, sometimes system design questions depending um system design questions depending on who like what question you get, who's interviewing you and stuff can be uh kind of set up to like basically just kind of trap you and trick you. So, I don't think that that kind of stuff is good. And on the topic of trapping, tricking, and being kind of deceptive, even sometimes behavioral interview questions can be like layered in a way where you're being asked something and the interviewer is looking for you to say something. But it's almost like if you would have just been more transparent or straightforward with the question, then I could give you a better example of that. So, kind of in a nutshell, that's going to be some of the things I'm talking about. Uh Taylor says, "Back on Substack for AI destroying uh their life. Uh taking the jobs, brother." Um so yes and no. I think that uh definitely think the job market's hard right now. I think there are some companies being completely stupid and saying like, "Oh, we don't need engineers. We'll use AI." Uh but there's a you can like AI is not the only sort of factor here. Um we had a very large event across the entire world a few years back uh where a lot of people went to go work remotely. Uh there was an extreme surge in hiring extreme and that has gone back the other way and so at this point in time there were a lot of people sort of flooding into the job market. Uh I'm not saying that AI is not having an effect, but these effects are being felt uh before AI was even being talked about like it is right now. So um I think I've talked about this a lot before. Uh, I'm not going to dwell on it too much here, but I think there's a lot of factors and then we end up getting a lot of confirmation bias when individuals are having challenges getting jobs because one of the things that is pumped in the media that you will see non-stop is is the fear of AI taking jobs and that being the, you know, the end of the world for developers. Um, people are, you know, they're they're making the memes and surfacing them. You know, six months ago you said all the code was going to be written by AI. Guess what? It's not. And so um it's not that AI is not beneficial. It's not that we can't use it in productive ways, but it's not it's not replacing everyone. Um so yes, there are some companies anchoring onto that, but um we got to we got to look past that. It's going to be a bumpy road for a little bit, but I don't think the I don't think AI has been the uh the driving force behind that. um you know I I work in big tech and when you know before we were even talking about co-pilot and software developers and all this stuff like at least for the space I work in I can't speak for all of Microsoft of course um I can remember us talking about slowing down on the hiring hiring freezes and stuff like that the the exponential growth that was kind of happening is just not sustainable right and this is talking like one company like Microsoft right but if you look data for any any company that was having a surge during uh sort of lockdown times with a lot more cloud uh software being developed, services being provided. There was a lot of scaling up. There were some small companies that kind of uh you know completely went bankrupt because they couldn't exist especially with lockdowns and things like that and a lot of software companies that were offering things that would flourish during that time um took off. So I think there's I just think that there's more factors there. And so I think my number one recommendation is if that you're, you know, afraid of AI taking your jobs and stuff, just like continue to focus on AI tools evolving, don't ignore them. Leverage them, learn them, uh, learn what they're good at, learn at what they're not. Pay attention to as the iterations are coming. But, uh, it's not if anyone's like kind of looking at the news and they're like, well, it's the end of end of times for software developers. like it will be for you if like if that's what you anchor to and for everyone else who's like okay like let's see what's going on let's let's ride the wave let's keep you know learning what we need to learn let's keep pushing forward on things like those will be the people that kind of adapt and um eventually have success so I don't mean to minimize it I'm not saying it's easy but I don't think it's the end um certainly so okay so interviewing I think that there's there's a lot of stuff broken with it and I can say this even like as an engineering manager when I was interviewing in big tech one of the things that I had like I'm I don't write code at work today I was literally writing code today we had like a fix hack learn hackathon thing going on and um I was writing code today but I write code every single day and um I've been in big tech interviews where you know I get the lead code questions still I've been managing engineering training teams for 13 years and you want to give me lead code questions like what the hell are we trying to assess here? What like I if I have to do anything remotely close to lead code questions like in my job like not the job for me. um but that we do the same thing for software developers, right? So, I think that there's a lot of misalignment with this kind of stuff. And when I was the interviewer more recently for a few candidates for for some individual like uh individuals in my org or I guess roles that were open in my org, um I was thinking about this because when I get on to these calls, um I I do this thing where I I like literally tell people at the start. I'm like, "Hey, we're doing intros and that kind of thing very briefly." And I say, "By the way, when we get into the questions, like here's the flow of how I'm going to talk through things." These more recent ones I did were just behavioral interviews, no um no coding questions, no system design. But I've done the same thing for those. And I say in the very beginning, I say I don't I don't ask you trick questions. I say, "If anything's not clear, please, I just ask. Like, I'm happy to try and make it clear. My goal going into this is like I want to learn about you and give you the opportunity for you to tell me about all the awesome things you do. So like I'm not out to trick you. And in coding questions or system design, I will tell them, by the way, as we walk through this, I will probably get to a point where I say, "Thank you. What happens if we try to change these constraints?" And I tell them this upfront because I want to see how how their design would change, how their code would change, API surfaces, if they're building a system, like, hey, we have a different constraint we're prioritizing for. What parts do you think that we need to change to to make up for that? And I tell them this upfront because I don't want it to be a surprise. I don't want them to feel tricked because there is literally no benefit to anyone in that situation, right? So I think that having clear intentions and making them very a like the candidate very aware of that in the beginning for me is very important. Um couple things that that come along with that. So one is like transparency about the flow of how things are going to go. Um the the other thing I I feel like personally is that it gets people more comfortable. If you're like me, like I am not the best at uh exams, like exam situations and interviewing and I could study, I could prepare and if I find myself in those situations, I will do the thing where you like you draw a blank or you're like your brain just stops working cuz and like it's a vicious cycle because you know what's happening and then you get more nervous and then you're like like I don't I don't what do I do? Um, and even though like like for like live streaming and vlog entries and stuff like I've done hundreds and hundreds of videos where I'm just talking to a camera like this and you know there are times where like as I'm and I'll do it a bunch on this live stream where I'm talking and I kind of screw up and I'm like, okay, I got to I got to figure out what I'm saying and continue on. But what's different in like these these other situations I find is like it's almost like I dwell on the idea and even after doing so many videos I still will run into these situations where if you put me into an exam or like test kind of scenario interview same type of thing if you put me into something like this I will freeze up and then unfortunately what that means is that you don't get to assess what I'm actually like to work with unless the job is going to be me being permanently interviewed. So, I try to like channel that when I'm interviewing people and I try to remind myself look like what can I do to make individuals comfortable? So, like I like to lean into humor a little bit like you know kind of just make people feel more comfortable like hey like I know you might be nervous like it's cool um being transparent about the format of the questions and stuff like that. So lowering fear, getting people more comfortable, and that way it's an even better opportunity for them to like actually talk to me in a way that's going to be like helpful for them. My goal in an interview, I'll talk more about this, is like I'm I'm not trying to set up the interview such that I get to sit there and try my best to gatekeep and be like, "Okay, like what can I throw at them to make sure that they're not going to get this job?" It's like, it's literally the opposite. What can I put in front of people that's going to help them demonstrate their skills that matter for this role, their skills and experiences that matter for this role as effectively as possible. As I navigate that, I will be looking for red flags or, you know, some things where I'm like, "Oh, there's some gaps here." But I want to make sure that I'm getting giving them the best opportunity to kind of uh, you know, share their experiences and their skill set. Uh, and then finally, just on that, like I think that if I'm putting myself in a situation where I'm trying to explain to a candidate, here's why I'm asking you these things here. Here's like the format of it. It's a good opportunity to like be thinking like this is this is the kind of stuff that is going to be relevant for this kind of job, right? This is the kind of stuff that would be experiences and skill sets that are relevant because if I have to go explain this to someone and I'm like, "Oh, that sounds stupid." like like why would I ever be talking about this? That's a good indicator like maybe I'm not talking about the right things. Right? So to give you an example in a behavioral interview, if I was like I want to ask some things about uh interpersonal conflict, I want to talk about some projects and I want to talk about um I don't know what's another good one like like coaching and mentoring, right? like those are things that those are behavioral style questions I can talk about that I feel are very relevant for a role. And if I, you know, if I only focused on like just project stuff in my head, like if there's another interviewer that's going to be talking about those other topics, I would feel okay about that, right? Like I got this one, they'll cover the others. If there isn't, like I better make sure that I'm trying to cover the necessary things. And if I'm talking about something that is completely unrelated, which those three things generally are pretty related to someone's experience, then it's like I I would feel awkward saying this to someone. So like it's just another gut check for me and something that's going to hopefully make this person feel comfortable about what we're going to go over. Which kind of brings us to like the next one. So use questions. This is from the the newsletter article. Use questions that look like the work, right? So I think that especially if you're getting into like technical questions, this is where I find it's more obvious, giving people like if you're doing coding questions, give them the opportunity to like to go work in a language of their choice so they can be more comfortable doing it. Um, give them and like the reason for that is that if you're forcing them into a language that they've never touched before and you're like, "Well, this is what we use here." Like that's not it's not what you would do even if you were ramping them up, right? If you're going to hire someone on, and this is going to look different at different companies, but if you're going to hire someone on, there needs to be a learning period. You're not going to test them in a language they don't know. So like give them that option to write stuff in the language they know. Um, I think something that I find is really helpful is like I like I don't like lead code questions like I will, you know, I'm happy to discuss that more in depth if people care to understand that more in depth, but I think what's works better is when you're walking through code, ideally if you have something where you can literally walk through a problem that's in like a code base and get someone to debug it or talk about how they might build a feature out like something that's closer to pair programming where they're doing a lot of the driving. I think that kind of thing works extremely well for understanding what it's going to be like to work with someone, but like what what are the things that they are talking about and focused on when they're navigating code? I think like this is really what matters more. I would rather see someone talk about like how things are connected together. I'd rather see like what tradeoffs people are going to be making in designs and things like that. and designs like as in like it could be design of an API, could be design of how they want to set up some classes or like just their approach for building out a feature. But this like to me this is significantly more real and relevant to work that we're going to be doing because what we're not ever doing ever is starting up a new project and then going like let me go build an algorithm that is something that we could find pre- can somewhere else like it just it never happens. It is a completely unrealistic take on on testing someone's skills for software. It's you could be arguing that it's good for problem solving. You could argue that that kind of stuff might be good for seeing how someone thinks through problems. That's fine. Or how they communicate through them. That's fine. But I don't think that it's a realistic scenario to go through. So like why not give them a more realistic scenario more relevant to the job and then have them talk through that? just seems to make more sense to me. I feel like one of the reasons we don't do it is because it's easy to go find an example lead code question or pull it from a question bank, right? And then just let me just fire this off at someone. I've asked it a million times. I can, you know, I can go through this with my eyes closed. But for a candidate, it's like it's it unless they go grind lead code questions, it's probably not going to be very relevant to them. Um, but yeah, I like the other thing that I made a note of is I like the idea of I'm interested if people want to jump in the chat on this one. I personally like the idea of going through some changing of constraints because I find that in coding questions or system design questions, you set something up and sometimes this is the kind of thing where um I feel like sometimes for like lead code style questions, people can go memorize them. Even the system design questions, someone's like, "Go build Instagram. Go build Twitter and or build Uber, right?" It's like, "Okay, like if you go online, you can go study all of these systems and like almost try to memorize like here's, you know, you got to put the Q here. You got to use this type of database and you could almost not know what you're talking about and just like try to regurgitate it." But like is are you trying to just test that people can memorize things? Like I don't know. I I literally know people that I went to school with and this is over a decade ago that that did this kind of thing. I just don't think that it's very helpful. So I like being able to say let's talk, you know, let's here's some code or like a scenario to code. Here's a system. Here's the constraints we're starting with. Start putting things together, understanding their thought process and say great. Okay. Like if we wanted to optimize instead of throughput, we wanted to minimize latency or like we need to think about um you know like how how consistent the data is because we need to make sure these updates are propagated. If that's the new number one focus like what would you change about this? Right? Because to me that's like getting someone to not like prove that they memorized everything and they got all the tricks and stuff. It's really like how do you think through a system when like so I can see the trade-offs that you're making on Instagram. Uh Danish, hi. I can't tell if you're still on here, but hello if you're still there. And uh Islam code on Twitch. Yeah, quick question. What's what's up? Feel free to just fire away. Like I said a little bit earlier for folks that are joining, like if you have questions at all, it's an AMA format. I'm going through a topic, but if you just want to ask about anything, I will completely derail, but just put it in the chat so I can I can see what's up. Um, I think the the next part, this is kind of me going back to like behavioral interview questions. So, um, I think for the most part, I have less of a problem with behavioral interview questions. Um because I think behavioral interview questions in general are trying to touch on the things that I actually care about more. Things like technical skills and stuff like that. Like sure they they help me get an idea for like how much experience there is. But like to give you an example, right? I've I've seen people and I've worked with people that were interviewing junior developers and I remember like getting to the end of an interview loop as a as an interviewer and someone was like, "Well, no, I don't want to hire them." Like this junior like they didn't they don't know what unit testing is. And I'm like, "Hold on, hold on. This is a new grad." I'm just making this example up just to to give you the the idea, but like this is a new grad. When I was in university for 5 years, we we didn't even talk about testing. We just it just wasn't a thing. And so like if you didn't have that exper I had six internships and like testing came up, but like I worked at sometimes like mostly at startups and stuff. I worked on a prototyping team at one startup and another startup I worked that went there twice, I was the only developer and I wasn't writing tests. But you know what's really cool about not knowing how to write tests is that I could teach someone how to write tests very quickly. Like that's not a thing that I need to like gate a junior or like early in career person on at all because it's a skill set that if I need a junior to do it, the the barrier to entry on that is so low. Like that's the least of my concerns. So I think that like behavioral interview questions I find are more valuable because these are the types of things that are telling again this is my opinion on it like are more telling of like how people are going to work together and I care about that more right I I think having the experiences to be able to walk through and say hey I have lived through this kind of thing here so I've navigated it like that's really good to show me you have the experience in doing it, but changing someone's behavior is significantly more effort than like teaching them a skill. Now, don't get me wrong, there might be people that we are like we have a role open where we're specifically looking for someone who is like an expert in some area. If that's the case, then if I need an expert in some area, I want I want them to be able to demonstrate that. But a lot of the time, especially for more general developer roles, like I want to know that you have some experience building, you know, systems of a certain scale or, you know, at least that you've shipped production code, this kind of thing. Walk me through those experiences. But I want to know how it is to work with you. Carlos says, "How do you handle if you find out someone who passed your interviews is not performing well? How do you uh so, okay, there's a couple things here. How do you tell the new hires the expectations for how long under probation period?" Uh, so how how do you handle if you find out someone who passed your interviews is not performing well? Um, Carlos, is this more like like a someone that I've hired or like from a different team? Because uh I guess I have not ever had and I'm not I'm not saying because I interview perfectly. Uh I have not done interview loops as an interviewer for someone like say another hiring manager and then someone gets hired and then like months later they're like by the way that person was a terrible fit like you know underperforming or anything like that. I've never had that experience. So uh again not I'm not saying it's because I interview perfectly. I just can't answer that for you with an example. Um how would I I would like to know what it is. Um, and often I think so far in my career, let me let me not say in my entire career, but at least more recently at Microsoft, I would say any shouldn't I can't say any, but most of the time if I'm talking to like talking about scenarios where there's underperformance, a lot of the time it's not technical. It's like I think someone's technically capable. It's it's more about engagement where it's like they're just very disconnected from what they're doing. They're not engaged. They're not seeking help. They're not talking with teammates. They're not responding to me. It's like I can't I can't help you if you're not even being engaged in the work. And then trying to set something up to improve that and it kind of continues to fall apart. U but that's more about like kind of observing someone's like uh like work productivity in general. So um kind of let me tie this into the next uh question you have. How do you tell the new hires the expectations? So uh this looks a little bit different depending on the team and stuff. Uh I very much believe in situational leadership which means that like I if I were to just take a cookie cutter approach to everyone in and every scenario I think that it would fail um or at least be ineffective. Now that does mean that I try to set expectations. Generally, uh, my expectations for new hires are that we're going to give you something that is well understood or mostly well understood, which means that, you know, I want you to go look into the problem. Usually, it's like a small feature or a bug fix, for example. Want you to look into it. I want you to feel a little bit stuck because I want you to be trying to think through this, but I want you to time box that kind of stuff. And then I want you to make sure that you can talk with people on the team to be able to kind of, you know, take it to the next level and figure out the problem. But I'm very clear with them that I want you to take this opportunity to learn because I'm not giving you a critical bug fix that I needed fixed like two weeks ago and then like you better figure it out right now or else. It's very much like a this is lowrisk and especially for more junior folks. This is low risk. you know, someone on the team probably has a couple of different ideas for how to go solve this, but like let's kind of set you up to kind of learn through it. And then it's really about clarifying the expectations that this is to build momentum. So the next one I give you might look kind of similar, but we're going to build this momentum where you can become um a little bit more and more independent each time. I'm I try to be it. This is where it deviates a little bit. I find with very junior people um and not all of them but for very junior individuals or like early in career let's say sometimes leaning a little bit closer to micromanagement hear me out sometimes leaning a little bit closer to micromanagement in terms of timelines is beneficial and I say this as someone who defaults to the opposite I very much default to the opposite where it's like hey like you know this is my expectation like we're saying, you know, it's not like we have a critical fix that needs to land or something last week. So, you know, let's let's plan for this to be it's a couple of weeks of work probably. Let's try to make progress through that or a week of work. You know, I'm talking with the individual or we're in the sync meeting and we get a feel for what that work looks like. But I'm not I'm not going to be chasing them down every day to be like, "Where is it? Tell me the status." Right? In fact, I almost have the opposite where people are like, "Hey, like here's the update for my work." Um, now I've I've had situations, especially with more junior individuals, where they're like, I actually don't know the expectation. Like, that's not clear enough for me. There aren't milestones. And so, I think that working more closely with those individuals, it doesn't have to be me. It could be a, you know, another team member who's partnering like sort of like a buddy to the more junior people. And I tell them like make sure you try to set some clearer milestones because that starts to set some structure. Now, some people get the hang of that very quickly and then they're like, "Cool, like I see how this works. Like if you, you know, feel comfortable, you can still give me some more guidance around like your expectations." But they're like, "I think I kind of get it." And they they get into the rhythm. Other individuals, it's still very challenging. And I that's when I go back to like people being disconnected. They're like if they're falling a little bit behind instead of saying like I should reach out and ask for help and try to make it known like hey I'm blocked on this. They they shy away from it. They go I don't want I don't want people to know because then it's like oh it's I'm you know I'm the weak link. I'm failing at this. and then as a result like if I keep hiding from it then then maybe I can get by and like you know I can fix this when really like we need to create that environment for people to feel comfortable and be like hey like no I'm behind like need a little bit of help here you know we're a team we have to work together on this stuff so um hopefully Carlos that answers most of your question the last part was for how long are under probation period uh I don't know what the actual standard is um I I to be honest I it hasn't come up where like that's been something that's been debated uh or or not but I actually don't even know at Microsoft now that I have teams that are across different geographies probation periods I actually wonder if that's different depending on the geo that they're hired in. So I don't know the answer to that. Um but yeah I I don't know. I think my my strategy in general is like I I said this to someone recently almost to a fault and this is me kind of admitting like I I have some weakness here. Almost to a fault I will try as hard as I can to invest time and energy into someone to help them. But the challenge is if they're not meeting me with the energy they're trying to uh to get on track. if they're like disconnected and I'm like, "Hey, like you know, I will put in more time and more effort into this. If they're not really meeting me there, then I after a little bit of time, I'm like, it's not it's not really worth it for me." And it sucks because like I don't I don't ever want people to not be successful. My entire career, like my role is to try and help make people successful. So, it's hard for me when that doesn't work, but that's why I try to put so much time and effort into it. how effective I am is a different story and I'm not here to tell you that I'm the best or the worst at that. Uh so Islam code sorry Carlos hope that helps. Um Islam code says as a software engineer do you think how think now after the AI and those new LMS do you think now the industry now these days becomes became useless? Uh I'm not sure I understand the question. And if you're asking if the software engineering industry has become useless, absolutely not. Uh I think it's just changed how we do things. Uh we're in an AI bubble without a doubt. Um I think AI is, you know, there's a lot of useful uh things we can do with it. I think that we can absolutely enhance what we're doing as software engineers, but I absolutely um I do not think that it's made like software engineering uh useless. if that if that was the question, let me know if if that was what you were after or not. But um I think it's evolving how we do work as software developers, but it's not uh not making us go away. Uh Clara Lopez says, "I hope I get clear guidelines around timelines so I know if I'm meeting expectations." Absolutely. Right. And so some people, right, and this is why I go back to situational leadership on this stuff. Some people are like, "Hey, look, like if you and I talk about roughly how long this should take, that's the conversation I need." like thank you. I'm off to go do my work and I will keep you posted if we're starting to deviate from that. Otherwise, I'll kind of give you the updates as I'm going. Just check in, make sure that, you know, you and the team understand what's up. And for some people, that works tremendously well. That works well for me because then I don't feel like I'm bothering people for updates and micromanaging them because I don't like that. I don't like to do it. I don't like when it's done to me because like if we're on the same page about expectations for that stuff like we must not be if you have to keep coming to me to be like what's the update tells me that you're missing some communication. So instead of you coming to me to be like give me the update where's it at? Where's it at? What do I got to do differently to get you the information you need in a comfortable way? How do I be more transparent about that information? Um, but some people, and it's not wrong or anything like that, some people very much want more clear milestones. I have uh a senior engineer I work with, and they are very much like uh one-on ones, but very clear about, hey, like this is what this week looks like because I'm progressing on things this way. Boom, boom, boom. Here's where I got to last week. Here's what I'm doing this week coming up. And here's how it fits into the bigger picture. So very much like a um an ongoing kind of approach to you know to to making sure timelines and expectations are met. But this all comes back to like one of the things I talk about a lot is just level setting expectations with people. That's on things like timelines. That could be other things as well. Uh sorry folks on Substack. I keep looking over and I can see like this I don't know if it's just my side but like the Substack feed just like disappears. I don't know why. Um, I have a feed across like five different uh screens here. And Substack's the only one doing that. So, I think it's a Substack problem. I stream to uh to reream and it blasted out everywhere. And if Substack's the only one doing that, I think it's Substack probably. Um, Carlos says, "Thanks for answering the previous question. Have you ever had a situation where someone is assigned to your team but doesn't align well uh with how the rest of the team works?" Sure. Yeah. Um, definitely. And I've had, you know, I've had to have conversations with people about how they work, their working style, and making sure that, um, like kind of coach them through that. I've had people that, you know, improve from that. I've had people that do not, right? And this is why like I again I'll say like the situational leadership style like if I don't if I treat everyone the same in terms of my my coaching style or like how I'm approaching problems with them. Um everyone is different doesn't mean that I treat people differently. It means that like how I coach and navigate problems with them needs to look different because they are unique. There are some common things that come up, but um yeah, like I need to make sure that if I have someone who's not uh sort of I want to say like fitting in with the team and I don't mean like they don't fit in because they're different or something. I mean that the way that they're working is not really being conducive. So to give you, you know, just some like sort of examples here, if the whole team is very collaborative and um, you know, they're making sure that everyone else like roughly knows what's going on. So when people are going on to code reviews and stuff, they're like, "Hey, cool." Like we've already talked about this, like things are kind of flowing. If you have someone that comes into that working environment and they're like, "I'm not talking to anyone until the code goes up." that's probably going to feel like there's a bit of friction and people might go, "Hey, like we we work this way. Like it would be great if you can kind of get on the same page." Like if you're not kind of um like conforming to how the team works, then there's going to be some challenges. And that might mean that maybe the team needs to be a little bit more flexible for that individual again situationally. Uh but that might also mean that like that individual like needs to kind of align with some of the team things. So, it's going to be situational, but the point is that like as an engineering manager, I have to work with those individuals to kind of coach them through that kind of stuff, understand where they're coming from, because I don't just want to be like, "Hey, man, like you're not fitting in. Like, screw you." It's more like, "Hey, like I I notice that there's some friction here. Like, tell me what's going on from your side." Sometimes they're like, "Oh, I didn't know that." Cool. Okay. Well, let's talk through it. Let's talk about why. Like, do you have any concerns with that? No. Okay, cool. Let's try it out. Uh other times, maybe something's coming up. Maybe um I have I've had people on the team where like they're, you know, they're going through some some significant burnout or some people that are having some issues uh whether that's at uh at home or with family or whatever, like something's going on in their life. And it's like, cool, like let me work with you on that. And then let me make sure that like if you're having any challenges kind of meeting expectations with the rest of the team, like let me take care of that. like let me work with you to make sure that we can progress things. Right? So hopefully Carlos that answers that question. Um Islam says uh Islam code uh I mean like companies like Microsoft they lay off so many employees because they don't need them anymore. Uh so this is like it's a it's just extremely it's extremely feedriven stuff in the media. Okay. So, um, what you will see, and I'm not I h I always have to put this disclaimer out there. I don't support layoffs. I don't like the idea of layoffs. So, what I'm about to say, if what you take away from that is like this guy likes laying people off and he's justifying it. I don't I don't like layoffs. I am not justifying them. I'm trying to explain what you are seeing versus like what is probably closer to reality. Okay. So, in I'm just going to Islam code I I want to first say thank you for asking this question. And the second part that I want to say is I'm going to take some of the words you're saying to dissect them. And I'm not doing this to I'm not doing this to try and attack your statement. I'm just trying to do it because I think it's a really good example of like how we see some of this stuff come up. Okay. So, thank you. And I I just want to be clear that I'm not um I'm not trying to make you feel bad for asking this question because I think it's a good question. So in in the statement, companies like Microsoft, they lay off so many employees because they don't need them anymore. So do they not need the employees? Like I I think the insinuation here back to the the statement earlier is because AI. So to me, I read this as I like Islam code is making the claim that Microsoft or perhaps other companies, they're laying people off because they don't need them because AI is doing their job. And I think that is wildly inaccurate. And I'm not again I'm not trying to attack you Islam code for this statement, but if that is the um if that is the crux of what what this claim is, I think that's inaccurate. Some some companies might be doing that kind of thing because they have it in their head like this is this is it. Like we figured out how to not hire more people. There's lots of companies that are rehiring lots of engineers because they're like, "Oh wait, that doesn't work very well." Um but probably what's happening is that this is more likely. Okay, you have companies like Microsoft and there are other companies that have done layoffs. We'll say the disclaimer again. I am not supporting the layoffs. What is probably happening is that they have um when I think about layoffs, there's probably two things going on or it's mostly one thing that it comes down to, which is why it ends up in a layoff. But it's like as business units in large companies, okay, business like companies exist because they are businesses. Businesses trade value for money. That's what a business is. And I'm not trying to be like condescending or patronizing with this, but that's what a business is. And so like I know a lot of us are like, "Oh, businesses, they give us jobs and stuff." Like business exists to trade value to customers for money. It's what it is. So what ends up happening in these situations, and I have not I'm not an executive at Microsoft or a big tech company that, you know, I have all the ins and outs of this. This is my understanding of it is that these business units when they are given guidance that's like hey we we have these targets that we want to achieve it it means that either you need to find ways to make money to help us reach those targets or what's the other factor that affects profit? You either make more revenue or you cut costs. So I think again not an executive but I think generally what happens is that someone's not sitting there going ah well you know what great news we've been sitting on this thing that if we just spend two more weeks on it we can crank out 20% more revenue that'll get us to target. Probably not. Maybe in some cases there's some stuff ready to launch or whatever and they're like hey that's going to be really great. But it's probably not. It's probably more like they're going, "Okay, well, if we need like let's look at our business and we have these parts of the business that we were investing into because we were hoping that over a longer time horizon, we could like it's kind of like a bet, right? If we invest into this, we're placing a bet that this should do well. We have data, you know, market analysis, whatever else it happens to be that suggests that this should be a winning strategy, but that time horizon's further out, there is a risk associated with it because it is further out. And then they'll go, okay, well, we're not going to do this part of the business. We're going to cut that. So, hear me out. Talking through that, I didn't say AI anywhere. Like it's not it's not oh like guess what we can just go use co-pilot to go do those people's jobs now like that's that's not happening in those conversations what you get to see on the outside though is big company lays off people not a good thing I don't like that big company lays off people big company's also working on AI things and then the rest of the entire media across the planet going, "Hey, if you're developing software, you better be terrified because AI can do your job, right?" And it's like, it's thrown at us nonstop. You open up, pick any social media site you want right now. Any social media site, go through the first 20 posts and you probably have seen something that's, you know, you're not going to have a job because you work in software development and you know AI is taking it from you. So you layer all those things on and then what you end up with is a narrative that is like well that's what's happening then, right? Like that's that's why Microsoft did that. they're replacing those people with AI. It's not what's happening. It's just it's just not. Now, what happens is that while there is downsizing in in companies, can't speak for every company, obviously I'm making generalizations, is that if if there is the inability to go hire people back in, by the way, I think what's really stupid, aside from layoffs in general, is like laying people off and then being like, "Hey, well, we still have job openings." It's like, why the hell didn't we just take the people that were getting laid off because their their part of the business doesn't exist anymore? Like, why don't we pull them back into the other roles? Like, doesn't that make the most sense? I don't know. That part drives me nuts. But I'm sure there's a very good explanation for it that is completely beyond um beyond my role or my pay. Like I I must imagine there's a good reason because it's not an accident that it happens that way. Anyway, can't remember the other thing I wanted to say. Oh, is that so then you have like parts of the business that are gone. It's not like, okay, well now what we're going to do is go hire lots of people because the whole thing was that we were reducing costs. I'm saying we collectively I'm not really part of this. I'm I'm a middle manager. I get told what happens. So now that we are reducing costs and that's why people were let go, what you're not going to go do is say great, let's go hire more people on top of that because that would just undo what you just did. So okay, well there's other teams like I've been at Microsoft. Guess how many people I've hired at Microsoft in five years? Zero. I've hired zero external people. I've done interviews for other teams. I've had internal transfers. It's not like I haven't had new people coming on or anything like that, but I have not and I've I've gotten interns as well. By the way, I should mention that. That's a really important part because everyone's like, "Oh, like no one's hiring juniors." I've literally had three three if not four uh interns to full-times at Microsoft in five years. I'm one person. And I realize it's not a big number, but for someone who's not hired anyone external aside from interns. So then what happens is that if we're not able to bring on more people to our teams to help with things, we are trying to find every way we can to become more effective. So yeah, we have lots of people that are like, "Yeah, maybe we can use like can we use co-pilot to help churn through some of the stuff in the backlog?" Like there's small bug fixes. like I'm trying to find ways that I can be more helpful that way. So, sure, but it's not like it's not no one got at least that I'm aware of, no one got fired and it was like or laid off and then it was like that's because we have AI lined up to go replace them. It just I think it's a a misconception that's completely um you know a fear-mongering from the media in general. That's my take on it. If you have data that says otherwise, like that's cool, too. But that's my interpretation of uh what's going on across big companies. So, Islam code, I hope that helps. But that's my take on it. And that's why like I'm not I'm not like afraid of this stuff. Like I I totally acknowledge working for any company that I could be I could be let go or whatever, right? Um I do everything in my power to make sure that I'm doing the best work I can. So, if I were to ever be let go, I'm not sitting there going, "Oh, it's because I was doing bad work or I wasn't keeping up." Nope. I work my work my butt off and I will keep learning things and I will keep working because I love to work. But if I get let go or something happens like I don't have the fear that it's it's because AI did it because from at least my experiences that's just not what's happening. Carlos, uh, what would you do if someone if some external contractors are assigned to your team and cause friction with your team? Uh, I would I would have a conversation with them first. Uh, I would have a conversation with, uh, depending on the situation because it's always situational, but, uh, could look like a conversation that I need to have with the contractors. It could be that I need to have a conversation with my team members to talk to those contractors. uh could be a very good coaching opportunity. Recorded a code commute video today when I was driving into work and I said in that video that one of one of the things that I think is like one of the best coaching opportunities for for software developers is getting people to talk to the individual that's causing them friction. And I say that because a lot of the time I think it's pretty a human thing to do. Like we avoid friction. We avoid difficult conversations. Right? Um like okay is it easier for you to go rant to your significant other or a friend that you're like, "Oh man, I work with this person. They totally suck." that makes you feel better in the moment. And it's significantly easier than you going to talk to that person and having that difficult conversation where you're like, "Hey, I've been finding it kind of hard to, you know, to work through these things and I wanted to talk to you about it because I really want to get on the same page as you, work effectively with you, and I wanted to understand your perspective on this kind of stuff better so that you and I can work and, you know, do an awesome job together. The second one is way harder to do. The second one is also going to be like significantly more impactful and beneficial. So I like coaching people that way. And then ultimately like if that's really what's causing friction and you know people aren't having the conversation, I might have to escalate to whoever is responsible for the contractor. Uh, in some setups it's like the contractors actually have like someone they're reporting to that's internal and I might have to talk with them be like, "Hey, this isn't working. Like here's why and like what's what's my strategy with you to figure out how we make this better?" Um, Carlos says, "Let's say the contractors do not meet your expectation, but upper management hires them because uh it's cheaper than uh hire a full-time employee." Yeah, I think visibility is the most important thing, right? Um let's see. I have not been in this situation so I can't just give you um like let me talk about a time when like this is this is a great interview question. Um tell me so Carlos would say tell me about a time when you were working at a place and upper management hired contractors and they weren't working out. Like how would you like how did you navigate that? Um yeah I think couple things right. So when you have individuals that are a little bit more removed in this example, upper management I'm saying is more removed from from the like the contractors that are being hired. What they see is a a business reason that it's like it from their perspective it is more optimal to bring in the lower cost of work. That's what I'm reading kind of from this. it's more beneficial uh more economically viable to do that and therefore like that's a good reason for us to do it. It's not like a terrible thing to assume like on paper that can make a lot of sense. What is difficult to measure is like if you have those people coming in and they are very difficult to work with then like if your overall effectiveness as a team is not greater right like you what you cannot do is measure contractor output and say well we pay contractor X they produced Y therefore like that's the return on this. Nah, it's going to be looking at the entire team's uh overall productiveness because if your overall team is now being hindered by someone coming on like that or groups of people coming on like that, if the overall productivity, however you decide to measure that, I'm not here to to start arguing that. But if that is net not improved, it very well could be a case to like how do you try to you know get data supporting this to be like hey look like I don't know how you folks operate so not for me to say maybe you have like I don't know like features that you're landing per release and you're like or you know how you're able to get through bugs or you have other metrics for your sprints and stuff and you're like here's what it used to look like and here now it's tanking you know we spend all this extra time doing you these difficult conversations with folks and there's friction like try to bring data because this is one of those examples where you might know what's bothering you and that's good but you need to think about your audience and if you're like I'm just sorry I'm going to Carlos I'm going to I'm going to butcher this a little bit but if you were to like go to your your your leadership or management and be like I don't like them I don't like working with um it sucks. They're going to be like, I don't care. Like, that's not what I care about. Like, sorry to hear that, Carlos. Maybe maybe you should do better. Right. Like, you know what I mean? Like, that's not the the angle that that's really going to change things for them because especially if they're far removed, they're kind of looking at it like, okay, well, I don't know, is Carlos the problem? Like, you know, they're they want to make sure that they can have a productivity increase here. So being able to give them data and focus on the parts that are going to be what they care about as stakeholders in that kind of conversation is going to make a difference. Right? So how was overall team productivity affected? Try to bring in some examples like this. And I think that that's how I would approach it to to try and and sort of surface that information to them so that they can understand it in a way that they otherwise are not getting. Um this is the kind of stuff I spent not specifically with um you know with uh outsource work kind of thing or contractors but this is the kind of thing that I've spent a lot of my career in before Microsoft where it was like you know I was in at the beginning of a startup that grew to a couple hundred people and one of the things that I sort of feel like was my strong suit was that I could be you know on the ground floor talking with people, understanding things and then making sure that I could find a way to communicate that up to like up to the CTO and CEO, right? Like let me get you data points in a way that you can understand that's valuable. So up to the VP, CTO, CEO, and making sure that like they have information they can make executive decisions on. So Carlos, I hope that helps answer your question. I'm realizing folks that we got it to 8:00. I didn't get through my my topic, which is totally fine because I would much rather do uh AMA style questions. But um to kind of go back to the article before I sign off here, um I think like maybe the only thing maybe the only thing I didn't really touch on that I that I wanted to is like um I think trying to evaluate like one of the things I really like is understanding how someone approaches learning. And I I'd love to hear about examples where like you were put into a situation like you didn't know a lot and like cool like that's an awkward situation to be in but like how did you overcome that? Like what did you learn? Like how did you approach doing that? How are you res talking to talking to people through scenarios like this so I can get a better understanding of how they're approaching this kind of stuff because you know technical skills and things like that are things they can pick up on over time. I actually think the stream just dropped there for real. I hope it came back. But um technical skills people can learn over time, right? Especially if they're more junior, they got lots of opportunity to do it. But um like if you're not willing to learn and you're not sort of excited about doing it um and you're not extracting lessons from when you've gone through things, like those are the things that I really care about personally. Um, so to kind of finish all of this off, um, I didn't write it in the article, but in the code commute video, let me just go back to here. In this code commute video, I linked, uh, I was reflecting on two interviews that I had when I came to Microsoft. I had um my first skip level manager gave me one of the interviews that I I really liked and I had another engineering manager who um unfortunately I haven't like worked a ton with him since I've been at Microsoft but um you know we've kept in touch and stuff but uh he he gave me I think probably my favorite interview that I've ever had and so for that individual um I was explaining this to my wife because I wrote this article and um did the But I was telling her like I'd never met this person before, right? I'm going into this interview and I immediately felt like we were friends. So, he's very welcoming, made me feel very comfortable. And then he was getting me to talk about my experiences in a way that he was getting the information that he needed to hear, but not asking me questions in a way that was like kind of forcing me to answer like something that felt contrived, right? Because when we get into these behavioral questions, sometimes they're asked in a way and you're like, if you're paying attention to behavioral questions, you're like, I think I know what you're trying to get me to talk about, but like I don't have that exact example. And then it's kind of weird. So he talked to me about my experiences and I just felt like I told my wife it felt like I never had to go study and like rehearse to be able to talk that way to him because it was like I could just tell him stories about my work and he would ask more specific questions. And I I love that interview like that that is something that when I did that interview with him, it reminded me like, hey, you know, remember how you felt during that interview and going forward try to make sure that you can try and model that for other people. So that was like a really um important interview in terms of like framing my perspective. And the other one was my skip level manager. I kind of mentioned that briefly and he asked me and the other one was my and he asked question typically if you haven't done these kinds of kinds of interviews before typically you get some type of like I was kind of joking about this earlier in the stream but like hey go like tell me how you would build Instagram or YouTube or uh Uber or like whatever right like a pop like build Netflix you get like popular type of system and it's like if you have studied it you'll know that there's like some interesting constraints you need to work through and this is a pretty typical thing that comes up and so when I was coming from a digital forensics company I was very transparent like hey I have not I I was uh interviewing for the office 365 deployment team and I said I have never done things at this scale before I've done a ton of desktop development. I've not deployed things to the cloud. I haven't done that. And so when this uh my skip level manager at the time was he was not yet my skip level manager. He would be um when he was asking me my architectural question I said to him I said normally when people ask these they want to hear about a you know complex distributed system but I don't I don't have one of those. I've built a lot of desktop software. um you know for a suite of products like am I okay to talk about one of those examples and he said absolutely like tell me about something that you were building and you were responsible for making architectural decisions and just walk me through what those look like so I said okay and then started describing something that's not a big complex distributed system but I was talking about like layered architecture that we had for a desktop application I was talking about how historic torically we had challenges like you know being able to get data displaying uh like fluidly in the user interface and uh our database choice was actually very interesting because it was SQLite and like hey like why wouldn't we go use some powerhouse database like but there's reasons for that so I could walk him through why I was making these types of tradeoffs and I suppose it went well because I ended up getting hired but again that was an interview that it felt felt very natural for me because I got to just talk about my experience and let him kind of dive deeper into different parts as uh as he needed to. So those two interviews for Microsoft were I think two of my favorite interviews that I've been on um on the interviewe side. So I just wanted to share those because they came up in the code commute video and they were um something I was keeping in mind when I put this together. So that's going to be it folks. Uh, I'll do a couple quick shares. Um, so Devleer weekly is my newsletter. It's at, if you see in my URL, uh, my title bar here, uh, weekly.devleer.ca. It's completely free. You don't have to subscribe to if you don't want, but if you like the live stream, uh, for next Monday, check out the newsletter issue that goes out on Saturday. You can see the topic at least. Um, I have a bunch of YouTube channels. I think I have five YouTube channels now. Um, but this is the one. So, Dev Leader podcast is where I do the live streams to and I have all of these software engineering interviews I've done. The most recent one I posted was with Derek Martin of Code Opinion. And, uh, if you're not a net developer, you might not know Derek, but Derek has a an awesome YouTube channel. He is uh very very good at being able to like take bias out of things like architectural decisions. So you might have a favorite pattern or practice and he's like cool but like in this context here's what makes sense and here's why. And if you change a little bit of the context that might mean some other approach makes a lot more sense. But he's so good at doing like a pros and cons analysis based on the context. And I highly recommend that folks check out Code Opinion if you're not already familiar with them. Um, got lots of other guests on here and uh looking for more guests as well. So if you or someone else would like to be interviewed, you can check out what the podcast looks like. So go to Dev Leader Podcast. It's also on Spotify and you can see how these interviews flow. Feel free to recommend someone if you're interested. Uh I have my main channel, Dev Leader. I so I moved over my my other videos from this channel to the others. This one is just going to be programming tutorials and AI videos. Uh AI specifically around how to leverage AI when you're writing code and how to build C applications that use AI as well. So um this is sort of my bread and butter on YouTube. That's where most people kind of find me from. And uh so if you want to learn C or you're building C applications like definitely check out Dev Leader. Uh all the videos are edited uh it's not like me blabbing away at a camera like this. Uh so check that out. Path to tech. So Dev Leader Path to Tech this channel if it ever loads is uh ré reviews and I will probably introduce some other content related to interviewing and other stuff but uh primarily this is uh ré reviews. So, if you want your resume reviewed, head over to Dev Leader Path to Tech. Watch a video. It will explain how you can submit your resume to be reviewed for free. Finally, Code Commute. This is the one I was talking about a whole bunch today. So, Code Commute is my vlog Q&A channel. So, most of the time I'm, you know, doing this on my way to or from work or CrossFit, and I answer questions that you submit. So, um, you can check out Code Commute on YouTube. It is on Spotify. Oh, I should have preloaded all these pages. Sorry. So, there's code commute on Spotify. And then on codemute.com, if you want to submit questions anonymously, just check the box, write your question, and it will email me. And finally, I'm not going to talk about Brand Ghost today. I'll wrap up. I just wanted to show you guys there's courses on dome train. So, let me copy paste this in the chat. She got it. But if you want to learn how to program in C, I have uh getting started in deep dive courses. Those are 11 and a half hours together. And then if you're not a C developer, you don't want to be, totally cool. I have some other courses that I paired up with Ryan Murphy on who's a software engineering manager at Yelp. And uh we have career management, getting promoted, behavioral interviews, and soft skills as well. So hopefully there's something for folks that uh see some value in that. If you want to get an idea around how I teach, I would say um if you check out my like my main channel, Dev Leader, um I kind of carry over that similar style into my um my courses. So, uh you'll notice I repeat things. I try to explain things in different ways. And so, if you find the way that I explain topics beneficial, then that's what you get in the courses. If you're like, I can't stand listening to this guy, the courses might not be for you. But I'm just trying to be transparent. So, thanks so much, folks. Um, I hope that that was an interesting chat for you guys. If uh if you like that, then I hope to see you next week, same time. So, that's 700 PM Pacific. And uh yeah, if uh if you can't wait that long because you're so excited, check out code commute because it's a very similar style. There's just no live chat because trying to uh use the chat and driving would be pretty negligent. So, we're not going to be doing that. But thanks folks. I will see you next week. Take care.