Practice vs Talent, and Deliberate Practice
NNeetCodeIO@NeetCodeIO · 352K subscribers
- Views
- 31.6K
- 31,574
- Outlier
- ×3.4
- Median 9.2K
- Length
- 12:17
- Published
- Jan 6
- Tuesday
- Comments
- 71
- 949 likes
Script
How it's written
- Words
- 2,409
- Words a minute
- 196
- Reading time
- 11 min
- Segments
- 9
The hook
0:00–0:17On 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 generally Yeah.
Structure
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 generally 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?
Watch from 0:00Uh 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 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 asked 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. 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.
Watch from 1:19Yeah, 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 uh 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 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 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.
Watch from 2:48You 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 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.
Watch from 4:13Um 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
Watch from 5:33mean 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
Watch from 7:05it 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. 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.
Watch from 8:38Yeah, 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, it helped me I I guess just stay like familiar with like programming style of thinking because 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
Watch from 9:55lost 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 stuff 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 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
Watch from 11:26Full transcript
- 0:00
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 generally Yeah. Yeah. Like probably most people aren't going to get there unless they're like
- 0:20
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
- 0:41
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
- 1:01
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
- 1:21
yeah, but sometimes you take breaks. All right. All right. But but if there's a problem that need code 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,
- 1:42
"Hey, I'm having trouble trying to get a software engineering job. What do I need to do?" I asked 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
- 2:03
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,
- 2:26
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. Um so given that you get that kind of binary feedback, I feel like that's that's the
- 2:46
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
- 3:09
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 uh I think maybe somebody like you who's probably just genuinely curious
- 3:30
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 why does this algorithm work or whatnot. So would you say that like the practice versus like deliberate practice is something that
- 3:51
people make a mistake on or 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
- 4:11
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
- 4:32
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,
- 4:52
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
- 5:14
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
- 5:36
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
- 5:58
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
- 6:19
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
- 6:40
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
- 7:01
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
- 7:21
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
- 7:43
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
- 8:04
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
- 8:25
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
- 8:46
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
- 9:08
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
- 9:28
they naturally kind of catch their own edge cases when they're writing code. Yeah, I 100% agree. Yeah. 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
- 9:49
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
- 10:10
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
- 10:30
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, it helped me I I guess just stay like familiar with like programming style of thinking because I didn't like I mostly have stopped doing math over the last like decade and um, most of the
- 10:51
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
- 11:11
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
- 11:31
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 stuff that kind of programmer where you're just uh most of your work is just going around digging around to like uh
- 11:51
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 that's funny. Yeah. No, that's that's why I went back
- 12:13
to startup land and uh that's kind of why where I've been ever
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
🧑💼 LinkedIn: / navdeep-singh-3aaa14161
🐦 Twitter: / neetcode1
#neetcode #leetcode #python
