Computer Science Fundamentals?! Who Needs Them!!

Transcript is auto-generated and may contain errors.

Hey folks, I'm headed to CrossFit. Um, going to Reddit for the topic today. This one I think is kind of interesting. Um, I think I'm a little sick too, so I apologize. I don't want to keep clearing my throat, but we'll see if I can survive. Um, this topic is experienced devs, how well do you remember the computer science fundamentals? And um I believe this person's going on they're talking about like interviews and stuff like that. Um or they're saying like they I think the context they said is like if you were to interview today, you know, how well would you be able to kind of uh draw upon that knowledge? So I think that'd be kind of cool to talk through. Because I'm going to CrossFit, this is a a little bit shorter of a video than normal because CrossFit's a lot closer to home than work is.

Uh, but if you want questions answered, leave them below in the comments. Happy to try and answer. Otherwise, you can look for Dev Leader on social media and uh that's also my main YouTube channel. But if you send me a message on social media, I will keep you anonymous so you can write more details, do whatever you want. But yeah, software engineering career stuff. happy to try my best. Um, okay. So, I think that this is an interesting question because it's almost like the way that it's asked implies how we leverage that knowledge. And I'll be, you know, the super short answer is like I would do a very poor job at just like uh recovering uh computer science fundamentals. Uh, so like in an interview context, if someone was just like, you know, lightning round, like tell me this, tell me that, I'd probably do very bad.

Um, for those of you that don't know, like I've been in the industry for just under 15 years now. 13 years of which almost 13 years of which is a software engineering manager currently at Microsoft. Uh, role I had before for eight years was IC and manager at the same time. So, I I've been writing code for a while. Um, and managing teams for even longer. Uh, no, other way around, but professionally that way. Um, so it's it's weird because it's not that those are things that I do not know or could not figure out, but uh to be able to recall them on the spot probably wouldn't do well. And a similar thing too like I know we're talking about like sorry in their example you don't have it pulled up in front of you. I don't currently at this moment either, but they were talking about some things like actual like hardware concepts.

Um, and then I guess you could layer into like I would layer into that things like uh basic things from data structures and algorithms even like these are things that that you learn as concepts and build on top of and that's why they are fundamentals. So, the reality is just in terms of like very fast recall on these, I would do a poor job. Um, but like I'm hinting at, there's a it's almost like we're we're being guided as to like how we leverage that information as part of the question, right? And I don't personally think that the effective way to use that kind of stuff is to have it recalled like it's been memorized. Okay. Um, and this might be different for different people. Um, so maybe maybe you do well with memorization stuff, but the reason I don't do well personally with memorization stuff is like it's one thing for me to recite things back to you.

So like could I spend time memorizing concepts? Yes. Um, and then what can I do with those concepts is sort of the next question. And um when I was thinking about answering this cuz I took a couple seconds before I walked out the front door this morning like what do you make sure you have something you want to talk about here. Um I wanted to to kind of talk through the sort of parallel I see with like uh at least my university experience and this maybe applies to college or for other people arguably even in boot camps depending on how things are structured. Um, for me, a lot of a lot of how I was like graded in university would have been on exams, right? Like I had I literally had math exams that would be 95% of my final grade in a course. Um, so like the like all of your work comes down to doing well on an exam, right?

And that means that it all culminates to like a a 2 and 1/2 or 3 hour period where you got a a pencil, a calculator, and it's like, okay, time to shine, right? And uh inevitably I found that I needed like in order for me to do well on exams in university I needed to memorize things which is like again it feels kind of counterintuitive. Uh in my opinion it feels counterintuitive. The I feel like the goal of college and university is not supposed to be to memorize things. It's to like have these experiences and like these fundamental things that like that you that you learn. And I would say like it probably did some of that, but I find that how exams and stuff test you is very much um like a memorization thing.

And in fact, just to draw a quick parallel back to what we're kind of talking about with this main topic is uh like I find that depending on how someone's interviewing you, that could very much be the same too. Like if you have an interviewer that's just looking for you to be able to say like, "Do you know X? Do you know Y?" And it's just like reciting things to check a box. Like it's not not super helpful. But again, my my university experience was that um it would be essentially especially like leading right up to the exam, get as many concepts in front of my face and try like going through and memorizing. Now the obvious and maybe it's not obvious but for me the obvious sort of drawback to that is if you've memorized things then when you have something that's presented to

you in a way that looks slightly different all of a sudden that slightly different looks very different and it's because the thing that you've memorized like doesn't match the exact pattern. and it might look similar and you're going but wait a second it's not like it's not the same like this part this part here is different so then you're the way I found it was like I want to go apply this thing that I've memorized but like because it's different I don't know what to do now and if we contrast that with like actually taking time to understand concepts I think that's very different because when you like genuinely understand something and then you get a variation of the thing, it's not, oh no, I didn't memorize this variation. It's well, I know that this looks similar to this other thing and I understand how that thing works.

So I can kind of extrapolate how it functions or interpolate depending on the direction and um and kind of see like hey I can apply this fundamental knowledge to this scenario and um then it becomes more like active problem solving and thinking through something versus just did I memorize it and again to draw the parallel back to interviewing um this is the same thing that I've experienced. It's the the reason that like things like lead code questions I think feel really crappy uh or unfair because sometimes people can just memorize enough lead code or patterns that when they get a question in an interview it's like hey it's I've seen this right like let's just here's the answer. Um but they don't they might not truly understand it. I'm not saying that there are are people that do lead code well and like don't understand things.

It's not not my uh not my point here. I'm saying that it is very possible to not actually really understand what's going on uh or how to program effectively or how to build software effectively and answer lead code questions effectively. Um because I think that you can get away with a lot more memorization in lead code. like I don't think that it becomes a good gauge of a software developer um because it can be gamed by by things like memorization. Um so one of the tricky things is like if we take something like lead code just to kind of shine you know light on a different perspective here is if we understand fundamentals and someone presents lead code type questions what's nice is that if you have the fundamentals you can look at something and try like you can try navigating it right you can

say like okay I I have this this pattern or this this problem set laid out in front of me and like if we decompose it into smaller pieces start looking at some of the patterns we see then we can start applying like things that seem more fundamental right so like if you need to go over data but you're finding that you have to keep looping over it are there ways that you can um that you can shortcut the lookup right so can we trade runtime for memory or the other way around um obviously ly there's a million different flavors of this to go consider, but but this would be something where it's like I feel like that would be a fundamental thing that if you understood the concept, you could go navigate that.

The reason just to go back on why I don't like lead code again, um the reason that that's not the full picture though is because I find a lot of the time lead code questions can have like a trick to them. And I have experienced too many times even as an interviewer talking with other like interview panelists like that um that people are often looking for the the candidate to get the trick. And I think that that's absolute because if you're trying to like interview people on how good that they can find tricks to problems then I'm like okay like I don't know what the point is here. Um it just feels kind of off to me. Uh when I say kind of I mean vary. But uh yeah it's uh you know if you have some of the fundamentals understood then you can go navigate.

So to go back to this person's question, right? I feel like the answer that I would give them is no. I don't off the top of my head, like if you put me right into an interview, like I would not be able to like recite fundamental things back. But because some of that stuff is actually just ingrained in my brain, not the specifics, but some of the concepts that are fundamental that just happen to get applied uh pretty regularly at different levels. Um I find that I would be able to try and navigate things. So it would feel like on the outside looking into me solving a problem it might look slower for example compared to someone who's memorized some of those things right because they could just recite the answer whereas for me I'm going to be like I don't have the answer off

the top of my head but if you're willing to like let me reason through it I should be able to arrive at something that is I don't know hopefully on the right track and um I just think that that that approach is more flexible, right? Like that's you being able to adapt to different situations and and navigate different types of problems versus just saying I can go tackle the situations that I've memorized for one of them feels extensible compared to the other. It's also why I personally interview that way. So I don't ask questions like if people have things memorized I just move on to the next like variation of the question where we build on these things right so it's not I can ask you something that's like related to data structures and algorithms but I don't care in step one if you've just regurgitated something you've memorized like okay we just move on to the next part where uh I will change requirements around uh not to not to trick you.

It's not like, "Oh, surprise. I got you." But it's more like, "Hey, if this was a different constraint that we had to work with, how does that change, right?" Because to me, that will help people explain and navigate concepts or fundamentals versus just, oh, I memorized what a a linked list look like looks like. Understanding why there's different characteristics in that data structure versus something else. Okay. Um, sorry. Because I'm sick, I'm like trying to catch my breath at the same time. It's like talking is hard. Um, what's the last thing I wanted to say on that? Was thinking back to the post. Come on, Nick. Get the brain going again. Yeah, I was well I wanted to say something about the interview part specifically. Um but I I can't really recall. So I would say maybe if I just start talking again it'll come back.

But yeah, to maybe to kind of summarize some of those thoughts um oh this is what it was. part of um what they said in their post was like, "I'm not really doing low-level stuff anymore or regularly, so it feels like those types of like fundamental concepts don't seem to apply." And um I would say for a while, like that's mostly like how I I kind of saw things. Like I would agree with that if I'm not doing like super lowle stuff and having to to think about some of that stuff regularly because when it's when it's abstracted away it can feel like you don't have to to really worry about it right the cognitive load is lower um at least on those pieces right um it's not like hm like I have to go write this algorithm like what data structure and blah blah blah it's just like there's a library that does Okay.

Right. Like let me let me solve problems at different levels and that um what I wanted to say that I thought was kind of interesting and I actually was talking to someone about this the other day this week. They were asking me about hey like at Microsoft are you do you use like data structures and algorithms like regularly? And I was like for me personally absolutely not. I'm an engineering manager. So, um that's like not part of my day-to-day. But, um what I thought was a neat thing to reference was like it's completely on the opposite end of the the scale here from like, hey, I don't look at low-level stuff. Um when you have stuff that's like ridiculously massive scale, right? So, for folks that don't know, I like I said, I work at Microsoft, but um I work on the routing plane for uh Office 365, and we have to route trillions of requests per day.

That's what the T trillions. Um, and because of the scale of our system, it's kind of uh interesting that instead of saying like, oh, I don't look at low-level stuff, we actually have this effect where because the scale is so big, these these sort of uh scenarios or challenges that you would only think about with low-level stuff, they start to resurface when you have massive scale. Right? So, if you're building, I don't know, like a a even like a midsize website with decent traffic and stuff, you might not have to think about like, hm, like how am I storing this data in this data structure because it's like, like I said, like there's libraries that you can just lean into and not really have to pay much attention. not saying no attention, but like they do the majority of the heavy lifting. You're you're kind of thinking more of like a system level.

Um, and then we have stuff at our scale where it's like we end up having to go it's it almost feels like reinventing the wheel for some things because you need like in some of that context like ridiculous efficiency because when you scale it out it makes a really big difference. So like how we pack data into certain data structures and stuff when you're dealing with systems that have trillions of requests per day like that can translate into into money saved because you are multiplying it by by large numbers right um or like if you think about how many IP addresses have to flow like flow through our system if we needed to do anything uh related to IP addresses like just the the sheer volume of stuff we have to deal with is uh is reason why some of these like fundamental things like and even data structures and algorithms will start to pop up more at this scale.

So I thought that was kind of an interesting um take on stuff like that. So maybe that's why you'll see more data structures and algorithms pop up for companies that have really large scale stuff aside from just trying to be a pain in the ass in an interview. Okay, let's get in this parking spot. Cool. Okay, well, I'm at CrossFit. I'm going to go deadlift and do handstand push-ups and hopefully wake up. So, I'll see you next time. Thanks for being here. Take care.