Interviews, Competitive Programming & Vibe Coding (w Ex-Google Competitive Programmer)
NNeetCodeIO@NeetCodeIO · 352K subscribers
- Views
- 31.1K
- 31,094
- Outlier
- ×3.4
- Median 9.2K
- Length
- 1:01:39
- Published
- Jan 5
- Monday
- Comments
- 56
- 925 likes
Script
How it's written
- Words
- 12,742
- Words a minute
- 207
- Reading time
- 54 min
- Segments
- 42
The hook
0:00–0:26Today we're doing something a little bit different. Today I'm joined by a competitive programmer, Chi-Chi. Before we get into it, uh I think most people watching this probably see me as somebody who's like pretty decent at coding interview questions. And I would say that when it comes to coding interviews, I think I'm pretty decent. I could probably pass most of them. But when it comes to competitive programming and especially at Chi-Chi's level, I just want to stress that there's like a really big order of magnitude difference
Structure
Today we're doing something a little bit different. Today I'm joined by a competitive programmer, Chi-Chi. Before we get into it, uh I think most people watching this probably see me as somebody who's like pretty decent at coding interview questions. And I would say that when it comes to coding interviews, I think I'm pretty decent. I could probably pass most of them. But when it comes to competitive programming and especially at Chi-Chi's level, I just want to stress that there's like a really big order of magnitude difference when it go when you go from coding interviews to competitive programming and even just competitive programming. There's a wide distribution of like skill levels. So I want to make that clear that we are literally not on the same level at all. And I think that's why I'm asking him these questions so we can get his point of view on a lot of this stuff. Um, also he has a YouTube channel, a Twitch channel where you can ask him questions uh on DSA and stuff like that. Maybe even get a little bit of uh dating advice if uh that's what you're into. Uh but not that any of my viewers would need dating advice, of course, but if you're interested in that. But yeah, I just wanted to give you a chance to like introduce yourself. Okay. Yeah. Yeah. So, uh a little bit about my background. Um, I've uh I've been programming for about like 15 years or so, like professionally. But um uh my background going back to like high school. Uh I did uh I did competitive math. I was doing like AMC12 AIM. I I like won the Minnesota State Championship in math league, but then never really made it super big in like USA Mo or IMO or anything. So I was like good at math and and like it translated really well to like competitive programming and stuff. Um, I did that,
Watch from 0:00went to Berkeley, um, got my, uh, bachelor's in math. I didn't do computer science. Um, actually went back to Minnesota and became an insurance actuary. Um, so I did I was actually working with like Excel files and Excel VBA and like there's a little bit of programming in that, but so so I did some of that. It was kind of a bad fit because like it's a lot of that job. insurance actu. I mean, they say it's like a good job and all that, but like the insurance actuary, it's it's a whole lot of reading Excel files and finding the things that are like a little bit off. And I was like, it's it's not really my thing. And then I started uh after that I started like um learning programming on my own. Like I had a nextoor neighbor um was my my best friend's dad. uh he was a longtime programmer for Loheed Martin and he was like you know you should you should learn this new programming language called Python. Uh so I was like okay um I'll I'll take a look. I learned Python and I was like I mean it just kind of went from there. I ended up like building my own I I was really into like game development. Um I was really into like the Starcraft 1 custom map interf like I built a whole Tetris emulator in Starcraft 1. But yeah, I I was really into that stuff and so I kind of built my own games and stuff. Used that as kind of demo projects to get my first software engineering job which was for an insurance software company. They probably like the actuarial background but in reality this was like a different
Watch from 1:30time like a very different time when Yeah. I I I realize how lucky I had it back then because um they were just picking up anybody off the street basically uh who was interested in stuff. Now nowadays it's it's like rough for new grads and we could we could probably get into that later but like um that's I I ended up applying for that job, got my first software engineering job there um insurance software and then I built my own I I ended up building an iOS game on the side. Um it didn't do that well. It made like 10 bucks on the on the on the app store. Uh but it got me an interview with um a social game company out in San Francisco and I've I've kind of been out here ever since. Uh, I did iOS for like four years. Um, and then left that job. I built another game. I built a web game that actually did really well. A bunch of influencers played it. It made a total of about $170,000 uh lifetime revenue. But anyway, I built that in ReactJS and so I used that as a demo project to get a uh front-end software engineering job and I've kind of been doing that ever since. And how old did you say you were when you like first learned to program? first learn to program. See that it's it's a difficult question to answer. Um because uh would you consider being on the bus in like seventh grade on a TI83 calculator learning basic or whether it was my XLVBA experience from being an actuary or whether it was the Starcraft stuff. The Starcraft trigger language
Watch from 3:01was was pretty intense. Um but in terms of like formal programming languages, you know, C++, Python and stuff, I would say somewhere around 23 24 kind of a late bloomer there. Yeah. So you didn't have like the traditional like programming background, but um even like in terms of like competitive programming, but you see like a lot of people they've been doing it since they were like 12 years old or something like that. And uh and I think you also said you moved from math uh over to programming and that translated well. Would you say it's easier to go from like math to programming like versus the other way around? Oh, math to programming versus the other way around. Um, I don't know too many people who go the other way around. Um, but I know a lot of people like uh a lot of people I I knew from Math League ended up do at least trying programming for a little bit. Um, uh, yeah, like a bunch of X-fang people because like the the skill set from like competitive math translates really really well. Um, I I I remember some of the the big names that I saw back in high school doing like IMO and stuff like that and then I I start to see them like doing the competitive programming stuff and being being that I'm like, okay, there there's a link there that's there. And and also uh in terms of like your background, um, you didn't mention it, but you are and I'm going to put this in the title, that's why I'm going to ask you. you are ex Google, right? So, you you did work at the big uh company Google and and you did that like you said without having the like the typical CS background or whatever. And I think that's actually pretty common for a lot
Watch from 4:32of people who worked at Google and other tech companies. Yep. Um yeah, I I worked at Google. I was uh I was part of YouTube uh for a couple years. They they had it the the specific team I was on was the mobile web search team. So like they they have like hyper specific teams. So like on a mobile device but not on the app but on a browser window uh the search bar and the autocomplete results that has a whole team behind it. Um so I was proud of that. So I guess specifically your like competitive programming background. I'm interested a little bit about like your journey and specifically like how how many problems have you solved and like what is your competitive programming background because obviously like you're good at it but what does that mean? Okay. Um, number of problems solved. I've I've probably I I I had like two different accounts. Um, trying to take out the intersection of the two. I'd say somewhere between 2,000 3,000 something like that. Um, but I like like I say, I mean to to like people who show up in my stream or like people in general, it's like it's not about the number of problems you've solved. It's about how difficult they are relative to your current skill level. uh you like if if you're at like the level where you can do hards, don't just clear out easys just because um just just for the problem count, right? Um uh so there's that. Um and uh I am on lead code. I've done uh in terms of like contest rating um that one
Watch from 6:03I mean contest rating has like kind of it it like peaked somewhere uh what was it maybe about a couple years ago and then AI started taking over and then like they that that that's a whole another topic. So um I wouldn't consider myself like an elite competitive programmer anymore. On the other hand, um I have done a bunch of problems and I still like on stream and and and am able to like break take a problem, break it down and kind of explain it for people and I still I still do the contest every week. Uh did it last week uh or sorry yesterday. Yeah. And actually uh a little bit later I actually want to get into that because I want to like I really want to like dissect like somebody's like thought process when they're like doing these things because I think it's different for everybody and that's kind of the side that like a lot of people don't see. they'll see like a solution and everybody has their own way of taking a solution, understanding it in a way that like makes sense to them. Like a lot of people will watch like a video, but even the videos don't really capture, I think, what somebody's actually doing when they're solving a problem. Because even in my case, if I'm explaining a problem, most of the time that's actually not the way I solve it because it's kind of like if I'm explaining like arithmetic, like adding, addition, or whatever, nobody's actually like carrying like certain things in their head. Like you take these certain like I think at least most people take like mental shortcuts without like realizing it. And I would almost say that like that's like a very very necessary part.
Watch from 7:35And I think that's why people see like a really hard problem and they're like, "Holy crap, like that's insane. I can't even imagine how somebody could solve something like that. And it's in my opinion analogous to like an instrument. Like I can't imagine how somebody could play like the piano so quickly. But like eventually over time you kind of build that like muscle memory. And I think uh you could use so many analogies even uh like CPUs. They have uh if I recall correctly, they have like dedicated circuits for doing certain like operations because they're so common. And I think there's like the inverse square or something that's like really really common in I think game development or other like graphics engines or whatever and I think CPUs if I'm correct maybe I'm wrong but I think they have like a dedicated circuit specifically to calculate like the inverse square root because it's so common and I think usually that'll happen with people as well and I think that's what you kind of alluded to where you you solve problems but you solve problems that are difficult and then eventually you just keep doing that you build up the like the circuits in your brain or whatever that allow you to like recognize the patterns and solve problems quickly. Um, what do you kind of think about that like uh in your experience like is that kind of correct or would you describe it a different way? Yeah, I think uh the idea of of having like uh specific shortcuts like you see a pattern and you're like bam segment tree or like uh bam uh like a monotonic stack, you know, something like that. um you see a problem like the way it's laid out, you like kind of know how it's going to you kind of know how the story is going to end. So yeah, you definitely've got uh like mental
Watch from 9:03shortcuts like that. And those are only developed through experience. Um you don't you don't really build it up by reading about it. You you you build it up by doing lots of problems, going through the weeds, uh struggling with it, trying a bunch of other stuff that doesn't work. And then I guess on that topic, you mentioned that a lot of people like like one mistake that some people make is that they'll solve problems that aren't like appropriate for like their difficulty level or something that isn't actually giving them any like benefit. Uh are there other things that you see people commonly like doing wrong? People are doing problems that are like uh out like far outside their difficulty, like if they're at a medium level, they're doing hard questions, things like that. Um what other things do I see people doing wrong? Um well, one one of the big ones is like giving up too quickly or like letting AI like especially nowadays letting AI just do everything so they don't learn anything. Uh there are ways you can use AI uh nowadays um uh where you can you can ask it to explain like just give me a small hint and then if if you're like stuck for like 15 minutes or so, you ask for a small hint and then see if that like mentally like unblocks you and then try it again. And uh and if if it doesn't work, get another small hint, just enough to get you past the rest of the way.
Watch from 10:34So I guess when you were solving problems, what exactly did that look like? Because this is what I think a mistake people make as well. Like what does it mean to solve a problem? Does that mean okay, you couldn't solve it? You looked at the solution and then you tried to understand the solution and maybe you did kind of have like a shallow understanding and then you got accepted on leak code or whatever. I think I think that's what people look at, right? Okay, I got accepted. You know, it's there's a statistic right there that means I solved problems. Is that what it means to solve a problem or does it mean that okay, you had to look at the solution and then you solve the problem and then eventually maybe you come back to that problem a week later and try to solve it without looking at the solution. Does that qualify as a solved problem or like something else? Like what does it actually mean to to practice or to solve a problem? Uh, for the record, I never go back to previous problems unless unless maybe somebody on stream requests that I solve that problem and I've previously solved it, but I never look back. Um, I know a lot of people do that. Um, but if you if you derive value from it, great. A lot of people use like to use like the Anky flashcard approach where like uh you you'll you'll have a problem and then you you'll solve it and then it'll just show up in another flash card again that that very same problem. So you have to solve it again. So like the spaced repetition thing. Um I personally don't find any value in repeating a problem.
Watch from 11:51Um but uh to answer your question, what does it mean to actually solve a problem? Well, well, for one, the the easy way is like if you already knew how to solve the problem, like you you type out everything and you get you get the AC done. I mean, you solve it that way. But if you didn't know how to solve the problem, then you have to figure out like what uh you you have to think through it. Um or like if if you didn't already know how to solve the problem, you have to think through it and then uh go through like all of your toolbox of uh techniques and tools or whatever. And then I mean if you solve it from that toolbox like it didn't immediately come to mind like that you knew how to solve it but uh you dug through your toolbox and you picked out a couple tools and they happen to work great then you solved it that way. um that's a learning experience because like you've learned that now later on in the future if you see a similar problem that can be part of your instant recognition method. But um if you don't if you dug through your toolbox, you couldn't find it, you take a you can take a hint um and then add that to your toolbox and then solve it. Or you can take two hints or three hints or whatever. Um uh but if you need the entire you know if if you've completely given up you need the entire thing um you you read the entire solution uh one thing you you can still do to to salvage some kind of learning out of that is um reading the solution and either trying to type it up yourself or reading the code and trying
Watch from 13:12to copy over the code like just read the code try to memorize roughly what it does and then try to type it out uh from memory. uh so that even if you have to look up the solution um even if you have to look up the whole solution you can get some kind of small learning out of it and uh the more of those little tidbits of you have to mentally fill in the gap you can get out of a problem the better. So like in terms of what qualifies as a solve, yes, technically it's just get an AC, but there are different levels of what you can get out of the problem based on how you approach it, right? Yeah, I think that makes a lot of sense. And now I'm curious about what that looked like for you for the problems you solved. Um, for example, like uh in my case, like if I solved a problem, like in my experience, sometimes I got to problems that like I didn't have a ghost of a chance of getting it right. like I didn't know what the hell a segment tree was. Maybe I could have derived it. Maybe I could have like, you know, you could say whatever. If maybe if I was a math genius, I could have done it. Even if I could have probably would have taken me hours and if it took me like, you know, an entire day of just banging my head against the wall. Um, I probably would have gotten a lot out of it, but also maybe that's indicative of like the question was too difficult. So I'm curious like in your experience and and to be honest that actually was the case a lot of my time like I I remember looking at a problem and like I spent hours and hours even sometimes after looking at the solution I spent hours trying to understand it. So I'm curious in your experience like what did that look like? What was like the longest it
Watch from 14:45took you to like maybe fully understand a problem or to for you to be satisfied with like okay I kind of get what's going on and maybe I couldn't do it initially but now I do. Oh oh oh the the longest it took me. Okay. Um there was a problem on this online actually my first online judge wasn't lead code it was this thing called sphere online judge um there was this problem that okay I was feeling real confident one day and then I went after a problem that um so the way sphere online judge works is they have they have the problem and they won't let you look at solutions uh like other people's like previous solutions and stuff. Uh so like if you don't get it right like you're you're like stuck stuck. Um but like uh this this problem I think had like two people in in the entirety of Sphere online judges existence that had solved it before. Um actually I I can give you the quote. It's it's called MEPerm Perm. Um, and so you can see a bunch of like attempts from 2010 uh from from a guy for like I I tried that problem for a straight month. I tried over optimizing like my C++ code. Um, and I was just like not getting anywhere. Um, but then later on a code forces GM showed up in my chat and said um told me told me roughly what's up. Um, and uh I don't know. Should I should I like spoil it?
Watch from 16:17Uh yeah, go ahead. Okay. Okay. So it it turned out to be an FFT problem. So that's an example of like I I did I did not know how to use FFT in a competitive programming environment. Yeah. Uh so that that's an example where I I uh I tried I tried so so what what what are the lyrics? Oh my god. Um but anyway, I got so far. I tried so hard, but but in the end it was FFT. Um and I I just didn't know how to use that technique. If I were to do things again from the start uh on that problem, I would uh I would attempt that problem for like maybe a good half an hour to an hour um before like looking up a hint because um one I mean it's it's I mean okay mathematicians are a little bit sadistic or like masochistic that that's the word right. Um they they can they can tolerate a lot of pain and they they like they like the mental pain of like trying to solve a problem. Yeah. um they they they like the mental pain of trying to solve a problem. And so they will be attracted to very difficult problems that look like they're out of reach and like I I think I could get that. I I really think I got a shot at that. Okay, maybe use this technique. Maybe use this other technique. And then you just keep working on it, working on it, working on it, and all of a sudden like six hours have gone by and you're like, I really haven't gotten anywhere on this problem, have I? Um but yeah, no it was like that with me in that problem for like a whole month. Oh yeah, previously before that um before that GM
Watch from 17:47just came in and randomly told me it was an FFT problem. Uh I had given it to another another uh another code forces GM. Um so like there's this guy Luen Gun who ran like a a competition at Stanford or something. I did this competition uh won that thing. It was like a it was like a tiny thing. It wasn't really a big deal. Then afterward, I like asked him like, "Hey, there's this really difficult problem I don't know how to solve. I can't see the solutions. Can you take a crack at it? Here's my existing code." He took a crack at it for granted, he he I don't think he spent like that long um like trying to crack that problem, but like he couldn't figure it out either. So that if if like a code forces red is not figuring that thing out, it's like, "All right, dude." Yeah. I had like an exact same kind of experience because I think in terms of like what people can do wrong. Uh people like to anybody watching this, especially if like you're a beginner, you're definitely going to do something wrong. Like don't look for like the perfect way to do it. Sometimes you're going to like spend too much time. Sometimes you're going to not spend enough time and just end up memorizing the solution. And I think it's kind of just about trying to find like a balance and like what works for you. But I would say my biggest problem was that I wasn't willing to like look at a solution or I wasn't willing to do that because I felt like damn like if I don't figure it out myself that I'm just memorizing a formula. I'm just like I have to like derive it. I have to like prove it. I have to do this and and for some problems you can kind of get close like like I think like some problems like alien dictionary it's really hard for a beginner but like it's pretty intuitive.
Watch from 19:18There's nothing super crazy as long as you know like the core graph algorithms behind it. But there are some things at least for me like the monotonic stack and I wasn't solving like an easy monotonic stack problem. It was like one of the harder ones but I just could not like I just felt like it was possible like okay it seems like it's possible that there's a linear solution to this but I can't figure out what the it is and I have never heard of the monotonic stack. I don't know to use it in that way. It's such an unintuitive thing for me even to this day. I think those are like something about that just knowing that like the ordering of a stack can help you solve a problem unless it's like a really trivial one. It's just so like unintuitive. But once you know the core idea like you can kind of apply it and you know to think of it and you're just like okay I don't really know how to solve this problem. Does a monotonic stack work? you just try to like force it in and you find okay there is a way to to do it and yeah like it's just so frustrating but like you again like if you're just preparing for interviews and trying to do it in a time efficient way like you kind of have to like find the balance somewhere in there and I think the people who do it best are the people willing to like balance that. Yeah. I feel like for time pressure the the biggest thing for time pressure for me um I I feel like you've got to do like you've got to do the lead code contests. Um, I you could have a substitute in the sense that you take a problem and you like set yourself a timer of 20 to 30 minutes or something.
Watch from 20:48Uh but it's really not the same as like being in kind of a global contest where everybody else is kind of doing it under the same time limits and okay prior to AI like being able to solve everything like you could see the leaderboards you could like see how quickly each person solved each thing and like you could al you could also read their solutions to see how like uh one of the one of the most helpful things for me at least for the contests as far as contests are concerned I mean by the time I got good at contests like passing lead code interviews was like essentially trivial. But like for um for the purposes of getting better at contests, one of the uh one of the most useful things I found was looking at a top competitor, how they wrote their code, how they structured things, what kind of templates they used. Um yeah. Yeah, I completely agree with that. Like the contests is and I haven't really done many contests before, but I think that kind of like simulates the like pressure of like a real interview. Um, on that note, I'm kind of curious, what do you think the role of like talent versus practice plays? Obviously, like most people aren't going to be like world class uh uh what's his name? Tourist or something like the Yeah. Uh, yeah. Yeah. Like probably most people aren't going to get there unless they're like doing it out of the womb or whatever.
Watch from 22:16But like from a to a reasonable extent, like what's the difference between like talent versus practice? Okay. uh for the purposes of competitive programming or for the purposes of like getting a job in software engineering. I would say mostly getting a job uh but you can also touch on like the competitive programming aspect. Okay. Yeah. For for getting a job for software engineering um it's it's just practice. Um, I I think most people who are, you know, good enough to get and keep a software engineering job. Um, that level of intelligence, uh, should be good enough to be able to grind at lead code. Just do lots of problems. Um, if you get stuck, you know, um, if if you get stuck, well, first dig through your toolkit, then like um, then use AI to like maybe give you like a little little hints here and there or watch watch Need Codes videos um on on uh, you you still do the videos on like every solving every problem, right? Uh, sometimes I take breaks and stuff. So, yeah, but sometimes you take breaks. All right. All right. But but if there's a problem that need code has to solve, you can watch that video, too. He he gives really good explanations. Um but yeah um uh practice is uh absolutely key. Uh I know there are a lot of uh there are a lot of juniors and new grads who stop into my stream like they ask me to do like resume reviews or like ask me like hey I'm having trouble trying to get a software engineering job. What do I need to do? I ask them questions. Actually, one one happened yesterday where a guy was getting like uh I think about he had
Watch from 23:36about 10 online assessments, but he was only passing a little over half of them. Um and I was like, at that point, right, your resume is probably good enough because it's attracting some attention. But at that point, you've got to like buckle down and practice like at least like couple hours a day. try some lead code mediums, maybe a few lead code hards, um to to like kind of kind of get that get that uh six out of 10 to like a 10 out of 10. Um because um I feel like that's the part that's most under your control. um right uh being able to practice lead code and solve those because unlike other parts of a uh a technical assessment, lead code is the only one that'll tell you yes or no, accepted or wrong answer TLE, you know. Yeah. Um so given that you get that kind of binary feedback, I feel like that's that's the part that's most under your control. Yeah, I I definitely agree with that. uh in terms of like the role of practice and we kind of like talked about this earlier. How much of a difference because I I hear this question a lot which is that like I feel like I am practicing. I feel like I solved all these problems. I spent you know all this time uh like what am I doing wrong and like I would say that boils down to practice versus like deliberate practice. And we kind of like touched on that which is like solving problems that are actually like you know challenging for you and you're actually learning something new and also doing it the right way in terms of like getting hints and understanding a solution and stuff.
Watch from 25:08Would would you say like that's generally true in like your experience? And I think maybe somebody like you who's probably just genuinely curious and genuinely interested in in these types of things is probably just going to naturally do it the right way. Whereas somebody who really really hates this just, you know, without even trying, they're just going to take the shortcut of naturally trying to like memorize a solution because they don't actually care, you know, like why does this algorithm work or whatnot? So would you say that like the practice versus like deliberate practice is something that people make a mistake on or do you think I'm like not right about that? Okay. Practice versus deliberate practice. I can you clarify what you mean by deliberate practice again? Yeah, I guess in terms of like somebody who maybe they're like practicing in the wrong way, which could be a dozen different things where where it's like solving problems that are just too easy and you're not really learning something or just looking at a solution and memorizing it or something like that. You can learn a little bit that way, but it's it's wildly inefficient. Um I I think the two main tracks of learning lead code um that uh that I've heard other people doing and then I myself have done done one of these um the the track of just doing random problems at or a little bit above your skill level or the other track being taking each of the different topics and then if there's a topic you want to learn just doing a bunch of problems in that. Um, one of the main I I prefer the the uh the just do random pro problems approach. Um,
Watch from 26:36because uh, one I like to deal with the uncertainty. It's like you're you're being given a problem. It's like it's it's it's kind of a dog fight for me. I'm a little bit of a competitive person. I'm like, "All right, come at me with whatever you got. Uh, I don't I don't know what techniques I got to use. I've got to think on the fly." I mean, that's that's genuinely exciting to me. I mean, just telling you that gets me all excited, man. I I got to do problem after this. Um but yeah anyway um but yeah there there's there's that line of thinking then the the line of thinking where you do practice based on the different topics. Uh the one problem with that I mean that that's great for like hammering home a particular topic. Um on the other hand when you get a problem in that topic you already kind of have like the horse blinders on. you already are like kind of laser focused in on a specific topic. So, you're not digging through that toolbox. And that's that's kind of an underrated part of learning lead code uh learning how to do lead code problems that beginners just don't really know or understand. It's that you've got a toolbox. It's it's not only having a lot of tools in the toolbox, knowing what what the right tool to use is, but also digging through that toolbox to find stuff like rip out that monotonic stack or that Fenwick tree or whatever um uh from the bottom of that toolbox if you haven't used it in a while, you know. Um and uh yeah, that that whole process is like a part
Watch from 28:08of it. Um so um I guess to answer the question of you know taking shortcuts versus uh yeah taking shortcuts or right like not really doing things the right way. You can learn a little bit um I I think what oh right uh to also answer one of the previous questions you had about like what things do junior engineers or like people who are learning lead code for the first time do wrong. Um, one of the big ones is passively consuming lead code as um, I think you touched on this in your video too, right? Um, right. Uh, passively consuming lead code content and thinking they're learning a whole lot. Uh, you I mean it's it's it's a very trivial amount you're getting by osmosis. You really have to you really have to do the problems. I guess one question in terms of like the context of your experience which we didn't like talk about too much but you have like quite a lot of experience like in the professional world in development and I think you're no longer at Google you're at a different company right now. Uh in terms of like everything in your experience like has DSA been useless and if so how useless or how useful and like how do you think about that in terms of like what you got out of doing this? Okay.
Watch from 29:40Like my philosophy on like what lead code does for you as a programmer. There are exactly two benefits um to doing lead code um like at somebody who's good at lead code versus somebody who's not. The first benefit is that when they run into a uh a problem that requires kind of an algorithmic solution like maybe it's an n squed type problem but then they find an o sol they're more likely to find the o solution or like introduce memorization at the right spot like their head space is already like kind of there and so like if if you have somebody who's less good at lead code um they they might write a bad solution there and then if that becomes a hot path later. Sometime later down the line, this affects the business operations. Somebody has to diagnose the problem, pinpoint it right back to that that piece of code, and then a senior engineer has to come in and then like change it um so that it's better. Um so it introduces like having somebody who already has algorithmic complexity in the back of their mind um just makes that whole process a lot easier. You don't run into these landmines all over your code. you're going to have landmines in your codebase anyway. Any sufficiently large codebase is going to have landmines, but you get a fewer of the algorithmic variety if you've got people who are good at lead code working on your stuff. Uh the other thing is because lead code beats you down so hard with a okay, you got you got you got one test case wrong, you got the last test
Watch from 30:56case wrong, wrong answer, zero points, you get absolutely no credit, right? Um, so based on that and the people who are good at lead code have been beaten by that stick so often that they uh they they naturally kind of catch their own edge cases when they're writing code. Yeah, I 100% agree. Yeah. Mhm. Yeah. Th those are like the two things. But like does it make you a much better programmer in whatever framework you're working on or what I mean? Does it make you a better React engineer? Does it make you a a better golang injury? I I I really don't know. I I can't really speak to that, but those are the two really big ones that I see. Yeah, I 100% agree with that, especially the like edge case aspect of it because uh I think that's like one of the things that can so easily be applied to so many different things because it's not just like if you're programming then you're going to think of like the unit tests that like have to be tested whether you implement the unit tests or not. you still have to like think about like the unexpected behavior like the zeros, the whatever empty arrays and sometimes it's not even that trivial. Like you really have to like even just be aware that something like that's possible. You wrote code, but you're pretty sure that there's probably some edge cases that you're missing. You might not know what they are, but you even have that like tendency to just know that like intuitively something might be missing. And in my experience, um, for me at least, I would say it helped me, I I guess just stay like
Watch from 32:28familiar with like programming style of thinking cuz I didn't like I mostly have stopped doing math over the last like decade. And um, most of the time like math isn't going to be directly applicable if you're doing like full stat crud development. But I do think like the muscle memory of like typing something actually out which I don't know about you but when I was working at Google a lot of it wasn't like I felt like I was kind of just a copy and paste monkey like if I if I didn't know what to do or like how to how exactly to implement something it was like okay in open source it's like you go to Stack Overflow or nowadays like ChatgBT at Google for me it was just like go through the code search go through the code base find somebody who did something similar who used this library copy and paste their snippet make some edits and like I I felt like I lost a lot of like at least what I was doing. Maybe you were doing more interesting things or for me like I I felt like I wasn't really thinking that much for a lot of the stuff that was going on. It was more just like reading code rather than writing it. Yep. Yeah, you're absolutely right. And your experience completely mirrors mine. That's that's why I left after two years. I was like that that that kind of programmer where you're just uh most of your work is just going around digging around to like uh numerous teams trying to find out who worked on something similar, copy pasting that code, throwing it in a feature flag and then going through all the bureaucratic red tape to get in and then all the all the failing unit tests that had nothing to do your with your code and oh my god uh ju just thinking about it gives me PTSD.
Watch from 33:59Um that's funny. Yeah. No, that's that's why I went back to startup land and uh that's kind of why where I've been ever since. So, I had one like actual coding question. So, I went through your leak code profile and I stalked you and I saw that you solved and this this was actually a relatively easy one and I think you solved it during the contest. So, it was maximum score of a split string and I was looking at your code and so this is a problem I think that this is not what I would qualify as a crackhead problem. I think most people can reasonably quickly get to a level of leak code where they can solve this problem, but everybody solves it differently and um even like probably the best people will have like a different thought process and I really want to know like exactly what was your thought process because if I explained this video this solution in a video I would really go step by step and say okay well like you know here's some like things I notice about the problem here's some observations I make and so knowing that We could try this. Okay, if we try that, it's going to be a little bit it's not going to be so efficient. And then so we try it the other way and that one is efficient. But if I'm actually solving this problem, especially trying to solve it as quickly as I can, there's there's a few things I'm just going to like laser point on, which is that okay, so this is a array problem. like if we were like doing the simulation of what the problem is asking us and you know recalculating uh maybe I'll give some background on the problem when I upload this video but recalculating the prefix sum every
Watch from 35:27single time etc. It's probably going to be n squ. Okay. Well, like that's kind of the benchmark. Can we do better? Very quickly, I don't know if it technically qualifies as a greedy problem or just a prefix some problem, but like very quickly, it's very simple to to realize that there's a shortcut that you can get the minimum and like if you have the prefix sum and you do it like in an intuitive way, you can solve it in linear time. And like maybe and there's never going to be a better way than that. And if there's a worse way than that, I don't really care about it. I'm just going to laser point on that solution and just try to implement it and then figure out the code and I want to know like when you solve this problem what exactly did you think and how how did you get to your code? Okay. Uh okay as as I am getting to my Okay. So with the maximum score of a split let me know. Um this one this one took like I think a couple minutes or something. So let me let me go back and like read through it. Um okay so you are given an integer array nums of length n I okay prefix sum suffix min I was okay the first thing I thought was like both of these are calcul you can you can calculate in linear time and uh how do I get them both on and then the score of a split is I didn't even read the part about the score of a split I skipped over that uh ran tests and it it it failed and I was like oh wait the score isn't the sum it's the subtraction so I didn't even read that part of it. Um, return an integer denoting the maximum score over all valid split indices.
Watch from 36:58Okay. Um, so like an integer over all valid split indices, you want the maximum amount. So like the prefix sum in order to get the well the first part, the prefix sum, you have to make the prefix sum array. And then to get this suffix min thing, I figured you could just uh so like a after I read that maximum score over all valid split indices. Um at so at first before I read that statement, I thought maybe you had to find the score over all split indices, but this is just the maximum overall valid. So um it's it's a little bit easier. U the prefix sum, you have to build up the prefix sum array for this anyway. Um so like by default, you have to build that. But for the suffix min, the minimum value from the right, um, I figured, okay, once you've built out your prefix summary, you you take your your current uh your current suffix minimum and then just roll it right to left and you you you have to store a singular value and then you compare it against that. Right. So that's how I would solve that problem. Um, right. Does that make sense? Yeah, exactly. And so when you thought about it, like did you think of it in terms of like the time complexity or like okay like when you saw that there's a linear solution often linear is the best but like you probably didn't even think that like is there something better than linear, right?
Watch from 38:30You you don't need it because uh okay um uh on on lead code if you see 10 to the 5th uh n login or better will do it, right? Even even if you had to for whatever reason sort it, you're you're fine. Okay. So, so you used the constraints as like part of your you actually read the constraints or you didn't. Oh, for this one. Did I read the constraints for the Yes, I did. I read the constraints um just to see. Yeah, I don't remember if I read the constraints for this one, but I I probably did. Okay. Um but it it it wouldn't have mattered either way, right? And so if I was going to make a video, I I want to explain it like step by step for people because often like if you say like, okay, I intuitively just kind of knew this because of like, okay, I've solved similar problems or like maybe a single statement and that kind of intuitively just tells me like something about what the solution is going to be. Often for a lot of people, like that's like too far of a jump. They really need to see like the exact like calculations that were made to like get to this point. um and it's really useful I think for like learning and stuff but uh for me at least like if I'm actually just trying to solve problems as quickly as I can I really skip a lot of those like one thing I noticed about this problem is that like okay so you solved it by computing the prefix sums and then going in reverse order to just kind of track the suffix men uh but but it could have been done the other way right we could have just computed I think the suffix men's and then just kept and then scanned from left to right to keep uh to maintain whatever the prefix men were prefix whatever sum is. Um but like in a real problem like if I'm solving I'm not
Watch from 39:49going to go through all the different ways once I identify a solution. And so um I I guess I just wanted to mention that because um I think people don't really get to see that like people don't see what exactly is like going on in somebody's head and whatever like mental shortcuts they're taking. And so I wanted to just kind of like get your thoughts on that or if you even have like a different problem that was like more difficult or something that's fresh in your mind where you kind of want to like elaborate on like some of the mental shortcuts that you're actually taking whether you realize it or not um like in the moment. But yeah. Um I guess in terms of mental shortcuts, well this this was actually from the from the contest from yesterday. This was the Q1. Uh the Q4 uh was like a a complete mental shortcut. Uh the Q4, let's pull it up. Okay. Uh weekly contest 482. Oh, uh somebody in chat asked about those mental shortcuts. Any advice not to take them during interviews? You should take them during interviews because it it it helps you solve them quicker. Um but yeah, um number of balanced integers in a range. Let me like send it over. Uh that guy right there. Um and I'll send you my submission then. So um number of balanced integers in a range. Uh so you're given two integers low and high. Uh integers called balanced if it satisfies both of the following conditions. One it contains at least two digits and two the sum of the digits at even positions is equal to the sum of the digits at odd positions. Um, immediately when I saw that, I was like I knew how to do it in in terms of one,
Watch from 41:20it's going to be a digit DP. Two, it's going to be a um do the range from zero to high minus the range from zero to low minus one. And uh and I knew the states for the digit DP. It would be like index um whether you're doing the high or the low uh whether the digit at the digit was limited or not because if you picked a lower digit earlier um the the future digits are not limited. You can pick the zero through nine um and uh uh what was the uh the other one? Oh yeah the the other state is the difference between the even and odd um indices. uh the difference between the ind the digits uh the sum of the digits and on the even and odd indices so far um and then at the very end to check whether it's a valid combination you have to check that that difference is zero right okay yeah so it it's a digp like immediately figured that that's a metal shortcut to me because I' I'd seen so many problems like this before I was like yeah that's that's how you do it um I cannot believe they would put this as a Q4 um right um but Yeah, it's uh top down. Um yeah, the Python ad cache uh decorator is is pretty good for like top downs. Um sometimes lead codes constraints will screw you over there.
Watch from 42:53Um and you need to do a uh deep you you need to do like a cache clear on the function. Sometimes that trick will help. It's it's all these little things you find out when you get like like 15 memory limit exceeded and you don't know how to solve the thing. Right. Right. Um, so sometimes that helps. And if that doesn't work, yeah, you might have to write it, rewrite it bottom up. Um, it's it's just I don't know. I I have a habit of doing top down, but um yeah, bottom up is perfectly valid as well. I guess on that point for me, I would say like DP and for most people probably DP is like one of the hard uh patterns and the top down is generally I think more intuitive for me. Like I would describe like the bottom up solutions really as like a math problem like I I don't know I I think there is like a discrete math concept that like DP is based on. I could be wrong. Isn't it like induction or something like that? Oh yeah it's uh yeah DP is basically strong induction. Yeah. Uh where you strong induction is where you use the previous statements to prove the next one. And so that that is that is effectively what DP is. Yeah. And for me and I guess it comes with practice because like you can definitely improve like if I'm doing like a one-dimensional like DB problem like the the space is you can kind of visualize the space and whether you're going left to right or right to left once you build up the equation the relation then it's it pretty much becomes intuitive. The two dimensional ones to this day I still solve them.
Watch from 44:11Some people get mad in the comments. I still solve it like with the the two dimensional grid. I fill it up from right to left, bottom to up. And I do that because it's more usually more consistent with like the top down solution. I could probably do it the other direction. Like eventually with enough practice, maybe that one way would become more intuitive to me. But it's like no matter how you do it, maybe I just haven't figured out the right way to think about DP problems. But I feel like no matter how you do it, it's just confusing because like what okay when you're solving let's say a bottomup DP problem, how do you do it? And what is actually like what are the a few like bullet points in your head that you're actually going through cuz because there's like okay so how do you populate the dimensions? Okay, so and then so for an individual square what does it depend on? It depends on like it's right neighbor, it's whatever neighbors, right? And so you have to think about the ordering, you have to think about like the geometry, what the equation actually is, what the edge cases are, like what the value itself even means and and if you have like three dimensions, that's even harder because then it's like visualize that. Yeah. So, so what what do you think? Well, I I think about like which values do I need to calculate first and which which values depend on them, right? So you the ones you need to calculate first, you calculate those first and then like then just run the calculation run the loops in that order. Um that that's the way I think about it. And like sometimes it doesn't even matter whether you do um whether you do that
Watch from 45:38right to left, bottom up or like the top top to bottom, left to right. Yeah. Um sometimes it doesn't matter but yeah. Yeah. I just I just think about like which is the first one I need to calculate. Yeah. For me, for some problems, I find that it's kind of again, I always just end up going back to the thought process of like the recursive solution because it's I use the word like base case because like you said, like what's the first what's the starting point? What does it actually mean? What's the next one? How do you compute it? What's the relationship? What's like the directions? And yeah, and do you do you visualize it? I guess like do you think about like the grid or do you just see it in terms of code and like the whatever grid like you're using and like the indices of that grid. Sometimes I think of it in terms of the grid sometimes I think about it in terms of uh it really depends on the problem. Yeah. Right. Do you do you have like trouble with like the the DP style thinking or do you think your math background like helps you when it comes to that? I think I'm like okay at DPS. Um uh in terms of bottom up uh I think I'm a little slower than average um for my skill level in terms of like like populating everything out um like like having trouble like just just kind of setting up the indices and like it it has to be this plus one this you know that that sort of thing. Um but yeah uh but but like the from the top down DP with the with the ad cache handler which which is like good enough for pretty much most of the uh DP problems on uh in
Watch from 47:10Python on lead code um that handler and then doing the top down it's comes pretty intuitively to me and uh like in it it's it's essentially a sparse table because um yeah so you you don't have to like pre-allocate a certain amount of space um in like a DP table. Um it just takes it takes the tupil, memorizes it versus its result value and uh away you go. Yeah, I agree. Uh and sometimes for me that that's kind of what makes it almost confusing going to the the bottom up solution because like you said sometimes in the top down it'll be a sparse table but obviously bottom up like you do have to do the entire ordering and then so like the translation becomes kind of confusing. Um, would you say that that that's just like a matter of practice? Like you said that the the bottom up isn't like your strongest uh way to do it, but if you just had practiced it and had you just done it that way, like like is it literally just a matter of doing it that way? Because like obviously getting good at graphs isn't going to necessarily help you do bottomup DP. It's kind of a different like skill almost. Mhm. Yeah. Yeah. Just just practicing that way. If if somebody tell told like lock locked me in a room and said you're not getting out until you do you do 100% of these problems uh bottom up DP way instead of top down. No ad cache handler for you buddy. Um I I' I'd probably figure it out. Um yeah. So uh somebody asked what are you guys building or side projects? like my I don't really have like me personally I don't have any side
Watch from 48:42projects right now so much as uh I mean I am getting really into like uh stock trading and stuff like that. So I did build um I didn't I didn't build it myself. I used Claude. Okay. Now the whole vibe coding thing, right? So Claude's just extremely good. Like you just ask it to build something. It's like build a build an interactive broker client. Um it it build an build an interactive terminal um uh that'll that'll let me do this this and this and like it it just just whipped it right out. I had to change like a few small things here and there. And what's really ironic is like I do that at work now as well, right? And most of my co-workers also kind of do the same thing and I work mostly on like kind of the front end side of things. So um like building out UIs and stuff. You could even give it a Figma design and it'll like do it mostly correctly. I was like, "All right, dude. What's my job now?" Yeah, that's true. Yeah, that's that's really interesting. I think um I try not to talk about this too much. I think I made a video about it like a year and a half ago, but like I don't want people to come to me and think like I'm some authority on like the future of programming. I think it's just kind of interesting to watch what happens. Literally nobody knows what's going to happen. But like you said, I think not enough people I feel like have actually used the newest like Claude like Claude Opus 4.5. And it's uh it's just so like so good, but it's so fun to use it for me cuz it it takes like I imagine if I was back at Google now, I wouldn't have to go copy and paste those things and find what I'm looking for. It would it
Watch from 50:13would already kind of know that. It wouldn't be perfect. There would be bugs in it. But then I feel like for me, like a lot of people don't like this new way of programming where they don't get to type everything out. But for me, I I would like it because now I get to actually focus on like the logic that's going on. Maybe fixing bugs, maybe deeply understanding it to make sure everything is good rather than like being a copy and paste monkey. But in terms of like what the future holds, it's uh kind of hard to say. Yeah, it does. It does feel a little bit odd like you're you're just typing stuff and then you're just waiting. Yeah, you're just waiting for it to output something. You hope it does the right thing, you know. And uh and of course, if if you if you're at Google, um you're not going to be using Claude. You're you're going to be using Gemini. Like there there is no way that would get through legal. Um um I'm curious when you do interviews, is it do you just kind of like breeze through them? Do you almost like slow like if you get a problem that's really easy, do you almost slow down just to like make sure the interview can interviewer can like keep pace with you or like how do you like approach them? I I go at my usual pace. I I just blow through it. Um I blow I blow through it and some sometimes it gets me into trouble because uh I I like don't explain it enough or whatever. Um but they they can't they can't give me less than the highest grade because I like solve the damn thing. So it's like Do they suspect you of like cheating ever? Oh, because uh the last lead code question interview I had well I mean the last time you know I'm I'm trying to think I haven't gotten too many lead code problems to be honest so
Watch from 51:44there wasn't really the opportunity. Um, but at the same time, yeah. No, I I don't feel like anybody like suspected me of cheating or like disqualified me for cheating or anything, but like because I I I'll still like talk out I'll like like I was on that one stream. I like talk out what I'm doing while I'm typing it out and like it it's something that's like really I I would feel like it's kind of hard to fake. Um, Hola Hola has a question in the chat. Can you tell us more about your Amazon experience? uh you had a lot of stress and anxiety I believe how you left and where you went to next. Uh yeah um I guess the short version is like I it was pretty much my first job like out of college. Um it like in hindsight like I can understand it a lot like the whole experience I can understand it a lot better in hindsight hindsight than I did at the time. Um, but basically I had that job. It was really kind of a shitty team environment. Like that's like I don't think it's really debatable. Anybody on that team would have told you that. Like people were in that. It wasn't even a Slack channel. It was something else. Chime. Um, and they were just like kind of really depressed and like angry with each other and stuff. People doing uh poll requests at like 3:00 a.m. getting up next morning having morning meetings. And you can see why they're pissed off.
Watch from 53:16So like I don't blame them. like you didn't really sleep that night or this this entire week, did you? So, like I can kind of see why they were mad. But, uh like in hindsight, I probably could have survived that experience even if it would have been kind of crappy. Um I'm sure most of the that team did end up surviving it. Like even there were like four other new grads that were hired like at the exact same time as me. Um and I'm not really generally one to like just kind of give up if something is hard. Like it sometimes will motivate you even more. Um, but uh, there was a lot of like personal stuff going on as well. Won't really get into that, but um, yeah, I was like 22 and so like just some kind of like random stuff was happening. I didn't really understand it at the time. I didn't really understand it until years later. Uh, but some of it was just kind of out of my control. And I think that kind of explains why things didn't really go super well. Um, but my kind of mindset when I quit was like, okay, this is really crappy. It's 2020. the COVID job market is pretty bad. Everybody just kind of laid off. And thankfully, like a year later, it kind of went in the reverse direction. Companies started hiring a lot. But I was I was just like, "Okay, I was smart enough to get this job. I don't really know what's going to happen in the future, but hopefully I'll be smart enough to get another job that's also pretty good." And I was lucky enough that like a year later, I got interview at Google. In the meantime, I was just making videos on YouTube. I got an interview at Google.
Watch from 54:33super nervous because I didn't really get any other interviews. I don't know why. Like I don't know why sometimes big tech companies are more willing to interview you than like smaller companies. But um yeah, and then I had prepared so much that surprisingly I wasn't even that nervous for the interview. Like I had adrenaline pumping, but I also had like a lot of confidence and like I I I solved a problem that I I swear I had no business solving this problem. Um, I don't even think I finished actually writing the code for it, but I think the guy was impressed enough because it was like I think it was nested binary search, which I I don't think I'd ever seen that before. I didn't even know that was a pattern. And I I might be misremembering, but I think it was nested binary search. And then on top of that, you had to do like the last optimization, which I didn't have enough time to code up, but the optimization was like then you do pre-processing with like a hashmap or something like that, and then you have to use the monotonic stack to like do it efficiently. And so you had that that part of code was nested inside of the nested binary search. And I was just like, yeah, I remember drawing on pen and paper showing the guy like, "Is this what you're asking?" And the guy was like a Chinese interviewer, super thick accent. And I I don't know if I was the first guy who like actually came up with it, but the guy looked so happy. He was like, "Yeah, that's exactly right." And I was like, "Holy shit." Like, "Did I actually do it?" Yeah. And um that that has that has got to be one of the highlights of your life. like guy who cannot understand you. You are giving him the I I I bring forth to you these gifts. Please accept. And he accepts. That's amazing.
Watch from 55:56Yeah. Exactly. And then I talked a little bit about this in like a video I made, but it was also just like a like kind of a mind game, like a psychology game because like after that experience, I was just like you don't really know how to process it. Like I'm not like a super like emotionally intelligent person. So this was like the first time in my life where I was just like academically like had just objectively just like failed and I didn't really know how to approach that. And so I kind of just like I had a lot of like I mean it's a long story but I kind of just like tried to reframe my thinking around like effort and like passion rather than just like thinking of things in terms of raw intelligence cuz like I I'd lost the battle when it came to raw intelligence. So I was just like I have to think of it in another way or else I'm just going to feel like about myself. Um, yeah. What neural net nemesis says, uh, what is your favorite book? And if you had the opportunity to redo something about your life professionally, what would you have done differently? Um, favorite book. Uh, it's hard to think honestly, like technical book. I haven't read too many technical books, but I really like DDIA. It's a really like commonly mentioned book. I don't think most people actually read it though because like you will often also see people complaining about the book how it's too dry too in depth when it comes to certain things which it definitely is. So nowadays like if you're reading it like certain things you might be able to skip over or just kind of use chatbt to explain it uh more in depth. Um but I really like that book cuz like I said earlier uh in this that like I have kind of like the autistic
Watch from 57:25mind when it comes to thinking things. I think of things in like a very like bottom up way and that like everything is like a tiny little piece and you understand like the lowest level and then reconstruct it and then you can kind of understand the big picture. Like that's kind of how my mind works. So I I hate summaries. I hate like some where somebody will give you an explanation for something but it doesn't quite explain it. It it sounds good but it doesn't actually explain it. And DD DDIA generally like really explains it. and if it doesn't explain something, there'll be like 20 references at the end of the chapter which will uh explain it. So, I really like that book. Um, in terms of like what I would change in my life professionally, I think things worked out pretty well. I was pretty lucky. Um, but probably just focusing on non-technical things earlier in my life, learning certain socialization skills, networking skills. Any recommendations on books to learn algorithms? I mean, if you really like learning from books, you can, but probably I wouldn't. I would probably just use whatever Yeah. like tool or website or leak code or whatever. Uh cuz reading is only going to get you so far. Just try to write the code whether you do it on pen and paper or like with a keyboard. Okay. And I guess this is the last one here. Um, in your professional life, how often do you think you get an actual dopamine hit from your work? I don't work in CS, but out of uh 10 shifts, 120 hours a month, I might only get two or three instances, a few hours worth per
Watch from 58:56month, but I feel like that makes up for the mind-numbing day-to-day work. Huh, that's a really good question, I guess. Um I I don't know if you could should call it a dopamine hit or not, but um usually I'll get like satisfaction like for me usually the hard thing is like starting something like sitting down and starting it for the first 30 minutes or an hour or um like a context shift. But just kind of like this conversation once I kind of get going like once my brain turns on like I don't know if it's ADHD or not like I was never diagnosed but like once I get going I'm like I'm like on it's like I took like people will say are you on aderall like why are you talking so fast and it's like for me it's like no like like I'm just like I'm wired now like I just woke up and like now I'm good and I can keep going. Uhhuh. Okay cool. Um yeah. No absolutely. Um, I know in terms of like dopamine hits from uh actual dopamine hits from my work like in engineering, I'm I'm trying to think uh from my own experience as well. Um, it's few and far between, but yeah, for me it's worth it. But yeah, no um it was it was absolutely wonderful to talk to you and need
Watch from 1:00:28Full transcript
- 0:00
Today we're doing something a little bit different. Today I'm joined by a competitive programmer, Chi-Chi. Before we get into it, uh I think most people watching this probably see me as somebody who's like pretty decent at coding interview questions. And I would say that when it comes to coding interviews, I think I'm pretty decent. I could probably pass most of them. But when it comes to competitive programming and especially at Chi-Chi's level, I
- 0:22
just want to stress that there's like a really big order of magnitude difference when it go when you go from coding interviews to competitive programming and even just competitive programming. There's a wide distribution of like skill levels. So I want to make that clear that we are literally not on the same level at all. And I think that's why I'm asking him these questions so we can get his point of view on a lot of this stuff. Um, also he has a YouTube channel, a Twitch channel where you can
- 0:44
ask him questions uh on DSA and stuff like that. Maybe even get a little bit of uh dating advice if uh that's what you're into. Uh but not that any of my viewers would need dating advice, of course, but if you're interested in that. But yeah, I just wanted to give you a chance to like introduce yourself. Okay. Yeah. Yeah. So, uh a little bit about my background. Um, I've uh I've been programming for about like 15 years
- 1:05
or so, like professionally. But um uh my background going back to like high school. Uh I did uh I did competitive math. I was doing like AMC12 AIM. I I like won the Minnesota State Championship in math league, but then never really made it super big in like USA Mo or IMO or anything. So I was like good at math and and like it translated
- 1:26
really well to like competitive programming and stuff. Um, I did that, went to Berkeley, um, got my, uh, bachelor's in math. I didn't do computer science. Um, actually went back to Minnesota and became an insurance actuary. Um, so I did I was actually working with like Excel files and Excel VBA and like there's a little bit of programming in
- 1:47
that, but so so I did some of that. It was kind of a bad fit because like it's a lot of that job. insurance actu. I mean, they say it's like a good job and all that, but like the insurance actuary, it's it's a whole lot of reading Excel files and finding the things that are like a little bit off. And I was like, it's it's not really my thing. And then I started uh after that
- 2:09
I started like um learning programming on my own. Like I had a nextoor neighbor um was my my best friend's dad. uh he was a longtime programmer for Loheed Martin and he was like you know you should you should learn this new programming language called Python. Uh so I was like okay um I'll I'll take a look. I learned Python and I was like I
- 2:31
mean it just kind of went from there. I ended up like building my own I I was really into like game development. Um I was really into like the Starcraft 1 custom map interf like I built a whole Tetris emulator in Starcraft 1. But yeah, I I was really into that stuff and so I kind of built my own games and stuff. Used that as kind of demo projects to get my
- 2:52
first software engineering job which was for an insurance software company. They probably like the actuarial background but in reality this was like a different time like a very different time when Yeah. I I I realize how lucky I had it back then because um they were just picking up anybody off the street basically uh who was interested in
- 3:13
stuff. Now nowadays it's it's like rough for new grads and we could we could probably get into that later but like um that's I I ended up applying for that job, got my first software engineering job there um insurance software and then I built my own I I ended up building an iOS game on the side. Um it didn't do that well. It made like 10 bucks on the on the on the app store. Uh but it got
- 3:34
me an interview with um a social game company out in San Francisco and I've I've kind of been out here ever since. Uh, I did iOS for like four years. Um, and then left that job. I built another game. I built a web game that actually did really well. A bunch of influencers played it. It made a total of about $170,000
- 3:56
uh lifetime revenue. But anyway, I built that in ReactJS and so I used that as a demo project to get a uh front-end software engineering job and I've kind of been doing that ever since. And how old did you say you were when you like first learned to program? first learn to program. See that it's it's a difficult question to answer. Um because
- 4:17
uh would you consider being on the bus in like seventh grade on a TI83 calculator learning basic or whether it was my XLVBA experience from being an actuary or whether it was the Starcraft stuff. The Starcraft trigger language was was pretty intense. Um but in terms of like formal programming languages,
- 4:38
you know, C++, Python and stuff, I would say somewhere around 23 24 kind of a late bloomer there. Yeah. So you didn't have like the traditional like programming background, but um even like in terms of like competitive programming, but you see like a lot of people they've been doing it since they were like 12 years old or something like that. And uh and I think you also said you moved from math uh
- 4:58
over to programming and that translated well. Would you say it's easier to go from like math to programming like versus the other way around? Oh, math to programming versus the other way around. Um, I don't know too many people who go the other way around. Um, but I know a lot of people like uh a lot of people I I knew from
- 5:18
Math League ended up do at least trying programming for a little bit. Um, uh, yeah, like a bunch of X-fang people because like the the skill set from like competitive math translates really really well. Um, I I I remember some of the the big names that I saw back in high school doing like IMO and stuff like that and then I I start to see them
- 5:38
like doing the competitive programming stuff and being being that I'm like, okay, there there's a link there that's there. And and also uh in terms of like your background, um, you didn't mention it, but you are and I'm going to put this in the title, that's why I'm going to ask you. you are ex Google, right? So, you you did work at the big uh company Google and and you did that like you said without having the like the typical
- 6:00
CS background or whatever. And I think that's actually pretty common for a lot of people who worked at Google and other tech companies. Yep. Um yeah, I I worked at Google. I was uh I was part of YouTube uh for a couple years. They they had it the the specific team I was on was the mobile web search team. So like they they have like hyper specific teams. So like on a
- 6:21
mobile device but not on the app but on a browser window uh the search bar and the autocomplete results that has a whole team behind it. Um so I was proud of that. So I guess specifically your like competitive programming background. I'm interested a little bit about like your journey and specifically like how how many problems have you solved and
- 6:42
like what is your competitive programming background because obviously like you're good at it but what does that mean? Okay. Um, number of problems solved. I've I've probably I I I had like two different accounts. Um, trying to take out the intersection of the two. I'd say somewhere between 2,000 3,000 something like that. Um, but I like like I say, I
- 7:04
mean to to like people who show up in my stream or like people in general, it's like it's not about the number of problems you've solved. It's about how difficult they are relative to your current skill level. uh you like if if you're at like the level where you can do hards, don't just clear out easys just because um just just for the problem count, right? Um
- 7:25
uh so there's that. Um and uh I am on lead code. I've done uh in terms of like contest rating um that one I mean contest rating has like kind of it it like peaked somewhere uh what was it maybe about a couple years ago and then AI started taking over and then
- 7:46
like they that that that's a whole another topic. So um I wouldn't consider myself like an elite competitive programmer anymore. On the other hand, um I have done a bunch of problems and I still like on stream and and and am able to like break take a problem, break it down and kind of explain it for people and I still I still do the contest every week. Uh did it last week uh or sorry
- 8:08
yesterday. Yeah. And actually uh a little bit later I actually want to get into that because I want to like I really want to like dissect like somebody's like thought process when they're like doing these things because I think it's different for everybody and that's kind of the side that like a lot of people don't see. they'll see like a solution and everybody has their own way of taking a solution, understanding it in a way that like makes sense to them. Like a lot of
- 8:30
people will watch like a video, but even the videos don't really capture, I think, what somebody's actually doing when they're solving a problem. Because even in my case, if I'm explaining a problem, most of the time that's actually not the way I solve it because it's kind of like if I'm explaining like arithmetic, like adding, addition, or whatever, nobody's actually like
- 8:50
carrying like certain things in their head. Like you take these certain like I think at least most people take like mental shortcuts without like realizing it. And I would almost say that like that's like a very very necessary part. And I think that's why people see like a really hard problem and they're like, "Holy crap, like that's insane. I can't even imagine how somebody could solve something like that. And it's in my
- 9:11
opinion analogous to like an instrument. Like I can't imagine how somebody could play like the piano so quickly. But like eventually over time you kind of build that like muscle memory. And I think uh you could use so many analogies even uh like CPUs. They have uh if I recall correctly, they have like dedicated circuits for doing certain like operations because they're so common.
- 9:31
And I think there's like the inverse square or something that's like really really common in I think game development or other like graphics engines or whatever and I think CPUs if I'm correct maybe I'm wrong but I think they have like a dedicated circuit specifically to calculate like the inverse square root because it's so common and I think usually that'll happen with people as well and I think that's what you kind of alluded to where
- 9:51
you you solve problems but you solve problems that are difficult and then eventually you just keep doing that you build up the like the circuits in your brain or whatever that allow you to like recognize the patterns and solve problems quickly. Um, what do you kind of think about that like uh in your experience like is that kind of correct or would you describe it a different way? Yeah, I think uh the idea of of
- 10:13
having like uh specific shortcuts like you see a pattern and you're like bam segment tree or like uh bam uh like a monotonic stack, you know, something like that. um you see a problem like the way it's laid out, you like kind of know how it's going to you kind of know how the story is going to end. So yeah, you definitely've got uh like mental
- 10:34
shortcuts like that. And those are only developed through experience. Um you don't you don't really build it up by reading about it. You you you build it up by doing lots of problems, going through the weeds, uh struggling with it, trying a bunch of other stuff that doesn't work. And then I guess on that topic, you mentioned that a lot of people like like one mistake that some
- 10:54
people make is that they'll solve problems that aren't like appropriate for like their difficulty level or something that isn't actually giving them any like benefit. Uh are there other things that you see people commonly like doing wrong? People are doing problems that are like uh out like far outside their difficulty, like if they're at a medium level, they're doing hard questions, things like that. Um
- 11:14
what other things do I see people doing wrong? Um well, one one of the big ones is like giving up too quickly or like letting AI like especially nowadays letting AI just do everything so they don't learn anything. Uh there are ways you can use AI uh nowadays um uh where you can you can ask it to explain like just give me a small hint and then if if
- 11:36
you're like stuck for like 15 minutes or so, you ask for a small hint and then see if that like mentally like unblocks you and then try it again. And uh and if if it doesn't work, get another small hint, just enough to get you past the rest of the way. So I guess when you were solving problems, what exactly did that look
- 11:56
like? Because this is what I think a mistake people make as well. Like what does it mean to solve a problem? Does that mean okay, you couldn't solve it? You looked at the solution and then you tried to understand the solution and maybe you did kind of have like a shallow understanding and then you got accepted on leak code or whatever. I think I think that's what people look at, right? Okay, I got accepted. You know, it's there's a statistic right
- 12:16
there that means I solved problems. Is that what it means to solve a problem or does it mean that okay, you had to look at the solution and then you solve the problem and then eventually maybe you come back to that problem a week later and try to solve it without looking at the solution. Does that qualify as a solved problem or like something else? Like what does it actually mean to to practice or to solve a problem? Uh, for
- 12:36
the record, I never go back to previous problems unless unless maybe somebody on stream requests that I solve that problem and I've previously solved it, but I never look back. Um, I know a lot of people do that. Um, but if you if you derive value from it, great. A lot of people use like to use like the Anky flashcard approach where like uh you
- 12:58
you'll you'll have a problem and then you you'll solve it and then it'll just show up in another flash card again that that very same problem. So you have to solve it again. So like the spaced repetition thing. Um I personally don't find any value in repeating a problem. Um but uh to answer your question, what does it mean to actually solve a
- 13:18
problem? Well, well, for one, the the easy way is like if you already knew how to solve the problem, like you you type out everything and you get you get the AC done. I mean, you solve it that way. But if you didn't know how to solve the problem, then you have to figure out like what uh you you have to think through it. Um or like if if you didn't
- 13:39
already know how to solve the problem, you have to think through it and then uh go through like all of your toolbox of uh techniques and tools or whatever. And then I mean if you solve it from that toolbox like it didn't immediately come to mind like that you knew how to solve it but uh you dug through your toolbox and you picked out a couple tools and they happen to work great then you
- 14:00
solved it that way. um that's a learning experience because like you've learned that now later on in the future if you see a similar problem that can be part of your instant recognition method. But um if you don't if you dug through your toolbox, you couldn't find it, you take a you can take a hint um and then add that to your toolbox and then solve it.
- 14:22
Or you can take two hints or three hints or whatever. Um uh but if you need the entire you know if if you've completely given up you need the entire thing um you you read the entire solution uh one thing you you can still do to to salvage some kind of learning out of that is um reading the solution and either trying to type it up
- 14:42
yourself or reading the code and trying to copy over the code like just read the code try to memorize roughly what it does and then try to type it out uh from memory. uh so that even if you have to look up the solution um even if you have to look up the whole solution you can get some kind of small learning out of it and uh the more of those little
- 15:04
tidbits of you have to mentally fill in the gap you can get out of a problem the better. So like in terms of what qualifies as a solve, yes, technically it's just get an AC, but there are different levels of what you can get out of the problem based on how you approach it, right? Yeah, I think that makes a lot of sense. And now I'm curious about what
- 15:26
that looked like for you for the problems you solved. Um, for example, like uh in my case, like if I solved a problem, like in my experience, sometimes I got to problems that like I didn't have a ghost of a chance of getting it right. like I didn't know what the hell a segment tree was. Maybe I could have derived it. Maybe I could have like, you know, you could say whatever. If maybe if I was a math
- 15:46
genius, I could have done it. Even if I could have probably would have taken me hours and if it took me like, you know, an entire day of just banging my head against the wall. Um, I probably would have gotten a lot out of it, but also maybe that's indicative of like the question was too difficult. So I'm curious like in your experience and and to be honest that actually was the case a lot of my time like I I remember
- 16:07
looking at a problem and like I spent hours and hours even sometimes after looking at the solution I spent hours trying to understand it. So I'm curious in your experience like what did that look like? What was like the longest it took you to like maybe fully understand a problem or to for you to be satisfied with like okay I kind of get what's going on and maybe I couldn't do it initially but now I do. Oh oh oh the the longest it took me.
- 16:28
Okay. Um there was a problem on this online actually my first online judge wasn't lead code it was this thing called sphere online judge um there was this problem that okay I was feeling real confident one day and then I went after a problem that um so the way sphere online judge works is they have they have the problem and they won't let
- 16:49
you look at solutions uh like other people's like previous solutions and stuff. Uh so like if you don't get it right like you're you're like stuck stuck. Um but like uh this this problem I think had like two people in in the entirety of Sphere online judges existence that had solved it before. Um
- 17:12
actually I I can give you the quote. It's it's called MEPerm Perm. Um, and so you can see a bunch of like attempts from 2010 uh from from a guy for like I I tried that problem for a straight month. I tried over optimizing like my C++ code. Um, and I was just
- 17:32
like not getting anywhere. Um, but then later on a code forces GM showed up in my chat and said um told me told me roughly what's up. Um, and uh I don't know. Should I should I like spoil it? Uh yeah, go ahead. Okay. Okay. So it it turned out to be an FFT problem. So that's an example of like I I did I did not know how to use
- 17:54
FFT in a competitive programming environment. Yeah. Uh so that that's an example where I I uh I tried I tried so so what what what are the lyrics? Oh my god. Um but anyway, I got so far. I tried so hard, but but in the end it was FFT. Um and I I just didn't know how to use that technique. If I were to do
- 18:15
things again from the start uh on that problem, I would uh I would attempt that problem for like maybe a good half an hour to an hour um before like looking up a hint because um one I mean it's it's I mean okay mathematicians are a little bit sadistic or like masochistic that that's the word right. Um they they
- 18:36
can they can tolerate a lot of pain and they they like they like the mental pain of like trying to solve a problem. Yeah. um they they they like the mental pain of trying to solve a problem. And so they will be attracted to very difficult problems that look like they're out of reach and like I I think I could get that. I I really think I got a shot at
- 18:57
that. Okay, maybe use this technique. Maybe use this other technique. And then you just keep working on it, working on it, working on it, and all of a sudden like six hours have gone by and you're like, I really haven't gotten anywhere on this problem, have I? Um but yeah, no it was like that with me in that problem for like a whole month. Oh yeah, previously before that um before that GM
- 19:18
just came in and randomly told me it was an FFT problem. Uh I had given it to another another uh another code forces GM. Um so like there's this guy Luen Gun who ran like a a competition at Stanford or something. I did this competition uh won that thing. It was like a it was like a tiny thing. It wasn't really a big deal. Then afterward, I like asked
- 19:38
him like, "Hey, there's this really difficult problem I don't know how to solve. I can't see the solutions. Can you take a crack at it? Here's my existing code." He took a crack at it for granted, he he I don't think he spent like that long um like trying to crack that problem, but like he couldn't figure it out either. So that if if like a code forces red is not figuring that
- 20:00
thing out, it's like, "All right, dude." Yeah. I had like an exact same kind of experience because I think in terms of like what people can do wrong. Uh people like to anybody watching this, especially if like you're a beginner, you're definitely going to do something wrong. Like don't look for like the perfect way to do it. Sometimes you're going to like spend too much time. Sometimes you're going to not spend enough time and just end up memorizing
- 20:20
the solution. And I think it's kind of just about trying to find like a balance and like what works for you. But I would say my biggest problem was that I wasn't willing to like look at a solution or I wasn't willing to do that because I felt like damn like if I don't figure it out myself that I'm just memorizing a formula. I'm just like I have to like derive it. I have to like prove it. I have to do this and and for some
- 20:41
problems you can kind of get close like like I think like some problems like alien dictionary it's really hard for a beginner but like it's pretty intuitive. There's nothing super crazy as long as you know like the core graph algorithms behind it. But there are some things at least for me like the monotonic stack and I wasn't solving like an easy monotonic stack problem. It was like one of the harder ones but I just could not
- 21:02
like I just felt like it was possible like okay it seems like it's possible that there's a linear solution to this but I can't figure out what the it is and I have never heard of the monotonic stack. I don't know to use it in that way. It's such an unintuitive thing for me even to this day. I think those are like something about that just knowing that like the ordering of a stack can help you solve a problem unless it's
- 21:23
like a really trivial one. It's just so like unintuitive. But once you know the core idea like you can kind of apply it and you know to think of it and you're just like okay I don't really know how to solve this problem. Does a monotonic stack work? you just try to like force it in and you find okay there is a way to to do it and yeah like it's just so
- 21:44
frustrating but like you again like if you're just preparing for interviews and trying to do it in a time efficient way like you kind of have to like find the balance somewhere in there and I think the people who do it best are the people willing to like balance that. Yeah. I feel like for time pressure the the biggest thing for time pressure for me um I I feel like you've got to do like you've got to do the lead code
- 22:04
contests. Um, I you could have a substitute in the sense that you take a problem and you like set yourself a timer of 20 to 30 minutes or something. Uh but it's really not the same as like being in kind of a global contest where everybody else is kind of doing it under the same time limits and okay prior to
- 22:25
AI like being able to solve everything like you could see the leaderboards you could like see how quickly each person solved each thing and like you could al you could also read their solutions to see how like uh one of the one of the most helpful things for me at least for the contests as far as contests are concerned I mean by the time I got good at contests like passing lead code
- 22:46
interviews was like essentially trivial. But like for um for the purposes of getting better at contests, one of the uh one of the most useful things I found was looking at a top competitor, how they wrote their code, how they structured things, what kind of templates they used. Um yeah. Yeah, I completely agree with that. Like the contests is and I haven't
- 23:07
really done many contests before, but I think that kind of like simulates the like pressure of like a real interview. Um, on that note, I'm kind of curious, what do you think the role of like talent versus practice plays? Obviously, like most people aren't going to be like world class uh uh what's his name? Tourist or something like the
- 23:29
Yeah. Uh, yeah. Yeah. Like probably most people aren't going to get there unless they're like doing it out of the womb or whatever. But like from a to a reasonable extent, like what's the difference between like talent versus practice? Okay. uh for the purposes of competitive programming or for the purposes of like getting a job in software engineering. I would say mostly getting a job uh but
- 23:50
you can also touch on like the competitive programming aspect. Okay. Yeah. For for getting a job for software engineering um it's it's just practice. Um, I I think most people who are, you know, good enough to get and keep a software engineering job. Um, that level of intelligence, uh, should be good enough to be able to grind at
- 24:11
lead code. Just do lots of problems. Um, if you get stuck, you know, um, if if you get stuck, well, first dig through your toolkit, then like um, then use AI to like maybe give you like a little little hints here and there or watch watch Need Codes videos um on on uh, you you still do the videos on like every
- 24:32
solving every problem, right? Uh, sometimes I take breaks and stuff. So, yeah, but sometimes you take breaks. All right. All right. But but if there's a problem that need code has to solve, you can watch that video, too. He he gives really good explanations. Um but yeah um uh practice is uh absolutely key. Uh I know there are a lot of uh there are a lot of juniors and new grads who stop
- 24:52
into my stream like they ask me to do like resume reviews or like ask me like hey I'm having trouble trying to get a software engineering job. What do I need to do? I ask them questions. Actually, one one happened yesterday where a guy was getting like uh I think about he had about 10 online assessments, but he was only passing a little over half of them.
- 25:12
Um and I was like, at that point, right, your resume is probably good enough because it's attracting some attention. But at that point, you've got to like buckle down and practice like at least like couple hours a day. try some lead code mediums, maybe a few lead code hards, um to to like kind of kind of get that get that uh six out of 10 to like a
- 25:33
10 out of 10. Um because um I feel like that's the part that's most under your control. um right uh being able to practice lead code and solve those because unlike other parts of a uh a technical assessment, lead code is the only one that'll tell you yes or no, accepted or wrong answer TLE,
- 25:54
you know. Yeah. Um so given that you get that kind of binary feedback, I feel like that's that's the part that's most under your control. Yeah, I I definitely agree with that. uh in terms of like the role of practice and we kind of like talked about this earlier. How much of a difference because I I hear this question a lot which is that like I feel like I am practicing. I feel like I solved all
- 26:14
these problems. I spent you know all this time uh like what am I doing wrong and like I would say that boils down to practice versus like deliberate practice. And we kind of like touched on that which is like solving problems that are actually like you know challenging for you and you're actually learning something new and also doing it the right way in terms of like getting hints
- 26:35
and understanding a solution and stuff. Would would you say like that's generally true in like your experience? And I think maybe somebody like you who's probably just genuinely curious and genuinely interested in in these types of things is probably just going to naturally do it the right way. Whereas somebody who really really hates this just, you know, without even trying, they're just going to take the shortcut of naturally trying to like
- 26:56
memorize a solution because they don't actually care, you know, like why does this algorithm work or whatnot? So would you say that like the practice versus like deliberate practice is something that people make a mistake on or do you think I'm like not right about that? Okay. Practice versus deliberate practice. I can you clarify what you mean by deliberate practice again? Yeah, I guess in terms of like somebody who
- 27:18
maybe they're like practicing in the wrong way, which could be a dozen different things where where it's like solving problems that are just too easy and you're not really learning something or just looking at a solution and memorizing it or something like that. You can learn a little bit that way, but it's it's wildly inefficient. Um I I think the two main tracks of learning
- 27:38
lead code um that uh that I've heard other people doing and then I myself have done done one of these um the the track of just doing random problems at or a little bit above your skill level or the other track being taking each of the different topics and then if there's a topic you want to learn just doing a
- 28:00
bunch of problems in that. Um, one of the main I I prefer the the uh the just do random pro problems approach. Um, because uh, one I like to deal with the uncertainty. It's like you're you're being given a problem. It's like it's it's it's kind of a dog fight for me. I'm a little bit of a competitive person. I'm like, "All right, come at me with whatever you got. Uh, I don't I
- 28:20
don't know what techniques I got to use. I've got to think on the fly." I mean, that's that's genuinely exciting to me. I mean, just telling you that gets me all excited, man. I I got to do problem after this. Um but yeah anyway um but yeah there there's there's that line of thinking then the the line of thinking where you do practice based on
- 28:41
the different topics. Uh the one problem with that I mean that that's great for like hammering home a particular topic. Um on the other hand when you get a problem in that topic you already kind of have like the horse blinders on. you already are like kind of laser focused in on a specific topic. So, you're not
- 29:02
digging through that toolbox. And that's that's kind of an underrated part of learning lead code uh learning how to do lead code problems that beginners just don't really know or understand. It's that you've got a toolbox. It's it's not only having a lot of tools in the toolbox, knowing what what the right
- 29:23
tool to use is, but also digging through that toolbox to find stuff like rip out that monotonic stack or that Fenwick tree or whatever um uh from the bottom of that toolbox if you haven't used it in a while, you know. Um and uh yeah, that that whole process is like a part of it. Um so um I guess to answer the
- 29:44
question of you know taking shortcuts versus uh yeah taking shortcuts or right like not really doing things the right way. You can learn a little bit um I I think what oh right uh to also answer one of the previous questions you had about like what things do junior engineers or like people who are learning lead code for the first time do wrong. Um, one of the big ones is
- 30:07
passively consuming lead code as um, I think you touched on this in your video too, right? Um, right. Uh, passively consuming lead code content and thinking they're learning a whole lot. Uh, you I mean it's it's it's a very trivial amount you're getting by osmosis. You really have to you really have to do the
- 30:27
problems. I guess one question in terms of like the context of your experience which we didn't like talk about too much but you have like quite a lot of experience like in the professional world in development and I think you're no longer at Google you're at a different company right now. Uh in terms of like everything in your experience like has DSA been useless and if so how
- 30:50
useless or how useful and like how do you think about that in terms of like what you got out of doing this? Okay. Like my philosophy on like what lead code does for you as a programmer. There are exactly two benefits um to doing lead code um like at somebody who's good at lead code versus somebody who's not. The first benefit is that when they run
- 31:12
into a uh a problem that requires kind of an algorithmic solution like maybe it's an n squed type problem but then they find an o sol they're more likely to find the o solution or like introduce memorization at the right spot like their head space is already like kind of there and so like if if you have somebody who's less good at lead code um
- 31:34
they they might write a bad solution there and then if that becomes a hot path later. Sometime later down the line, this affects the business operations. Somebody has to diagnose the problem, pinpoint it right back to that that piece of code, and then a senior engineer has to come in and then like change it um so that it's better. Um so it introduces like having somebody who
- 31:56
already has algorithmic complexity in the back of their mind um just makes that whole process a lot easier. You don't run into these landmines all over your code. you're going to have landmines in your codebase anyway. Any sufficiently large codebase is going to have landmines, but you get a fewer of the algorithmic variety if you've got people who are good at lead code working
- 32:17
on your stuff. Uh the other thing is because lead code beats you down so hard with a okay, you got you got you got one test case wrong, you got the last test case wrong, wrong answer, zero points, you get absolutely no credit, right? Um, so based on that and the people who are good at lead code have been beaten by
- 32:39
that stick so often that they uh they they naturally kind of catch their own edge cases when they're writing code. Yeah, I 100% agree. Yeah. Mhm. Yeah. Th those are like the two things. But like does it make you a much better programmer in whatever framework you're working on or what I mean? Does
- 33:00
it make you a better React engineer? Does it make you a a better golang injury? I I I really don't know. I I can't really speak to that, but those are the two really big ones that I see. Yeah, I 100% agree with that, especially the like edge case aspect of it because uh I think that's like one of the things that can so easily be applied to so many different things because it's
- 33:22
not just like if you're programming then you're going to think of like the unit tests that like have to be tested whether you implement the unit tests or not. you still have to like think about like the unexpected behavior like the zeros, the whatever empty arrays and sometimes it's not even that trivial. Like you really have to like even just be aware that something like that's
- 33:42
possible. You wrote code, but you're pretty sure that there's probably some edge cases that you're missing. You might not know what they are, but you even have that like tendency to just know that like intuitively something might be missing. And in my experience, um, for me at least, I would say it helped me, I I guess just stay like familiar with like programming style of
- 34:02
thinking cuz I didn't like I mostly have stopped doing math over the last like decade. And um, most of the time like math isn't going to be directly applicable if you're doing like full stat crud development. But I do think like the muscle memory of like typing something actually out which I don't know about you but when I was working at Google a lot of it wasn't like I felt
- 34:23
like I was kind of just a copy and paste monkey like if I if I didn't know what to do or like how to how exactly to implement something it was like okay in open source it's like you go to Stack Overflow or nowadays like ChatgBT at Google for me it was just like go through the code search go through the code base find somebody who did something similar who used this library copy and paste their snippet make some edits and like I I felt like I lost a
- 34:44
lot of like at least what I was doing. Maybe you were doing more interesting things or for me like I I felt like I wasn't really thinking that much for a lot of the stuff that was going on. It was more just like reading code rather than writing it. Yep. Yeah, you're absolutely right. And your experience completely mirrors mine. That's that's why I left after two years. I was like that that that kind of programmer where you're just uh most of
- 35:05
your work is just going around digging around to like uh numerous teams trying to find out who worked on something similar, copy pasting that code, throwing it in a feature flag and then going through all the bureaucratic red tape to get in and then all the all the failing unit tests that had nothing to do your with your code and oh my god uh ju just thinking about it gives me PTSD.
- 35:27
Um that's funny. Yeah. No, that's that's why I went back to startup land and uh that's kind of why where I've been ever since. So, I had one like actual coding question. So, I went through your leak code profile and I stalked you and I saw that you solved and this this was actually a relatively easy one and I think you solved it during the contest. So, it was maximum score of a split
- 35:50
string and I was looking at your code and so this is a problem I think that this is not what I would qualify as a crackhead problem. I think most people can reasonably quickly get to a level of leak code where they can solve this problem, but everybody solves it differently and um even like probably the best people will have like a different thought process and I really
- 36:10
want to know like exactly what was your thought process because if I explained this video this solution in a video I would really go step by step and say okay well like you know here's some like things I notice about the problem here's some observations I make and so knowing that We could try this. Okay, if we try that, it's going to be a little bit it's not going to be so efficient. And then
- 36:32
so we try it the other way and that one is efficient. But if I'm actually solving this problem, especially trying to solve it as quickly as I can, there's there's a few things I'm just going to like laser point on, which is that okay, so this is a array problem. like if we were like doing the simulation of what the problem is asking us and you know recalculating
- 36:53
uh maybe I'll give some background on the problem when I upload this video but recalculating the prefix sum every single time etc. It's probably going to be n squ. Okay. Well, like that's kind of the benchmark. Can we do better? Very quickly, I don't know if it technically qualifies as a greedy problem or just a prefix some problem, but like very quickly, it's very simple to to realize
- 37:14
that there's a shortcut that you can get the minimum and like if you have the prefix sum and you do it like in an intuitive way, you can solve it in linear time. And like maybe and there's never going to be a better way than that. And if there's a worse way than that, I don't really care about it. I'm just going to laser point on that solution and just try to implement it and then figure out the code and I want to know like when you solve this problem
- 37:35
what exactly did you think and how how did you get to your code? Okay. Uh okay as as I am getting to my Okay. So with the maximum score of a split let me know. Um this one this one took like I think a couple minutes or something. So let me let me go back and like read through it. Um okay so you are
- 37:56
given an integer array nums of length n I okay prefix sum suffix min I was okay the first thing I thought was like both of these are calcul you can you can calculate in linear time and uh how do I get them both on and then the score of a split is I didn't even read the part about the score of a split I skipped over that uh ran tests and it it it
- 38:18
failed and I was like oh wait the score isn't the sum it's the subtraction so I didn't even read that part of it. Um, return an integer denoting the maximum score over all valid split indices. Okay. Um, so like an integer over all valid split indices, you want the maximum amount. So like the prefix sum
- 38:38
in order to get the well the first part, the prefix sum, you have to make the prefix sum array. And then to get this suffix min thing, I figured you could just uh so like a after I read that maximum score over all valid split indices. Um at so at first before I read that statement, I thought maybe you had to find the score over all split
- 39:00
indices, but this is just the maximum overall valid. So um it's it's a little bit easier. U the prefix sum, you have to build up the prefix sum array for this anyway. Um so like by default, you have to build that. But for the suffix min, the minimum value from the right, um, I figured, okay, once you've built out your prefix summary, you you take
- 39:20
your your current uh your current suffix minimum and then just roll it right to left and you you you have to store a singular value and then you compare it against that. Right. So that's how I would solve that problem. Um, right. Does that make sense? Yeah, exactly. And so when you thought about it, like did you think of it in terms of like the time complexity or like okay like when you saw that there's
- 39:41
a linear solution often linear is the best but like you probably didn't even think that like is there something better than linear, right? You you don't need it because uh okay um uh on on lead code if you see 10 to the 5th uh n login or better will do it, right? Even even if you had to for whatever reason sort it, you're you're fine. Okay. So, so you used the constraints as
- 40:03
like part of your you actually read the constraints or you didn't. Oh, for this one. Did I read the constraints for the Yes, I did. I read the constraints um just to see. Yeah, I don't remember if I read the constraints for this one, but I I probably did. Okay. Um but it it it wouldn't have mattered either way, right? And so if I was going to make a
- 40:24
video, I I want to explain it like step by step for people because often like if you say like, okay, I intuitively just kind of knew this because of like, okay, I've solved similar problems or like maybe a single statement and that kind of intuitively just tells me like something about what the solution is going to be. Often for a lot of people, like that's like too far of a jump. They really need to see like the exact like calculations that were made to like get
- 40:45
to this point. um and it's really useful I think for like learning and stuff but uh for me at least like if I'm actually just trying to solve problems as quickly as I can I really skip a lot of those like one thing I noticed about this problem is that like okay so you solved it by computing the prefix sums and then going in reverse order to just kind of track the suffix men uh but but it could
- 41:07
have been done the other way right we could have just computed I think the suffix men's and then just kept and then scanned from left to right to keep uh to maintain whatever the prefix men were prefix whatever sum is. Um but like in a real problem like if I'm solving I'm not going to go through all the different ways once I identify a solution. And so um I I guess I just wanted to mention that because um I think people don't
- 41:29
really get to see that like people don't see what exactly is like going on in somebody's head and whatever like mental shortcuts they're taking. And so I wanted to just kind of like get your thoughts on that or if you even have like a different problem that was like more difficult or something that's fresh in your mind where you kind of want to like elaborate on like some of the mental shortcuts that you're actually taking whether you realize it or not um like in the moment. But yeah.
- 41:50
Um I guess in terms of mental shortcuts, well this this was actually from the from the contest from yesterday. This was the Q1. Uh the Q4 uh was like a a complete mental shortcut. Uh the Q4, let's pull it up. Okay. Uh weekly contest 482. Oh, uh somebody in chat asked about those
- 42:11
mental shortcuts. Any advice not to take them during interviews? You should take them during interviews because it it it helps you solve them quicker. Um but yeah, um number of balanced integers in a range. Let me like send it over. Uh that guy right there. Um and I'll send you my submission then. So um number of
- 42:31
balanced integers in a range. Uh so you're given two integers low and high. Uh integers called balanced if it satisfies both of the following conditions. One it contains at least two digits and two the sum of the digits at even positions is equal to the sum of the digits at odd positions. Um, immediately when I saw that, I was like I knew how to do it in in terms of one,
- 42:53
it's going to be a digit DP. Two, it's going to be a um do the range from zero to high minus the range from zero to low minus one. And uh and I knew the states for the digit DP. It would be like index um whether you're doing the high or the low uh whether the digit at the digit was limited or not because if you picked a lower digit earlier um the the future
- 43:16
digits are not limited. You can pick the zero through nine um and uh uh what was the uh the other one? Oh yeah the the other state is the difference between the even and odd um indices. uh the difference between the ind the digits uh the sum of the digits and on the even and odd indices so far um and then at the very
- 43:37
end to check whether it's a valid combination you have to check that that difference is zero right okay yeah so it it's a digp like immediately figured that that's a metal shortcut to me because I' I'd seen so many problems like this before I was like yeah that's that's how you do it um I cannot believe they would put this as a Q4 um right um but Yeah,
- 43:59
it's uh top down. Um yeah, the Python ad cache uh decorator is is pretty good for like top downs. Um sometimes lead codes constraints will screw you over there. Um and you need to do a uh deep you you need to do like a cache clear on the function. Sometimes that trick will help. It's it's all these little things
- 44:20
you find out when you get like like 15 memory limit exceeded and you don't know how to solve the thing. Right. Right. Um, so sometimes that helps. And if that doesn't work, yeah, you might have to write it, rewrite it bottom up. Um, it's it's just I don't know. I I have a habit of doing top down, but um yeah, bottom up is perfectly valid as well. I guess on that point for me, I would say like
- 44:42
DP and for most people probably DP is like one of the hard uh patterns and the top down is generally I think more intuitive for me. Like I would describe like the bottom up solutions really as like a math problem like I I don't know I I think there is like a discrete math concept that like DP is based on. I could be wrong. Isn't it like induction or something like that?
- 45:02
Oh yeah it's uh yeah DP is basically strong induction. Yeah. Uh where you strong induction is where you use the previous statements to prove the next one. And so that that is that is effectively what DP is. Yeah. And for me and I guess it comes with practice because like you can definitely improve like if I'm doing like a one-dimensional like DB problem
- 45:23
like the the space is you can kind of visualize the space and whether you're going left to right or right to left once you build up the equation the relation then it's it pretty much becomes intuitive. The two dimensional ones to this day I still solve them. Some people get mad in the comments. I still solve it like with the the two dimensional grid. I fill it up from
- 45:44
right to left, bottom to up. And I do that because it's more usually more consistent with like the top down solution. I could probably do it the other direction. Like eventually with enough practice, maybe that one way would become more intuitive to me. But it's like no matter how you do it, maybe
- 46:04
I just haven't figured out the right way to think about DP problems. But I feel like no matter how you do it, it's just confusing because like what okay when you're solving let's say a bottomup DP problem, how do you do it? And what is actually like what are the a few like bullet points in your head that you're actually going through cuz because there's like okay so how do you populate
- 46:24
the dimensions? Okay, so and then so for an individual square what does it depend on? It depends on like it's right neighbor, it's whatever neighbors, right? And so you have to think about the ordering, you have to think about like the geometry, what the equation actually is, what the edge cases are, like what the value itself even means and and if you have like three dimensions, that's even harder
- 46:45
because then it's like visualize that. Yeah. So, so what what do you think? Well, I I think about like which values do I need to calculate first and which which values depend on them, right? So you the ones you need to calculate first, you calculate those first and then like then just run the calculation run the loops in that order. Um that
- 47:05
that's the way I think about it. And like sometimes it doesn't even matter whether you do um whether you do that right to left, bottom up or like the top top to bottom, left to right. Yeah. Um sometimes it doesn't matter but yeah. Yeah. I just I just think about like which is the first one I need to calculate. Yeah. For me, for some problems, I find
- 47:27
that it's kind of again, I always just end up going back to the thought process of like the recursive solution because it's I use the word like base case because like you said, like what's the first what's the starting point? What does it actually mean? What's the next one? How do you compute it? What's the relationship? What's like the directions? And yeah, and do you do you
- 47:47
visualize it? I guess like do you think about like the grid or do you just see it in terms of code and like the whatever grid like you're using and like the indices of that grid. Sometimes I think of it in terms of the grid sometimes I think about it in terms of uh it really depends on the problem. Yeah. Right. Do you do you have like trouble with like the the DP style thinking or do you think your math background like
- 48:08
helps you when it comes to that? I think I'm like okay at DPS. Um uh in terms of bottom up uh I think I'm a little slower than average um for my skill level in terms of like like populating everything out um like like having trouble like just just kind of setting up the indices and like it it has to be this plus one this you know
- 48:30
that that sort of thing. Um but yeah uh but but like the from the top down DP with the with the ad cache handler which which is like good enough for pretty much most of the uh DP problems on uh in Python on lead code um that handler and then doing the top down it's comes pretty intuitively to me and uh like in
- 48:51
it it's it's essentially a sparse table because um yeah so you you don't have to like pre-allocate a certain amount of space um in like a DP table. Um it just takes it takes the tupil, memorizes it versus its result value and uh away you go. Yeah, I agree. Uh and sometimes for me
- 49:11
that that's kind of what makes it almost confusing going to the the bottom up solution because like you said sometimes in the top down it'll be a sparse table but obviously bottom up like you do have to do the entire ordering and then so like the translation becomes kind of confusing. Um, would you say that that that's just like a matter of practice? Like you said that the the bottom up
- 49:31
isn't like your strongest uh way to do it, but if you just had practiced it and had you just done it that way, like like is it literally just a matter of doing it that way? Because like obviously getting good at graphs isn't going to necessarily help you do bottomup DP. It's kind of a different like skill almost. Mhm. Yeah. Yeah. Just just practicing that way. If if somebody tell told like lock locked me in a room and said you're
- 49:52
not getting out until you do you do 100% of these problems uh bottom up DP way instead of top down. No ad cache handler for you buddy. Um I I' I'd probably figure it out. Um yeah. So uh somebody asked what are you guys building or side projects? like my I don't really have like me personally I don't have any side
- 50:13
projects right now so much as uh I mean I am getting really into like uh stock trading and stuff like that. So I did build um I didn't I didn't build it myself. I used Claude. Okay. Now the whole vibe coding thing, right? So Claude's just extremely good. Like you just ask it to build something. It's like build a build an interactive broker client. Um it it build an build an
- 50:36
interactive terminal um uh that'll that'll let me do this this and this and like it it just just whipped it right out. I had to change like a few small things here and there. And what's really ironic is like I do that at work now as well, right? And most of my co-workers also kind of do the same thing and I work mostly on like kind of the front end side of things. So um like building
- 50:57
out UIs and stuff. You could even give it a Figma design and it'll like do it mostly correctly. I was like, "All right, dude. What's my job now?" Yeah, that's true. Yeah, that's that's really interesting. I think um I try not to talk about this too much. I think I made a video about it like a year and a half ago, but like I don't want people to come to me and think like I'm some authority on like the future of
- 51:18
programming. I think it's just kind of interesting to watch what happens. Literally nobody knows what's going to happen. But like you said, I think not enough people I feel like have actually used the newest like Claude like Claude Opus 4.5. And it's uh it's just so like so good, but it's so fun to use it for me cuz it it takes like I imagine if I
- 51:38
was back at Google now, I wouldn't have to go copy and paste those things and find what I'm looking for. It would it would already kind of know that. It wouldn't be perfect. There would be bugs in it. But then I feel like for me, like a lot of people don't like this new way of programming where they don't get to type everything out. But for me, I I would like it because now I get to actually focus on like the logic that's going on. Maybe fixing bugs, maybe
- 51:59
deeply understanding it to make sure everything is good rather than like being a copy and paste monkey. But in terms of like what the future holds, it's uh kind of hard to say. Yeah, it does. It does feel a little bit odd like you're you're just typing stuff and then you're just waiting. Yeah, you're just waiting for it to output something. You hope it does the right thing, you know. And uh and of course,
- 52:21
if if you if you're at Google, um you're not going to be using Claude. You're you're going to be using Gemini. Like there there is no way that would get through legal. Um um I'm curious when you do interviews, is it do you just kind of like breeze through them? Do you almost like slow like if you get a problem that's really easy, do you almost slow down just to like make sure the interview can
- 52:41
interviewer can like keep pace with you or like how do you like approach them? I I go at my usual pace. I I just blow through it. Um I blow I blow through it and some sometimes it gets me into trouble because uh I I like don't explain it enough or whatever. Um but they they can't they can't give me less than the highest grade because I like solve the damn thing. So it's like Do they suspect you of like cheating
- 53:03
ever? Oh, because uh the last lead code question interview I had well I mean the last time you know I'm I'm trying to think I haven't gotten too many lead code problems to be honest so there wasn't really the opportunity. Um, but at the same time, yeah. No, I I don't feel like anybody like suspected
- 53:24
me of cheating or like disqualified me for cheating or anything, but like because I I I'll still like talk out I'll like like I was on that one stream. I like talk out what I'm doing while I'm typing it out and like it it's something that's like really I I would feel like it's kind of hard to fake. Um, Hola Hola has a question in the chat. Can you tell us more about your Amazon experience? uh
- 53:45
you had a lot of stress and anxiety I believe how you left and where you went to next. Uh yeah um I guess the short version is like I it was pretty much my first job like out of college. Um it like in hindsight like I can understand it a lot like the whole experience I can understand it a lot better in hindsight hindsight than I did at the time. Um,
- 54:08
but basically I had that job. It was really kind of a shitty team environment. Like that's like I don't think it's really debatable. Anybody on that team would have told you that. Like people were in that. It wasn't even a Slack channel. It was something else. Chime. Um, and they were just like kind of really depressed and like angry with each other and stuff. People doing uh poll requests at like 3:00 a.m. getting
- 54:28
up next morning having morning meetings. And you can see why they're pissed off. So like I don't blame them. like you didn't really sleep that night or this this entire week, did you? So, like I can kind of see why they were mad. But, uh like in hindsight, I probably could have survived that experience even if it would have been kind of crappy. Um I'm sure most of the that team did end up surviving it. Like
- 54:48
even there were like four other new grads that were hired like at the exact same time as me. Um and I'm not really generally one to like just kind of give up if something is hard. Like it sometimes will motivate you even more. Um, but uh, there was a lot of like personal stuff going on as well. Won't really get into that, but um, yeah, I was like 22 and so like just some kind
- 55:10
of like random stuff was happening. I didn't really understand it at the time. I didn't really understand it until years later. Uh, but some of it was just kind of out of my control. And I think that kind of explains why things didn't really go super well. Um, but my kind of mindset when I quit was like, okay, this is really crappy. It's 2020. the COVID
- 55:30
job market is pretty bad. Everybody just kind of laid off. And thankfully, like a year later, it kind of went in the reverse direction. Companies started hiring a lot. But I was I was just like, "Okay, I was smart enough to get this job. I don't really know what's going to happen in the future, but hopefully I'll be smart enough to get another job that's also pretty good." And I was lucky enough that like a year later, I
- 55:51
got interview at Google. In the meantime, I was just making videos on YouTube. I got an interview at Google. super nervous because I didn't really get any other interviews. I don't know why. Like I don't know why sometimes big tech companies are more willing to interview you than like smaller companies. But um yeah, and then I had prepared so much that surprisingly I wasn't even that nervous for the interview. Like I had adrenaline
- 56:12
pumping, but I also had like a lot of confidence and like I I I solved a problem that I I swear I had no business solving this problem. Um, I don't even think I finished actually writing the code for it, but I think the guy was impressed enough because it was like I think it was nested binary search, which I I don't think I'd ever seen that before. I didn't even know that was a pattern. And I I might be misremembering, but I think it was
- 56:33
nested binary search. And then on top of that, you had to do like the last optimization, which I didn't have enough time to code up, but the optimization was like then you do pre-processing with like a hashmap or something like that, and then you have to use the monotonic stack to like do it efficiently. And so you had that that part of code was nested inside of the nested binary search. And I was just like, yeah, I remember drawing on pen and paper
- 56:54
showing the guy like, "Is this what you're asking?" And the guy was like a Chinese interviewer, super thick accent. And I I don't know if I was the first guy who like actually came up with it, but the guy looked so happy. He was like, "Yeah, that's exactly right." And I was like, "Holy shit." Like, "Did I actually do it?" Yeah. And um that that has that has got to be one of the highlights of your life. like guy
- 57:16
who cannot understand you. You are giving him the I I I bring forth to you these gifts. Please accept. And he accepts. That's amazing. Yeah. Exactly. And then I talked a little bit about this in like a video I made, but it was also just like a like kind of a mind game, like a psychology game because like after that experience, I was just like you don't really know
- 57:37
how to process it. Like I'm not like a super like emotionally intelligent person. So this was like the first time in my life where I was just like academically like had just objectively just like failed and I didn't really know how to approach that. And so I kind of just like I had a lot of like I mean it's a long story but I kind of just like tried to reframe my thinking around like effort and like passion rather than
- 57:58
just like thinking of things in terms of raw intelligence cuz like I I'd lost the battle when it came to raw intelligence. So I was just like I have to think of it in another way or else I'm just going to feel like about myself. Um, yeah. What neural net nemesis says, uh, what is your favorite book? And if you had the opportunity to redo something about your life professionally, what would you
- 58:20
have done differently? Um, favorite book. Uh, it's hard to think honestly, like technical book. I haven't read too many technical books, but I really like DDIA. It's a really like commonly mentioned book. I don't think most people actually read it though because like you will often also see people complaining about the book how it's too dry too in depth when it comes to certain things which it
- 58:41
definitely is. So nowadays like if you're reading it like certain things you might be able to skip over or just kind of use chatbt to explain it uh more in depth. Um but I really like that book cuz like I said earlier uh in this that like I have kind of like the autistic mind when it comes to thinking things. I think of things in like a very like bottom up way and that like everything is like a tiny little piece and you
- 59:03
understand like the lowest level and then reconstruct it and then you can kind of understand the big picture. Like that's kind of how my mind works. So I I hate summaries. I hate like some where somebody will give you an explanation for something but it doesn't quite explain it. It it sounds good but it doesn't actually explain it. And DD DDIA generally like really explains it. and
- 59:24
if it doesn't explain something, there'll be like 20 references at the end of the chapter which will uh explain it. So, I really like that book. Um, in terms of like what I would change in my life professionally, I think things worked out pretty well. I was pretty lucky. Um, but probably just focusing on non-technical things earlier in my life, learning certain socialization skills,
- 59:45
networking skills. Any recommendations on books to learn algorithms? I mean, if you really like learning from books, you can, but probably I wouldn't. I would probably just use whatever Yeah. like tool or website or leak code or whatever. Uh cuz reading is only going to get you so far. Just try to write the code whether you
- 1:00:06
do it on pen and paper or like with a keyboard. Okay. And I guess this is the last one here. Um, in your professional life, how often do you think you get an actual dopamine hit from your work? I don't work in CS, but out of uh 10 shifts, 120 hours a month, I might only get two or three instances, a few hours worth per
- 1:00:28
month, but I feel like that makes up for the mind-numbing day-to-day work. Huh, that's a really good question, I guess. Um I I don't know if you could should call it a dopamine hit or not, but um usually I'll get like satisfaction like for me usually the hard thing is like starting
- 1:00:48
something like sitting down and starting it for the first 30 minutes or an hour or um like a context shift. But just kind of like this conversation once I kind of get going like once my brain turns on like I don't know if it's ADHD or not like I was never diagnosed but like once I get going I'm like I'm like on it's like I took like people will say are you on aderall like why are you talking so fast and it's like for me
- 1:01:08
it's like no like like I'm just like I'm wired now like I just woke up and like now I'm good and I can keep going. Uhhuh. Okay cool. Um yeah. No absolutely. Um, I know in terms of like dopamine hits from uh actual dopamine hits from my work like in engineering, I'm I'm trying to think uh from my own
- 1:01:29
experience as well. Um, it's few and far between, but yeah, for me it's worth it. But yeah, no um it was it was absolutely wonderful to talk to you and need
Description
🚀 https://neetcode.io/yt - A better way to prepare for Coding Interviews
Full episode
Spotify: https://open.spotify.com/episode/1J5q...
Youtube: • Interviews, Competitive Programming & Vibe...
Youtube Music: • NeetCode Podcast
Qiqi's Youtube: @qiqi_impact_official
Qiqi's Twitch: / qiqi_impact
🧑💼 Neetcode's LinkedIn: / navdeep-singh-3aaa14161
🐦 Neetcode's Twitter: / neetcode1
0:00 - Who is Qiqi
4:42 - Math vs Programming
6:29 - How many problems solved
8:07 - Thought Process
10:46 - Common Mistakes when Studying
21:53 - Contests
23:11 - Talent vs Practice
26:00 - Deliberate Practice
30:26 - Is Data Structures & Algorithms useless?
35:31 - Coding Thought Process
44:37 - Dynamic Programming
50:02 - Vibe Coding
52:29 - Qiqi's Interview Experiences
53:38 - Neetcode's Amazon after story
58:09 - Programming Book Recommendations
#neetcode #leetcode #python
