Interviews, Competitive Programming & Vibe Coding (w Ex-Google Competitive Programmer)

Key Takeaways

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. [laughter] 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, 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. [laughter] 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 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 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 was 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, [snorts] 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 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 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 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 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. 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 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 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 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. >> So 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. Um 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 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 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 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. 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? >> 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 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 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 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." [laughter] >> 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. 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 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. 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 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. 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 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 about 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. 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 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, 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 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 [laughter] 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 of 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. 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 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 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 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, [snorts] 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 familiar 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. Um [laughter] >> 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 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 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. Okay. 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? >> 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 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 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 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, 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 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. >> 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 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. Some 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 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 jus