LeetCode Sucks - Don't Let Your Critical Thinking Suck Too

Transcript is auto-generated and may contain errors.

Hey folks, I'm just driving to the office. Uh we're going to go to my brain for this topic today. Um there's a car coming. We're going to talk about my favorite thing, which is lead code. Um if you're new here, that's sarcasm. I absolutely hate lead code. I think it's uh one of the most useless things that we have in software engineering. But what I want to focus on is not just like lead code. Um, by the way, if you enjoy doing lead code, that's totally fine. I just don't think that it's relevant for interviewing. So, that's the focus. I'm going to talk about that. Um, and I want to kind of talk about like information that's shared online or I guess when I use the word information, I want to call it opinion that's shared online. And uh, you know, I will start by saying like you're watching a video where I'm talking, right?

Everything that I'm saying is just my opinion and uh I never want you or anyone listening to this to to take the things I'm saying as like you know 100% fact or like this is the only way or whatever. It's it's just my opinion that's all. And so I do encourage all of you, you know, if I'm sharing things that seem like they are data points, unless they're like literally things that, you know, I have lived through, uh, like go like validate them, right? Like double check them. Get form your own opinion on them. I I share perspective. I share my opinion and I encourage you to form your own, right? Like the goal with my content is not to to like tell you this is the only way. The goal of my content is to to give you more perspective to form your own opinions on things.

That's all. And so the reason I'm talking about this uh lead code thing is because uh as a content creator, I see lots of other content creators sharing things. And there was recently uh a discussion on LinkedIn where there was a I I don't know if there's still an engineering manager, former engineering manager, something. And they make content for engineering managers. just I think primarily but also software engineers and one of the things that they were I don't know like in their post I couldn't really tell like if they had an opinion I think they were kind of like making it an open question about um coding interviews for engineering managers and I think I can't remember in the in the original post if it was specifically about lead code or not But whatever. Um, I think they kind of like were inviting people to express their thoughts on it.

Like they I don't think they explicitly said here is my exact opinion on it. So, it was kind of open. And um, basically there was two major themes that I saw in the comments. It wasn't like a super popular post or anything, but like um, two two major themes I saw. It was either people being like that's useless to do like a lead code style interview for engineering managers. Um or it was people saying like hey that's like those are the questions that come up so like you have to prepare for them. um not saying uh like in those in those comments people weren't saying like those are the questions that come up and I think that they're appropriate. It was just like that's what we're stuck with. So again, I don't know if I saw a single person in an engineering manager role saying that they thought lead code questions for engineering managers made sense.

Um, and to be fully transparent, I don't think lead code questions make sense for anyone uh in an engineering manager or software engineering interview. And I've talked about this plenty before, but we're going to keep talking about it today. So, I thought that was kind of interesting, right? like basically anyone commenting seems to be of the perspective where they're um either against it or they're basically just like I accept that it has to happen because that's what people get asked. And I don't think that I saw anyone, maybe it was kind of buried in the opinions of people that said, "I guess we have to," but I didn't see anyone explicitly saying, "I think it's a good idea," except the author. So, the author was going through the comments and commenting back and kind of challenging people's perspective on this. And I think there's nothing wrong with doing that.

I actually think that that's a good way to have a conversation. And um I think that he was being respectful. So as I'm talking through this, I just trying to be transparent about this, right? Like he is taking the perspective that he thinks lead code questions for engineering managers are good. I think that's complete but I also don't think that he was approaching it in a way that was rude or anything like that. So again, I'm not like attacking him. I think he was, you know, uh, doing a good job like kind of like expressing his opinion and and navigating things. Um, the the thing though is like I am saying expressing his opinion. One of the one of the arguments, so I obviously chimed in on this on this comment thread because there's no way that that I'm gonna let a post like this go past me because I'm so against lead code.

But um I said, you know, in my comment something along the lines of, you know, not only do I think that lead code is not a good like interview type for engineering managers. I don't think it's good for software engineers. said, um, I said, "It's not it's just like not a real representation of what we're doing in our roles." And like, especially as engineering managers, like that's like to me it's just over the top ridiculous uh to consider it. Like there's I haven't I haven't done anything remotely close to lead code in like 13 years of managing teams. aside from like like talking about lead code and how much I don't like it but um or interviewing right like that's come up in when I interview but otherwise no so kind of expressed this and I think the the first response that this gentleman had

was along the lines of like um like almost like why do you think that their coding questions are or like why do you think that having oh questions that are representative of work are good for the interview and I can't remember the exact words but something like this and I was kind of like taken back by it cuz I'm like I can't tell if trolling or what like um because the question to me essentially read like why do you think that asking questions that are relevant to the work that someone will be doing are a good gauge for interview questions. And I said like I would much rather be like walking someone through things that are close to what we're doing so I can see how their previous experience lines up with things and how they essentially like approach navigating problems or type of work that they're about to be doing on the job.

And from my perspective, like this is how I've done things and this is what I feel like works well. And so the the rebuttal to this was essentially like two like two points that I think he tried to express was like one um he disagrees because interviews are short and the things that you're assessing people on for the job like for performance interviews take months to to actually assess. So like you can't adequately do that in an interview which like I yes that that makes sense. It's also I don't think what I what I was saying exactly but that makes sense. And then the other thing that he made a claim about was that um it's all about reducing false positives as in like hiring people that aren't actually good. and he said like big tech companies have the money to do research that actually like would validate that.

So essentially saying like all these big tech companies do lead code style interviews and because they make so much money they're the best informed to know that it leads to the fewest false positives and like again I can see the rationale behind that but um this is where I want to talk to all of you about this kind of thing. Um, this is just like at this point in the conversation in the here and like in the thread that I've seen, all that this is right now is some guy's opinion. It's two guys opinions actually, right? It's the original poster and it's mine against each other. And neither of us actually have data that's being shown. And I wanted to talk about this because I think it's too easy for people debating online um especially like you know in software engineering and when we have

more junior people that are reading this stuff and like they haven't yet had experience to form opinions about these things or like to try and get super analytical about them which is fine. I'm not I'm not discounting their ability to think. I'm just saying they haven't built up the experience yet. They might see conversations like this or other conversations and go, "Well, therefore, like, you know, one of these people must be right or therefore this one person must be right or whatever because of titles or how they say things or whatever, right?" And I want to talk through this because I I want other people to be able to read things online and and this this applies to like even like things at work, right? Like form an opinion about things like like get data and do the analysis yourself. Form your own opinion. Don't just blindly take what people are saying, including the that I say.

So, if you're like, "Hey, Nick, I've watched a few of your videos and I like the things that you're saying." Like, thank you so much. I appreciate that. That's super cool. But also, like form your own opinion. If that happens to be that's something that's aligned with mine, cool. That's that's really neat to hear. If it's not, that's cool, too. I like, you know what I mean? I I want my goal, like I said at the beginning of this video, is for you to come up with your own opinions on things. use your own mental model, your own framework for things like how you how you're going to approach problem solving or whatever. So, in this comment thread really, I'm like I'm open to like if if he's like, "Hey, look, here's a bunch of data published by big tech companies that say lead codes

like questions statistically lead us to having fewer false positives and lead when he says false positives, I'm assuming the definition of this is like good quality candidates for the role. I'm assuming that's what it means. But like I have yet to see the study. Z I've been at in Microsoft for 5 years. No one's ever approached me about the interviews I've done and the data that goes into that. Um obviously I'm only one person so not a good argument to say like no one's asked me therefore it doesn't happen. But like I don't know. I've not heard of anyone talking about this ever before. So, you know, when someone's kind of making a point like, hey, this happens in big tech and they got money to do the research, I'm like, that's cool. Like, my experience says that's not actively happening, at least in the experience that I've had.

But hey, if you got data that shows it, I would love to see it because I'm very skeptical of it because I think it's complete And again, I say that because I don't understand how testing someone on things that have nothing to do with their work equates to a lower rate of false positives for the work they're doing. It seems, like I said, it seems like to me. However, I would, if I saw data that said otherwise, I would love to see that. I would also love to see how the study was conducted because I would also be highly um skeptical of a study that did suggest that around how they do it. So for example, if they're conducting such a study, they must have, you know, a control group that's not getting asked lead code questions, right? And how are they doing that? Is it on the same teams that they're hiring for?

like I don't under I just I don't know what this study would even look like. Um but hey, if they got data, I would love to see it. But that's the thing, right? Like when someone's telling me something like this online, I want, you know, my goal is not like, oh, I don't like this person. I think this person actually posts, you know, valuable thoughts. I think the conversation itself is a good one to have this conversation around like coding interviews for engineering managers. Um I don't think that a coding interview for an engineering manager is terrible. I think it it's based on the expectations that you have for that role. So for example, when I interviewed at Amazon 5 years ago, I don't know if it's changed, Amazon did not ask me any coding interview questions. Okay. So, I didn't have to prove to them I could code.

Uh Microsoft did, Google did. Uh my Meta interview was canceled, but Meta would have. And so I would ask the question like what it when you are interviewing an engineering manager to test if they can do a lead code question, what is it that you are trying to assess? you're like the goal of the coding interview is to assess someone's ability to code. Do I need to do that in my role? If I do, then absolutely like give me a coding interview question is my belief. I don't think that elite code style question is remotely close to useful for that. But I could get behind the idea of a coding round. Right? If you're expecting that I need to code, then do that. the same reason like you expect me to be able to, you know, um, manage projects, so I need project retrospective type interview questions.

You need me to be able to help resolve conflicts, so like talk to me about behavioral stuff. You need me to be able to grow teams. You need me to be able to manage people out that are underperforming or coach them through that, right? To be able to help them improve. working with um engineers that are doing really well in their career and making sure they have proper guidance. Like I get asked those types of interview questions. Why? Because that's the kind of that I'm going to be doing in my role. So again, I I would love to see data that suggests otherwise. I just don't really believe it and so I remain skeptical about it. And that's the thing, right? Like in this case, this is something that's polarizing for me. So, I'm going to be highly skeptical, but I think that it's good to have a little bit of skepticism for lots of things.

And it doesn't, again, this example might be a poor one to get this point across because you can probably tell that it's a little triggering for me. But I think that it's valuable for you to not just take things at face value. Doesn't mean to be confrontational with people. Does it mean that anytime someone says, "Here's some data," you're like, "No way, Like, prove it to me or I'm going to do my own research and like I'll show you otherwise." Like, that's not what I'm saying. But I think what I'm trying to get across is like you need to be able to form your own opinions about these things. And so, if someone is presenting data, you know, do you understand where that data comes from? Do you also agree that it's like sound in terms of how it was collected? Would it like have you formed your own opinion about what that data is saying?

Is there data that's not present that would be more valuable uh in addition to what's provided for you to form a proper opinion? Right? This is what I'm trying to get across. Not not exactly just like I hate lead code, but this is what I'm trying to get across. Right. So, I like I guess for homework because if you're watching my videos, you're getting homework. Um, but I like I encourage you either, you know, at work the next time someone's presenting some data to you, whether that's in like a uh, you know, report of some kind in a design document, like here's the data that backs us up. Um, you know, think about that, right? I want you to kind of look at that data and be like, do I understand where this comes from? Does this make sense? Like based on the discussion that's being had, is this data comprehensive to get this like to get this across?

If it's not, like that doesn't mean that it's bad or wrong. Maybe there's something complicated about that and that person can go, hey, look, like this is supposed to be a starting point if we wanted the most, you know, accurate data that's actually going to take us like weeks to collect that. So this is like um I don't know like um as good as we can get we think and there's some inference here or we've extrapolated a little bit like that might be something that's happening. And I'm not here to say that's wrong, but are you aware of that? because if you're not, you might be making like, you know, you're not really forming your own opinion on this. You're just kind of assuming things. So, I think that it's good to make sure that you're understanding these things. And if you're not understanding them, then you can ask the right questions.

You can kind of challenge these things to say, well, what about or could you explain, right? And and kind of form your own opinion. So, that's some homework if you uh are not in that position where you know um you can do that because maybe you're not working on a team or that's not something that comes up. You know, I I would encourage you the next time you're reading some stuff online where people are making claims about something, go like go do some research on it, especially if it's polarizing for you, right? In this case, like I should take my own advice. I have not yet gone to go do research to see if big tech has done research that proves leak code questions are good. I do know an individual I want to reach out to that does a lot of this kind of stuff quite regularly and I might ask him and say hey like have you have you pulled data on this before.

This is the kind of stuff that he is really into. So, even if he hasn't, he might be a good resource for me to ask to see like um you know, where would you go to to find this kind of thing? So, like that, like I'm saying, that's homework that I should probably do. But I encourage you all to do this kind of thing. Um the goal is not to be confrontational. The goal is to make sure that you are forming your own opinions, understanding where data is coming from, and not just blindly assuming things. So, I hope that helps. Um, yeah. I don't know if I have anything else on that. Just ranting about lead code more. So, that's not really the goal. It's kind of my hook for the video is to to get people in here with lead code, but I wanted to talk about forming opinions.

So, I think that's it for this one, folks. Thank you so much for being here. Um, if you have questions, leave them below in the comments. And if you want uh to submit something anonymously, just go to codemute.com. You can submit uh questions or topics that way uh fully anonymously if you check the box. And then I have other YouTube channels if you're interested. So, Devleer is where all of my car and AI programming tutorials are. Devleer Path to Tech has resume reviews. And the Dev Leader podcast is where I interview other software engineers about their career journeys, things that they're into, passionate about as software developers. And then I do a live stream on that channel every Monday at 7:00 p.m. Pacific, except this Monday coming up. If you're watching this, it's already too late. It's behind us. Um, but that's because my sister is visiting from Canada and she has not been to Seattle yet.

So, I will be missing the live stream, but we'll be back soon. So, thanks so much for watching and I'll see you in the next video. Take care.