Transcription
Hi everyone. I'm Nathan. I'm a coach at V Planet, and today I want to talk about the top five mistakes that I often see competitors making when they're just getting started with USACO. This is mainly for people who are in the bronze or silver division, but if you're in the gold or Platinum division, feel free to stay around because you still might find some of this information useful. So, with that, let's get started.
All right, so the first mistake that I see a lot of competitors making is that they'll only practice using topic lists like Codeforces or the USACO Guide. Now, what I mean by this is, on the USACO Guide for example, right, all the problems on there are categorized into sections where each section corresponds with a specific concept. For example, the silver division will have a section for DFS, for prefix sums, or binary search, right? And the problem with that is that when you're only practicing using the USACO Guide, it's going to be a lot easier to solve a problem once you already know that algorithm or data structure you're supposed to apply to use it, right? For example, if I'm in the DFS section, then I know that every problem inside of there is going to involve DFS in some way. So the only real problem-solving I'm doing is just figuring out how I'm going to use DFS for that problem. This is an issue because it takes away a big part of problem-solving, where it's taking away the pattern recognition process of being able to figure out what algorithm applies to what problem.
Now, none of this is to say that you should never use the USACO Guide or practice using Codeforces. Right, these are still very, very amazing resources for you to learn and practice in an organized way. So I strongly recommend using it if you're just starting out and you're just trying to get familiar with every single concept in your division and also trying to figure out how we can apply that concept to real problems. All of that USACO Guide is amazing for. But once you reach a point where you're pretty much comfortable with every single topic and concept in your division, I'd recommend gradually moving away from these two guides because, again, it could take away a big part of your problem-solving process. Instead, what I'd recommend doing is going to the USACO web page and just go into the past contest section and going through each contest one by one, and then for each contest, just go through each problem one by one. And this way you're not going to have this information of what algorithm is supposed to be used for what problem, and that way you're kind of practicing the first part of problem-solving, which is being able to figure out what algorithm to use. Now, I recommend going to the older contests and starting there, and then gradually work your way up to the newer contests. And the reason for that is that the older contests are easier, so as you move along, the problems are going to get gradually harder, but you're also going to be getting better, right? So once you reach the newer contests, they'll be a lot more approachable for you.
So that was the first tip of essentially just not always practicing on these skill guides or Codeforces, and rather, once you get comfortable enough, just moving on to the Past Contest web page and just going through all the problems there. There'll be a second big mistake that I often see competitors making is putting a greater emphasis on learning algorithms and data structures than just problem-solving itself. And again, this is more so in bronze and silver. I think in Gold, you've already developed your problem-solving skills enough where you're mainly just focusing on getting familiar with all these algorithms and data structures. And the reason why this is a problem is that in earlier divisions, problem-solving is the much bigger factor in a lot of these problems than knowing a lot of algorithms and data structures, right? For example, in bronze, you don't really even need to know any big algorithms or data structures. All you really need to know is sorting, maybe a little bit of binary search, and just basic data structures like arraylists, sets, and maps, and things like that, right? But beyond that, problem-solving is the much bigger factor in being able to solve these problems. Knowing what a segment tree is or knowing what DFS is isn't really going to be able to help you to solve the majority of these bronze problems. So your time is much better spent just practicing your problem-solving skills, and this mainly just comes from going through past contests and just solving a bunch of problems and getting better at problem-solving. And this also is the case, in my opinion, in the silver division as well, because really all there is in the silver division beyond bronze is, again, maybe a little bit of binary search, and then beyond that it's just graphs like depth-first search, um, trees, as well as maybe a little bit of prefix sums. But outside of that, again, problem-solving is the much bigger factor in being able to solve these problems, and thus as a competitor in the bronze and silver division should focus a lot more on getting better at problem-solving than just learning a bunch of algorithms and data structures.
So the third mistake that I see people making is when they're practicing, what they'll do is they'll read through a problem; they'll be like, "Oh, I have no idea how to solve this," and after like five to ten minutes, they just give up, read the solution, and just move on to the next problem. Right? This is a very crucial mistake that people make during practice. When you're trying to solve a problem and you're really not sure where to start, you need to spend at least 15 to 20 minutes just thinking very, very hard about that problem. Now, I don't mean just staring at the screen and just thinking in your head about any possible way to solve it. Sure, while that may work for some people, what I really recommend is taking out a piece of paper or going on your iPad and writing out a bunch of different cases to that problem or diagramming everything out visually. Right? When you're able to visualize a problem and when you're actually writing stuff down, you're interacting a lot more with that problem, and oftentimes you'll be able to get a better sense for how you might be able to approach that problem in the first place. And after these 15 to 20 minutes, if you're really not able to get anywhere and you feel like you've made no progress, only when you reach that point should you then go to the solution and try to see what you missed out on. And after you're reading through the editorial, you're done reading through the editorial, try to implement this problem on your own without looking at the solution code. And this way you're really getting a better understanding of this problem that you wouldn't have if you just read through the editorial and you just quickly moved on. Right? You really need to be able to implement the problem by yourself to make sure that you fully understand the entire solution and what's going on. And it's very important that you don't reference the code because if you're just copy-pasting, then yeah, it's going to be very easy to implement it. And only if you're really getting stuck should you look at the code to see what you might have missed on.
Now, once you're done with this process, after you've finished reading through the editorial and you've written the solution code and you've been able to pass all the test cases by yourself, then you should take some time to reflect on the problem, and there's a few cases for this, right? If you weren't able to figure out the solution at all, think to yourself about how you could have approached that problem differently, such that in the future, if you came across a similar problem and pretending that you've never heard of the problem that you've just been solving, how could you have approached the problem differently such that you'd be able to solve it in the future? Or if you were able to solve a problem, but it took you a long time or you made a lot of mistakes during the process, again, think about how you could have optimized your approach to be able to work through the problem faster or been able to debug better, such that when you're in a contest you don't waste a lot of time on one problem. Or if you were able to solve the problem with no issues, then great job, you can pretty much just move on; you already know that you're pretty comfortable with a problem like this.
Right. So the fourth mistake is more with contest strategy and how people are managing their time during contests and strategizing what they're going to put their energy into during these contests, right? So you'd normally be practicing this in a mock contest by maybe just choosing a past contest and going through all the problems, or when you're in a real contest, right? This is where this tip really comes to be very important. Now, what a lot of people will be doing is they'll read a problem really quickly and just jump straight into the implementation. Right? You really do not want to be doing that. Instead, what you should be doing is you should read through all three problems before you start and spend a little bit of time thinking about them. Right? This part doesn't really need to be that long, but having been able to read through all three problems will help you determine A, the easiest problem to go for, and B, you can kind of have like the other two problems sitting in the back of your mind as you're solving the first problem. And when you decide what problem to start with, spend at least 10 to 20 minutes after your initial read just planning out your approach and thinking about possible solutions. You do not want to jump straight into implementation after you spent like one minute thinking about the solution and thinking that it's right, right? Because you don't want to be half an hour into writing your solution and debugging just to realize that your initial idea was completely wrong. Now, for more about contest strategy, I really recommend watching Ria's video about this; it will be linked somewhere in this video. But basically, uh, what she talked about is every 15 minutes you should log what you're doing in the contest. Now, this can be very important because when you're logging down your points and you realize you've logged down solving problem one for the past two hours, this will really help you realize when you need to stop working on a problem and when you need to start working on the next one, even if you didn't solve the problem you're currently working on. And when you come back to that problem after you solve the other two problems, then you you'll be back with a fresher pair of eyes such that you may very well be able to solve it the second time around because you have that fresh pair of eyes. Again, for more information about this, I'd really recommend watching Ria's video; she goes a lot more in depth into this topic.
Now, the final mistake may be a little bit controversial, but in my experience, it's made a huge difference in my efficiency with debugging, and this mistake is actually just using print statements to do all of your debugging for you. In my opinion, using print statements are often able to do the job, but for a lot more involved problems, they're very hard to use to cover the entire story. And when you have a ton of print statements that you're trying to parse through, it could often get overwhelming, and sometimes it's hard to just fully grasp at what all these print statements are saying. So what I recommend instead is actually using a debugger in your IDE or editor to do your debugging for you. And let me just show you what exactly I mean by this with an example.
All right, I've pulled out VS Code here. If you're using a different editor or IDE, you can probably search it up on your own; it's gonna be very similar to this. So the main points are still going to be the same. So I pulled up this random problem called Cal Frisbee; I think it was in the silver division at one point, and yeah, let's see how we can use a debugger to solve this to like debug our program. Right? You don't really need to understand what this problem is; I don't really remember what it is, but we'll just see how we can apply this debugger. Right? So how a debugger works is that we'll set this thing called a breakpoint in our code, and when we're running our debugger, what it will do is it will run the code all the way up to the breakpoint, and then from that point on, we kind of are inside of our own program, and we can control what we want to do next. So let's see what I mean by that. So to set a breakpoint, normally if you hover to the left side of the lines of code, you'll see kind of like a red dot appearing, right? And this is going to correspond to a breakpoint. So let's say I want to set a breakpoint at line 16, right? So I just click to the left of this line 16, and we see this red dot appearing, right? And that's going to be our breakpoint. Now, if we want to debug, all we have to do is click this button here, debug. Again, if you're on a different editor, try to find it for yourself, and this is going to open up this debug menu, right? And we see all these variables, and it's kind of overwhelming at first, but we'll see how it works. Okay, so I'm just going to paste in the sample input, and we'll see how this works. Okay, cool. So what just happened? Well, pretty much what happened is the debugger ran through the first 15 lines of our code, and we've now stopped at the breakpoint, right? So we can see the line highlighted is the current line we're on, and from this point on, we get to control where we move in our code, and we also have some pretty important things on the left side, right? The main thing I think is important is the variables column, where it will show you the value of every single variable that you've declared, and this is incredibly useful if you want to keep track of like some sort of answer variable and you want to see how that's being changed, and this will allow us to easily identify where the answer variable becomes wrong or where our expectations don't meet up with what the code is doing, and then we can just easily debug our code, right? So to move our debugger, what we do is we click this step over button, and this is the main button you'll be using where basically you'll just move on to the next line, right? So I'll just click step over, and you see that we've just moved on to the next line, line 17. And every time we step over, it's going to execute the current line we're on and just move on to the next one, right? So as I step over, we'll see that we're going through our code, and sometimes we're breaking; we're we're really just I don't really know what's going on right now; uh, I wrote this solution a while ago, but what's really important here is you can see how the answer variable is changing as we move through the code, right? Um, so for example, here, right, we get to a line where we increment our answer; we can see, okay, that line increments our answer by two. If this isn't what we wanted, then we could go in and investigate why this is the case, right? And you can see that we're also keeping track of a stack, uh, presumably of cows, um, and we can actually see what's going on with our stack by just clicking the stack variable and looking at the value of every single element inside of the stack, and again we can figure out if there's something wrong going on there, um, and we're also keeping track of a set variable; again, we can just expand that and just look at all the variables inside of our set and see if anything is wrong. And again, this way it's just a lot easier to be able to go through your own code, uh, and just figure out exactly what's going on when you're there, right? A print statement might be a lot harder to understand because you're pretty much looking at everything after the code has run, and you can't really see what's exactly going on at every single line. So that's why I really like a debugger. Again, it's a little bit of a controversial statement to say that using print statements is a mistake, but again, I found this to be very useful, especially actually just throughout all divisions, and I think that especially in contests, using a debugger, and if you're good at it, can increase your efficiency significantly more than just using print statements. If you have any questions, I recommend just going to a different YouTube video which will probably go more in depth into fully how to use the debugger, but this is pretty much just an overview.
So those were the five biggest mistakes that I've seen when I was working with bronze and silver competitors. Hopefully you found something, at least one point in this video, useful. And if you did, please consider leaving a like or subscribing to the channel; it'll mean a lot to us. But yeah, other than that, I'll see you in the next video.