When you use spaced repetition for LeetCode practice, keeping track of repetition intervals on your own is better than having practice software do it for you. Unlike vocabulary words, LeetCode model problems and solutions are complex, so you’ll only have time to practice a few of them per day. This gives you the time to consider the appropriate interval length and what your goals are for the current repetition. Here are some suggestions for what to focus on at each interval length.

0 days

It helps to practice a model solution even right after you finish reading it. If you stare at a solution for 10 minutes, then put it away and start typing it into LeetCode, you still probably won’t be able to recall the full solution from memory. You’ll have to use your understanding of the solution to come up with a working submission. As you try to reproduce the solution on day 0, you’ll notice which parts are harder than others. This will start the process of learning the solution, and it can help you find parts of the model solution that need to be updated with a clearer explanation.

1 day

The one-day interval works like this: You practice a solution on day 0, sleep for one night, and try to reproduce the solution the next day without looking at it again. This will expose different facets of the problem that you didn’t see the previous day. Sleeping is good for consolidating memories, but it also starts the process of forgetting. So at this interval, you may find that parts of the problem are difficult to remember. Recalling troublesome parts helps strengthen recall, and as on day 0, it can encourage you to make updates to the model solution description.

2-4 days

For the two-day interval, you practice a problem, skip one day without practicing it, and practice it the next day. For the four-day interval, you skip two days. The 2- and 4-day intervals increase the difficulty of remembering the details of a solution, but they are still short enough that you’ll remember most of the problem, including which algorithm you used and some parts of the code. But you may forget some implementation details if you haven’t practiced similar problems. This is a good time to think about how the algorithm works and how to apply it in more general cases.

8-16 days

At these intervals, you can forget major concepts required to solve the problem. So it’s important to slow down and avoid increasing the interval until you have mastered it at the current length. Since you’ll be practicing other problems in parallel, solutions to multiple problems can get mixed in your mind. You might recall a technique that worked on Problem A and mistakenly using it on Problem B. That provides an opportunity to learn how to map a problem with the solution that works for it, which is an important skill to have when you’re solving unknown problems.

32-64 days

With this amount of time between repetitions, you might completely forget a problem, almost as if you are seeing it for the first time. This shows that you are increasing the repetition interval too quickly. The 32- and 64-day intervals are a good time to make sure you have a solid understanding of every part of the solution, including how to pick the solution approach given the problem description, the high-level plan to implement the solution, any tricky details for particular steps, and finally all the low-level implementation details.

128-256 days

At very long intervals, the only options for solving a problem are 1) Retrieve the solution from your long-term memory, or 2) Figure out the solution from general experience. You won’t be able to rely on short-term memory from recent practice sessions. The goal is to use option 1. The purpose of model problem and solution practice is to learn canonical problems in such a way that you can implement them without thinking too much. For example, you should be able to implement the standard binary search algorithm without thinking about how to find the middle of an array, or considering the pros and cons of lo < hi vs. lo <= hi.

The 128- and 256-day intervals are not so much about learning a problem, and more about verifying that it’s really in your long-term memory. After some experience with the spaced repetition process, you should be able to work out every detail of a problem at the shorter intervals, and avoid lengthening the intervals too quickly. Then once you get to the longer intervals, you should always be able to solve the problem. If that works out according to plan, you can now archive the problem to make room for new ones.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

As you use a spaced repetition process for LeetCode practice, there are more things to keep in mind than just reproducing the solution correctly. Here are more tips to get the most out of the process.

Make sure you’re practicing the right problem

Before you start spaced repetition practice, you need to choose a model problem and write a model solution. But it may take several repetitions to figure out whether the problem you selected is the best problem for your current level of mastery of a topic. If you write a detailed solution for a problem and refine it over several repetitions, but you still have trouble reproducing the solution, it may be best to leave that problem for later. Maybe the problem combines multiple techniques in a tricky way, or builds on fundamentals that you haven’t yet mastered. It’s fine to switch to another problem in the same area, and come back to the original problem later. Spaced repetition works well to strengthen your understanding of a topic, but it’s not designed for learning a topic from scratch.

Understand the solution rather than memorizing it

Another advantage of spaced repetition is that it tells you when you’re trying to memorize a solution rather than learning it. For short practice intervals (up to a few days), you won’t know for sure whether you really know a solution. Although you may succeed in reproducing it, this could be because you remember it from the previous interval. But as you increase the interval length, it becomes increasingly difficult to remember a solution unless you understand it (unless you’re using sophisticated memorization techniques, which are better for card tricks than programming). So once you get to a 15- or 30-day interval, you can be confident that you know how the solution works, not just how to reproduce the code.

Develop building blocks to use for other problems

Repeating a problem that you have already solved uses skills that differ from the ones required to solve an unknown problem. But the first type of practice can help with the second. For example, if you encounter an unknown problem that seems like it may need a binary search solution, that knowledge won’t help unless you can implement binary search. So as you write your model solutions, remember that you’ll need to use these solutions for other problems in the future. When possible, write them in a way that isn’t too specific to the problem at hand. Some competitive programmers use this approach by assembling a code notebook to use as a guide for implementing tricky algorithms. But interviewers generally don’t allow this type of notebook, since they want to see you write code yourself. So for interviews, it’s best to keep the notebook in your head.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

Spaced repetition might seem like a memorization process. In its simplest form, you use spaced repetition by simply reading a prompt and responding with the correct answer. In the LeetCode context, the prompt is the LeetCode problem description, and the answer is an accepted solution. If you solve the same model problem multiple times, you get better at solving that problem and similar problems.

But LeetCode problems and solutions are longer and more complex than standard spaced repetition content, so it doesn’t work to approach them the same way. Here are a few things you can try to do as you use the process.

Improve your model solution

The goal when writing a model solution is to explain the best way to solve the problem, using your own experience and what you have learned from other people’s solutions. But no matter how careful you are to include every relevant detail, you will always find out more about the problem as you practice it. Taking a break from a problem to do other things (including solving other problems) gives your subconscious time to work on it. When you come back to it, you’ll notice additional details, and you’ll probably find that some parts are more difficult than you thought they were when you wrote the solution. Use this insight to improve your model solution. If you had trouble with part of the problem during a repetition, update the solution to explain that part more clearly.

Adjust the problem difficulty

Learning through problem-solving is most efficient when you practice problems that are just hard enough. It’s not useful if they’re so easy that you can solve them in your sleep. And if they’re so hard that you can’t make progress on them, you won’t learn anything either. But it’s not always possible to find problems at exactly the right difficulty level, unless you have an instructor to write problems specifically for you. Spaced repetition can help in this situation. A problem that you have studied previously is easier if you try it again soon after you have solved it, and harder if you wait longer. So you can adjust the difficulty of a problem by adjusting the repetition interval. If it’s too easy, wait longer to solve it again. If it’s too hard, reduce the interval or improve the solution to better explain the hard parts.

Narrow down a problem area

As you practice a problem using spaced repetition, you may encounter the following situation: After practicing a problem a few times at increasing intervals, you remember most of the solution but forget part of it. This is fine. It’s the spaced repetition process working, making you aware of a specific part of the problem that you haven’t completely learned. When this happens, you could reduce the practice interval, which is what the spaced repetition process says to do when you have trouble with a repetition. But if you have already practiced the problem several times at longer intervals, reducing the practice interval may not be the best option. Instead, keep the current interval, but write a detailed analysis of the difficult area in your practice notebook. The reason not to go back to a shorter interval is that while that will help you solve the problem successfully, it promotes a memorization approach. Once you reach an interval of a week or two, the goal is to rely on understanding the solution rather than remembering it. If you remember anything, it will be the general solution structure rather than lines of code. Once you get to this level of understanding of a problem, it’s best to keep using it, even if it means you have trouble solving it. If things still aren’t working out after a few tries with the same interval, it’s fine to reduce the duration. But try the other approach first.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

For most programmers, solving coding interview problems is not a natural way of coding. It takes time and practice to get good at them. Using spaced repetition techniques makes this practice time more effective.

The canonical example of spaced repetition is using flashcards to learn language vocabulary. Anki is a popular software application that implements spaced repetition by presenting each flashcard at the optimal time. In vocabulary study, each card is fairly short, just a single word and definition. But there are many cards to learn, since learners need to know thousands of words to become fluent in a language.

For coding interview problems, the quantities and material to learn are quite different. The well-known Blind 75 list, as its name implies, has only 75 model LeetCode problems. Even the largest list on NeetCode has only 327 problems. Each of these problems might require 25-50 lines of code to solve. That’s small by real-world programming standards, but there’s a lot of detail packed into those lines.

Algorithm implementation is a different kind of knowledge than vocabulary definitions. You wouldn’t want to memorize how to implement binary search the way you learn what a word means. Given these differences, you might wonder how applicable spaced repetition is to LeetCode problems. Maybe it’s better to solve a problem once, write a detailed model solution to make sure you understand all the details, and then move on to a new problem.

The problem with this approach is that if you only solve a problem once, you’ll never practice recalling the details of the solution from memory, which means you probably won’t remember how to solve it. Although they represent different types of learning, a complex activity like implementing an algorithm and a simpler activity like defining a vocabulary word both use the brain’s long-term memory functions. Rather than having to re-discover the principles of binary search when you need that algorithm, you can instead remember your model solution. That frees up more of your 30-minute interview to adjust your implementation to the specific problem you need it for.

To make this more concrete: If you want to remember how to implement binary search in a year, it’s not enough to practice once today and again after a year. Instead, start out with small intervals and increase them with each repetition. The basic interval is one full day (since sleep is important for consolidating learning). So when you’re learning a new model solution, start by practicing it every day for a few days. Once that becomes easy, a rule of thumb is to double the time interval after each successful practice session: Two days, four days, eight days, and so on. Adjust the interval times based on how hard a repetition is. If you’re using an eight-day interval and the problem seems very easy, try skipping 16 days and go directly to 32. If it’s too hard, stay at the same interval or cut it in half. Once you get to 256 days, you have probably learned the problem for the purpose of interviewing. You can either remove it from your model problem list to make room for another problem, or just practice it once a year to make sure you still know it.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

One way to use LeetCode is to solve as many problems as possible. The argument for that approach is that the more problems you solve, the more experience you get, which will make it more likely that you’ll be able to solve the problems you encounter in an interview. There is some merit to this argument. If you never practice solving binary tree problems, it’s unlikely that you’ll be successful if an interviewer asks you to reverse a binary tree. However, the opposite may not be true. If you practice 100 binary tree problems, you might still not solve the particular binary tree problem you encounter in an interview.

The purpose of model problems and model solutions is to improve the quality of your practice, independent of the number of problems you solve. You should add a problem to your list of model problems because you think it’s the best problem you know of to learn a particular skill. The model solution you create for that problem explains everything important about that problem, including parts you may not notice if you just solve it once and move on.

But writing a model solution doesn’t mean you’re done with a problem. It’s good experience to select a model problem, solve it on your own, study other people’s solutions, and write your model solution. You’ll know a lot more about that problem than you did when you started, and you’ll know better how to solve related problems. But even after doing this work, you’ll be far from an expert in that problem. If you doubt this, find a LeetCode Medium problem and follow the preceding steps to write a model solution for it. Then wait 30 days and try to solve it under timed interview conditions. My guess is that you’ll find it challenging, even though you’re re-solving a problem that you have studied in depth.

To effectively use model problems and solutions, you need another tool, spaced repetition. When you first study a LeetCode Medium problem, there are a lot of details to keep track of. You have to understand what the problem is asking, the algorithms and data structures you need to use to compute the result, and the implementation details for your chosen language. It can be difficult to keep everything straight, so you may not have the spare mental capacity to learn the more general lessons the problem offers. But if you repeat the problem a second time, some of it will be familiar. You won’t have to think as much about some parts of the problem-solving process. You’ll be able to focus on details that you may have missed the first time. With each repetition, some aspect of the problem will become easier, until you reach a level of mastery where you can solve the problem from start to finish with minimal effort.

That’s the repetition part. The spaced part is the time between repetitions. If you solve the same LeetCode Medium problem every day, it will get quite easy after a few days. But if you stop practicing it for 30 days and pick it up again, you might discover that it has somehow become difficult again. To avoid this problem, you need to schedule your repetitions effectively. In the next tip, we’ll look at how to design a spaced repetition plan that makes the most of each practice session.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

Writing your own model solution for a LeetCode problem can help you clarify the solution details in your mind, and it leaves you with a living document to use and improve each time you practice the problem. As an example of what to include in a model solution, I’ll use the one I wrote for LeetCode 1818: Minimum Absolute Sum Difference.

Here are the sections I recommend including in a model solution:

Problem

Rewrite the problem statement in a way that makes sense to you. LeetCode problem statements aren’t always written in the most understandable way, and even if a problem statement is clear to some readers, it may not be clear to you. So write your own. This section is also a good place to introduce variables you can refer to in the solution.

Solution

Now that you clearly understand the problem, write the solution itself.

Intuition

Summarize the key challenges posed by the problem, and the main approach you will use to solve it. When you’re writing the more detailed sections below, make sure they follow the general plan explained in this section. If they don’t, either adjust the details or adjust the plan. You can also use the intuition section to remind yourself how to solve the problem if you forget what approach you used in a future practice session. In this way, it’s a bit like the hints that LeetCode provides for some problems. But while LeetCode authors write hints cryptically, so they don’t give away too much, you should write your intuition section clearly.

Algorithm ideas

In LeetCode discussion posts, authors often jump to the solution without explaining how they figured it out. The algorithm ideas section is for explaining how you got from the intuition to the final product, including any false starts that can help explain why you solved the problem in the way you did.

Algorithm

LeetCode problems focus on algorithms and data structures. The algorithm section explains the final algorithm that you used to solve the problem. Usually, you’ll want to explain the algorithm using pseudocode. There is no official pseudocode syntax like there is for a programming language, so use whatever form of pseudocode is most understandable to you. For the Minimum Absolute Sum Difference solution, I used a bulleted list, with the statements inside the for loop indented as they would be in code. For a more code-like pseudocode format, see my model solution for LeetCode 227: Basic Calculator II.

Algorithm Notes

For some problems, it may not be clear why the algorithm works, even when the explanation is well written. Example cases or test data can help clarify how the algorithm handles different input. For an example of explaining why an algorithm works by enumerating all cases, see my model solution for LeetCode 1288: Remove Covered Intervals. This model solution also uses diagrams, which make most model solutions more understandable.

Code

Finally, we have the actual code, meaning code that LeetCode would accept if you submitted it. If you used code ideas from other sources, this is a good place to link to those in case you want to look them up later. Although LeetCode doesn’t care about code comments, it’s useful to add them to your model code to show where you implement each step of the solution. If there are any remaining questions about what each code block does and why it works, this is the place to clear them up.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023.

Practicing a LeetCode problem with the help of a model solution ensures that you are learning an optimal solution, not just any accepted solution. But don’t just take someone else’s solution as your model solution. Use what others have written, and make it your own.

Once you choose to include a problem in your set of model problems, you can begin writing the model solution. After you solve the problem once, the next step is to do some research. Review what others have written about the problem to see what approaches are available. Most problems are amenable to a few different approaches, but model solutions should focus on just one of them. For an especially good model problem, you could write two separate model solutions using two different approaches. But I would recommend finding a second model problem for practicing the second approach. LeetCode has plenty of problems, and it’s rare to find a single problem that is truly the best choice for learning two different solution patterns.

The solution approach will dictate which algorithms and data structures to use for your solution. Collect a few example solutions that use a similar approach. This will show you how different people implement the same type of solution. You may find that one of these examples meets your needs, but you can often combine the best parts of multiple solutions.

Next, make sure you understand how the solution works, and why each block of code is necessary. Go through your example solutions and draw diagrams, write explanations, and add code comments. These artifacts will be useful for any problem, but depending on the problem type, some of them will be more useful than others. For example, a geometry problem lends itself to pictures, while equations may work better to explain a number theory problem. I find it useful to write up a formal solution (an editorial in competitive programming jargon) like this one I wrote for LeetCode 1818: Minimum Absolute Sum Difference. I think it helps present the solution research in an organized way that helps me remember how it all works when I come back to it later.

Of course, you’ll also need to write your own code for your model solution. It will have some relationship to the example solutions that you found during the research phase, but you’ll write it in your preferred language, using your own unique coding style. And most importantly, you will get the experience of writing a solution from scratch.

Your model solution isn’t done when you have working code and an editorial explaining why your code works. You should practice model solutions repeatedly. Each time you practice, you might notice some code that you can make clearer, or a section of the editorial that isn’t as understandable as it could be. When this happens, update your model solution. A source control system like Git comes in handy here, so you can review your changes and revert if something doesn’t work as expected. Updating your model solution regularly ensures that it captures what you learn each time you practice it, and that older solutions take advantage of lessons from newer ones.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023

A well-chosen model problem gives you a vehicle for studying a specific concept. When you first select a problem, it’s good practice to see if you can solve it on your own using what you already know about the concept. But a problem is useful for practice even after you have solved it once. A problem that you have already solved is best used along with a model solution.

Selecting a problem you haven’t seen before and solving it for the first time is a good way to simulate what happens in a coding interview. But it’s only one type of practice, and you shouldn’t spend all your time practicing that way. Instead, reserve some of your practice time for problems you have already solved. This is where you need a model solution, which you can think of as the best solution you can create using all the resources available to you.

Once you submit your own solution, compare it with examples like the official LeetCode solution, the solutions posted by others in the LeetCode discussions, and solutions found elsewhere on the Web. This process, known as upsolving in competitive programming circles, is a key part of practicing a problem. Even if the LeetCode online judge accepted your first solution, there are other ideas that you could use to improve your solution, or to make your solution more useful in solving other problems.

The model solution emerges from this research. As you study other solutions, you can rewrite or update your model solution using the best ideas you find. Use your own coding style and make sure you understand each step. Think about whether the solution prioritizes runtime or memory usage, and whether you can write a different version that makes the opposite trade-off. At the end of this process, you’ll have one or two high-quality solutions to your model problem, and a foundation for building solutions to other problems that are based on the same concept.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023

In the model problem approach to LeetCode practice, the goal is to focus on specific problems rather than abstract concepts. For example, instead of focusing on the general properties of hash tables, or even hash table syntax in a particular language, find a problem that uses hash tables and study that problem. You’ll still learn the concepts, but you’ll have an implementation to associate them with. Then when you need hash tables to solve a new problem, you can retrieve your model problem implementation (either from memory or from your source code repository) and map it to the new problem.

To use the model problem approach, we need to choose model problems. Some problems make better model problems than others. Here are some principles to consider as you make your choice:

• Pick the right problem for your level: To improve at a skill, it’s best to practice problems that are slightly above your comfort level. For a model problem, the requirements are a bit different. Your aim in solving a model problem is to create an implementation that you can use in the future. Much of the skill improvement comes later, when you use your model problem to understand harder problems. For that reason, it’s fine if the model problem is easier than problems you would normally select for practice.

• Switch model problems over time: It’s hard to find a single model problem that covers every detail of a programming concept. So once you’re familiar enough with a model problem that you can confidently implement it, find another one that approaches the concept from a different angle. After you do this a few times, you’ll have a set of model problems that provide broad coverage of the concept.

• Choose a problem that focuses on the concept: If a problem uses a hash table as its primary data structure, but the hard part of the problem is in some other area, it’s not the best choice for a hash table model problem. One rule of thumb: The easier a problem is (in LeetCode’s Easy – Medium – Hard difficulty system) the more it’s likely to focus on fundamental concepts, and the less creative thinking is required. It’s good to practice creative thinking once you’re familiar with a concept, but learn the concept first.

• Check the like/dislike ratio: Each LeetCode problem shows how many users have liked or disliked it. This is one way to filter out problems that rely on tedious implementation details rather than fundamental concepts. You may get tedious implementation problems in interviews, so you have to practice them, but they’re not the best choice for model problems.

This year, I’m publishing a series of tips for effective LeetCode practice. To read the tips in order, start with A Project for 2023