As you get more experienced at LeetCode practice, you can envision a hierarchy of problem-solving skills, where each level helps with a different aspect of problem-solving.

At the base of the hierarchy is the most concrete skill: Learning a model solution and using what you learn to solve the specific problem for which you wrote the solution. Studying a model solution this way is not just memorization, but it is a very direct way to learn a skill. First, you learn the steps to solve Problem A, and then you use those steps to solve Problem A. With enough repetitions, it provides a good foundation for the “Problem A” skill.

One level up in the hierarchy is a slightly more challenging and abstract practice: Solving a problem using the skills you learned from a similar problem. This describes the main problem-solving loop for LeetCode practice. Start learning a topic, solve a practice problem, learn more about the topic, solve more problems, and so on until you get good at solving problems in that topic tag (at least through the Medium difficulty level). A standardized problem-solving process helps get the most out of this practice loop.

Topic-wise practice can get you a long way into LeetCode practice, since LeetCode consists of problems that are grouped into standard topic categories. But for harder problems, it isn’t enough to know how to solve a general problem type. Hard LeetCode problems are hard because they require more than a cookbook approach. They require creativity. But that doesn’t mean there’s no way to get better at solving them. A canonical book on mathematical problem-solving, How to Solve It by George Pólya, provides a set of principles and strategies to try. For example: use symmetry; consider special cases; solve a simpler problem first. This is more general advice than “find the middle of a sorted collection and determine if the target is in the left or right half.” But because it’s more general, it can apply to more complex problems.

Since How to Solve It comes from the tradition of mathematical problem-solving, it’s a good fit for LeetCode problems, which are often described in mathematical terms. But as an ultimate level of the skill hierarchy, we can examine problem-solving in even more general terms applicable to all areas of science and engineering. As an example, Ozan Varol’s book Think Like a Rocket Scientist uses examples from the Mars rover program and other challenging real-world projects. Some of his advice: reason from first principles; conduct thought experiments; learn from your failures.

It may seem like overkill to learn techniques that got robots to Mars and use them to solve toy software problems. But although well-defined LeetCode problems may be easier than messy real-world problems, that doesn’t mean they are easy. And LeetCode problems can work better for practice than problems that aren’t easily repeatable. So don’t worry that the technique you’re using to figure out a LeetCode problem might be too powerful for that purpose. If you test it out on LeetCode, you may find it coming to mind more readily when you need it for a bigger project.

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.

Learning a model solution is worthwhile because it gives you a process for solving similar problems. If you know how to analyze and solve one binary search problem, you can apply it to similar situations where you have sorted data and need to search for a target value. The more model solutions you know, the more likely you are to have a ready solution for any given LeetCode problem.

But while model solutions give you a detailed guide for solving similar problems, you won’t always get a problem that you can directly apply them to. So it’s best to see model solutions as an important component of a complete problem-solving process. Here’s an example of such a process for solving any LeetCode problem, even if it’s different from any problem you have learned previously.

Select a problem and open it.

This could be the daily challenge problem, a contest problem, or a model problem that you’re learning.

Start a timer

How long you take to solve a problem can tell you a lot about your progress, especially once you have some historical data about the time these problems typically take. A LeetCode contest or a coding interview has a built-in time limit. But even when you’re practicing on your own, you can compare your performance to previous attempts for the same problem, or to similar problems. The LeetCode problem page even has an integrated timer.

Analyze the problem statement

LeetCode problems are written in an academic style that many people find unintuitive. And sometimes they are just written poorly. The purpose of the analysis step is to convert the original problem into a format that makes more sense to you. Then you don’t have to keep going back to the original statement while you’re solving the problem. At a minimum, make notes about the input format, output format, and what your solution is expected to return.

Solve the problem on paper

Now that you understand what the problem is asking for, or you have some reasonable guesses, sketch an idea for solving the problem. This is the step where you might bring in a model solution that you have previously studied.

Write a pseudocode version of your solution

Pseudocode is a useful way to clarify an algorithm without getting bogged down in syntax or other implementation details. Convert your solution idea from the previous step into pseudocode. As you do this, you may find that you don’t understand certain parts of the solution well enough to write them as an algorithm. In that case, it’s good to work these out before you get to the coding step.

Translate your pseudocode into actual code

Now you have to work out any details that you skipped during the pseudocode step, including syntax and library details. Writing actual code is part of most coding interviews, so make a note of any areas where you find it difficult to translate an abstract algorithm into code. You can focus on these later during your study process.

Test and debug

LeetCode gives you a few test cases and lets you add your own. Unlike some platforms, the LeetCode judge even tells you what the correct answer is for any test case, which makes debugging easier.

Submit (and maybe debug some more)

LeetCode’s hidden test cases are trickier than the practice cases, so you may have more debugging to do in this step.

Stop the timer and record your elapsed time

Once you get an accepted solution, record how long it took you.

Read other solutions

Even if your solution was accepted, it’s probably not the best solution that anyone has ever submitted for this problem. Part of the learning process is seeing what other people have come up with. When you find good ideas, you can incorporate them into your model solutions.

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 model solution shouldn’t just explain how to solve a problem. It should also help you remember the solution, so you can use it in the future for similar problems. Here are a few more ideas for writing solutions you’ll remember.

Use multiple levels of abstraction

Think of a model solution like a pyramid, with the submitted code at the base and a tag like “binary search” or “hash table” at the apex. At the base, all the details are worked out, and all ambiguity has been clarified. That’s what is required to write instructions that can be understood by a computer. At the tip, there are just a few words that name the concept that the problem covers. Between these two extremes, you can explain the problem at different levels. For example, to elaborate on the “binary search” tag, you could say, “Run a binary search on the sorted input array by checking the middle value, then checking either the left or right half depending on how the middle value compares to the target. Repeat until you either find the target or run out of input values to search.”

By writing a solution at multiple levels of abstraction, you can make the solution useful regardless of how much of it you remember. If you just need a small hint, the topic tag may be enough. If you can’t figure out how the topic applies to the problem, you can move lower in the pyramid to get a bit more detail. This is often how LeetCode hints are structured, so people can read just the first hint if that’s all they need, or multiple hints if they need more help.

Divide your solution into chunks

Another way to break up a model solution uses the concept of chunking from cognitive psychology. According to this theory, human working memory has a limited capacity, on the order of seven items. If the number of items you’re working with gets too large, some items are lost.

The reason we can solve complex problems despite this memory limitation is that each item can contain a collection of smaller items. For example, if you try to learn a solution by remembering individual lines, you’ll quickly run out of working memory when you try to reproduce it. If you instead chunk multiple lines into a block of code, that will considerably reduce the number of chunks in a solution. Once you learn a solution well, you could even retrieve the entire solution as one chunk.

As you write your model solution, think about how to divide it into chunks, to reduce the demands on your short-term memory.

Explain the solution in multiple ways

You may have had the experience of reading a solution that doesn’t clarify anything about the problem. Sometimes that’s because the solution is just poorly written. But it could also be that you’re just missing some essential context. When you write your own model solution, you can only use the background you currently have. A year later, you might come to it with a different background. Keep this in mind as you repeat problems and revise your model solutions. As you gain experience, you may be able to write a different solution to the same problem, even if you don’t change the algorithm. Both solutions may be well-written, and the earlier one may even be better for an audience with less experience. But the later one makes use of what you learned in the intervening months. When you gain enough experience, it may make sense to rewrite a solution from your new perspective.

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 model solution is a place to record everything you think is important about a problem and its solution. If you can learn and remember your model solution, you’ll be able to reproduce the solution to the model problem, and you’ll have a head start on solving similar problems.

When you write your own model solutions rather than relying on pre-written solutions, you can customize them so they make sense to you, which means they’ll be easier for you to remember. Just writing and explaining a solution helps you remember it. But if you find that you can only solve a problem after short intervals and not after longer intervals, that’s a sign that your solution isn’t memorable enough. It’s not enough just to write a good editorial that clearly explains every step of the solution. You also have to write it in a way that helps you recall the key parts of the solution when you need them. Here are some ways to accomplish that.

• Explain the solution in multiple ways: You can explain a solution using code, pseudocode, code comments, narrative text, static diagrams, animated diagrams, and other creative methods. Each of these gives you a different way to remember the solution. For example, if you’re trying to reproduce a solution and you’re having trouble with the code, remembering the pseudocode may give you what you need.

• Use diagrams: To get a solution accepted on LeetCode, the only thing you have to submit is code. If your code is accepted, you know that your solution is correct and meets the minimum performance requirements. Once you have the code, it’s easy enough to write a few sentences in your model solution explaining how it works. Drawing a diagram requires a different way of thinking, so a visual representation of the solution, along with narrative text, will help you understand and remember the solution better.

• Pick good identifier names: Competitive programming has a reputation for encouraging short variable names, which contestants use to write their solutions as fast as possible. Coding interviews also have a time limit. But for learning and remembering a solution, it’s best to pick meaningful variable names, while balancing the need to write the solution under time pressure. If you’re practicing a problem and you have trouble remembering a section of the solution, renaming a variable or function could help make it more memorable.

• Write hints: LeetCode supplies official hints for many problems, so people can try solving a problem with a hint rather than by jumping directly to the solution. Hints also simulate the experience of a coding interview, where the interviewer is there to help you along if you get stuck. In your model solution, write a few hints, where each hint supplies more information. You can use these when you’re still learning the solution.

• Record which parts of a solution you don’t remember: A practice journal can help you discover which parts of your solution need to be more memorable. If you remember some parts of a solution but not others, make a note of that. Then use your notes to improve the solution.

• Make your solution explain itself: In real-world software, log files can help programmers track down the source of a bug. LeetCode solutions can also include logging (usually print statements). These logs can help clarify the steps that a program uses to solve a problem, and the state (values of variables) at each step. When you find test data that produces good log output, copy it into your model solution.

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.

The point of studying model solutions is to learn a collection of patterns. When you encounter a problem that resembles a model solution you already know, you can apply your model solution with a few adjustments, and quickly solve the new problem. You don’t have to start every problem from scratch.

But sometimes a problem isn’t a close match to a model solution, and it also isn’t completely new. It has some characteristics of a model problem that you’re familiar with, but you can’t figure out how to fit the details of the problem into the template you have created for that problem type.

Consider our canonical example, binary search. If a problem provides a sorted list and you need to find a value in that list, it’s clear how to apply the model binary search solution. Pick the middle element, compare it to the target, repeat on either the left or the right half, and so on. But some problems require binary search in multiple sets of data, or binary search on the output rather than the input, or 2D binary search, or binary search inside a dynamic programming algorithm. In these cases, simply applying a model solution template might not be enough.

To deal with these more complex problem types, it helps to learn not just the model solution implementation, but the steps required to find the implementation. This requires learning the solution at a higher level of abstraction. Rather than just looking for a list of sorted elements, look for any data structure with a well-defined “middle” element and a way to calculate whether the target is “lower” or “higher” than the middle. Rather than only applying binary search to input values, consider whether you can use it to find the value to return. Rather than asking binary search to give you the final result, consider whether it can provide an intermediate result as part of another algorithm.

Model solutions are useful because they let you practice a solution implementation. They don’t just explain the solution. They also give you code to solve it. For easy problems, this is often all you need. In the early stages of learning a topic, solving a few easy problems for that topic is a good way to reinforce the ideas in the model solution. But eventually you have to step back and learn the theory of why a solution works. This will help you apply the solution to more difficult problems.

This is a general principle of coding practice. Alternate between theory and implementation. Learn a bit about the theory, then solve a few problems. Then learn some more theory, then solve some more problems. Solving problems ensures that you can apply the theory, and learning theory ensures that you understand what you’re doing and can adapt it to other problems. The LeetCode interface tests you on the implementation and tells you if your code failed any tests cases. But it doesn’t directly test your understanding of the theory. So it’s up to you to write your model solution to be more than just a template for easy 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.

Unlike a real-world software project, LeetCode is set up for effective practice. But what is effective in general may not be effective for you specifically. So it’s worth thinking about the best way to practice. The framework I use is explained in Deliberate Practice for Software Developers. Let’s see how the five elements of deliberate practice apply to LeetCode.

Deliberate Practice Element #1: “It’s designed specifically to improve performance”

The LeetCode website is designed to help programmers prepare for coding interviews. So we could delegate responsibility for Element #1 to the LeetCode product managers and call it good. But that would ignore many improvements that you can make to optimize your own practice process through experimentation. By considering your goals, choosing problems carefully, writing detailed model solutions, using spaced repetition with carefully chosen interval lengths, writing a daily practice journal, and considering the other advice in these LeetCode tips, you can make your practice more effective than just opening the LeetCode website and going for it.

Deliberate Practice Element #2: “It can be repeated a lot”

This element doesn’t only mean repeatedly solving LeetCode problems. The skill that you need to repeat is more granular than one problem. Although you need to be able to solve a problem from beginning to end, and it’s essential to practice full problems, it’s also important to focus on smaller skills. As you practice problems, look for areas of weakness in skills like reading problem statements, translating a solution into pseudocode, fluently using the features of a programming language’s syntax and libraries, and selecting and implementing algorithms and data structures. When you run into trouble in one of these areas, find a way to practice it in isolation. The LeetCode website focuses on problem-level practice, so you may need to look elsewhere for some of these. CodingBat is a website that offers practice problems for more granular skills, though its features are rudimentary compared to LeetCode.

Deliberate Practice Element #3: “Feedback on results is continuously available”

The LeetCode UI is all about feedback. You get feedback through compiler errors, test failures, test data for failed tests, and the CPU and memory usage graph. But as with Element #2, you shouldn’t stop with the most obvious sources of feedback. You can generate useful information by tracking how much time you spend on each problem, writing notes in your practice journal, and comparing other implementations to your own. The goal is to determine exactly where your weaknesses are so you can focus your practice on them. This will accelerate your rate of improvement beyond what you would get just by practicing problems.

Deliberate Practice Element #4: “It’s highly demanding mentally”

LeetCode features can lead you astray when it comes to Element #4. Features like the daily challenge problem, the submissions graph, badges, and the solved problems counter. These are gamification features that are useful for building a regular LeetCode habit. But they aren’t always the best choice for deliberate practice. The daily problem might be too easy, might focus on a concept other than the one you’re currently studying, or it might be too easy or too hard. The submissions graph and problem counter might encourage you to submit a problem every day without thinking enough about what you’re getting out of that problem. So use these features to maintain your practice habit, but also set aside time to intensively practice the areas that you need to get better at.

Deliberate Practice Element #5: “It isn’t much fun”

Here’s a question from Reddit: Is competitive programming really worth it?

The top-voted answer:

It’s a hobby like any other. It’s like asking if making model trains is ‘worth it’.

Competitive programming and coding interview preparation aren’t the same thing, and people might be less likely to label LeetCode “a hobby like any other.” Nevertheless, preparing for programming competitions can be serious business, and is often used to get better at coding interviews. So it’s not all fun and games.

The message of Element #5 is that getting better at a skill requires hard work. So don’t be afraid to enjoy it, but if your goal is self-improvement, make sure that’s what you’re focusing on.

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.

There may be a way to design an effective interview process where candidates don’t have to prepare for the interview while companies still get the information they need to make effective hiring decisions. But no one has yet come up with such a process that scales to the needs of large companies. So we have the current state of affairs, where programmers need ways to prepare for interviews.

One justification for interview preparation is that the type of programming that people do for their jobs differs from the type of programming required for algorithmic coding interviews. So programmers prepare by practicing common algorithms that they may have forgotten from their student days. But even if your job is algorithmically oriented (maybe you’re implementing algorithms and data structures for a language library) interview-specific practice still helps. This is because practicing coding for interviews is inherently different from coding as part of your job.

When you’re writing software to be used by customers, you have limited time for activities that don’t directly contribute to finishing the project and getting the result into customers’ hands. Once you implement a solution that meets requirements like correctness, performance, and code quality, you’ll probably need to move on to the next work item. This differs from coding for practice, where you can spend more time on a solution to learn more about how it works, or try alternate solutions and compare them. Although you may still have a deadline (like your interview date) you can justify learning an algorithm from the ground up. That is often not something you can justify on a real-world coding project.

In the current era, there are many ways you can produce a block of code besides writing it from scratch. Two of the most common are getting it from Stack Overflow and asking a coding bot to write it for you. Even coding interview problems can be solved this way. But during a traditional coding interview, you’ll have to write code from scratch. If you have only coded with online resources, you may find this difficult. So it’s worth spending time practicing without modern conveniences. As part of your daily practice, write your solution with no help from an IDE or any coding resources. If you get stuck, focus on the areas where you have trouble.

The first element of deliberate practice states that deliberate practice is “designed specifically to improve performance.” So a musician performing in front of an audience or a programmer doing their regular job is not engaging in deliberate practice. Rather, they are taking advantage of the results of deliberate practice. To improve performance in interviews, you have to practice specifically for that goal, which means finding the parts of the interview process that you find difficult, designing exercises to target them, and repeatedly working on getting better.

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.

Most LeetCode problems require some knowledge of algorithms and data structures. But LeetCode problems are also a way to learn algorithms and data structures. So there’s a symbiotic relationship between the problems and the knowledge required to solve them.

Reading a textbook chapter about binary search will help you understand the principles behind it, how to analyze it mathematically, and the steps required to implement it. But it’s difficult to understand binary search well without solving binary search problems. Solving a simple binary search problem like LeetCode 704 is a good way to learn the fundamentals of the algorithm. From there, you can move on to harder problems where you have to integrate the binary search algorithm into a larger solution. As you’re solving a harder problem, you might go back to the textbook description of an algorithm to clarify the details, and then use that information to improve your solution. In this way, you can set up a virtuous cycle where solving problems helps you understand the algorithm, and the algorithm helps you solve problems more effectively.

Writing detailed model solution descriptions can also help you learn algorithms and data structures better. Just as writing a model solution clarifies your understanding of a specific LeetCode problem, it can also help you understand the general principles behind an algorithm. As you write your solutions, use correct terminology and explain how your solution applies a general algorithm to the specific problem you’re writing about. This will make it easier to move on to the next algorithm in a topic-wise list, since your algorithm skills and knowledge won’t be closely tied to one problem.

Besides applying an algorithm to a familiar problem, another key LeetCode skill is selecting the correct algorithm for a problem you haven’t seen before. As you learn algorithms and write solution descriptions, you can take notes from that perspective. For example, you can remind yourself that when the input data for a problem is sorted or can be sorted, consider using binary search. When you’re solving a topic-wise list of problems, you aren’t practicing this skill directly, since you already know which algorithm the problems require. But even with this type of practice, you can look for similarities between the problems, and include these in your notes. Then, when you need to select an algorithm for an unfamiliar problem, you can look through your list of heuristics to get ideas about which algorithm to use.

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 common criticism of algorithmic coding interviews is that they select for people who have “memorized a bunch of obscure algorithms.” In this view, recent computer science graduates have an advantage over experienced developers because they can still remember the material from their algorithms courses. And candidates can beat the system by memorizing a list of solutions and brain dumping the appropriate solution for the interviewer.

This way of thinking about coding interviews doesn’t make much sense once you have some experience with the process. Although interview problems may be difficult, the algorithms they require are hardly obscure. Algorithms that use hash tables, binary trees, and breadth-first search are commonly taught to undergraduates. But these basic principles can be combined in infinite variations, so memorizing solutions isn’t a very helpful approach. As for recent graduates, they may have some advantage. But given the low pass rate for entry-level interviews, it’s clear that having taken an algorithms course in the past few years is hardly a silver bullet for coding interview success. Most candidates at any level of experience have to prepare for interviews, beyond what they do in their daily work.

The grain of truth in this view of coding interviews is that interviews are not a pure intelligence test. They require domain knowledge, not just problem-solving skills. It’s possible to work as a programmer without ever studying algorithms. In fact, it’s even possible to work as a programmer without remembering programming language syntax or libraries. You can always look things up on the fly in the documentation or Stack Overflow, or have a chatbot write code for you. But you can’t pass a coding interview this way (at least the in-person variety). So for coding interviews, and efficient real-world coding, you do have to remember some information. It’s not enough just to understand concepts.

Since we can’t just memorize all the solutions, but we also don’t have time to figure everything out from first principles during the interview, we need a more nuanced approach to learning this material. Fortunately, we have already covered the necessary tools in previous tips. The key is to maintain the right balance between remembering and understanding.

To do this, we have to use the spaced repetition process correctly, in particular when it comes to interval lengths. Although you must set intervals lengths according to certain heuristics to make the process work, there’s also a risk that interval practice will push you towards memorizing a solution. In the early repetitions of a solution, you have to remember a few things: the general approach that a problem requires, the details of an algorithm, and any language syntax or libraries that you don’t already know from other problems. This type of remembering is good. It’s exactly why repetition is a good way to improve your skills. Repeating the solution with short intervals shows you what you need to learn.

The problem occurs when you try to move beyond short intervals and you get stuck. According to the spaced repetition process, when you have trouble solving a problem, the correct approach is to shorten your practice interval and try again. This may in fact be necessary. But as you think about the right interval to use, make sure you’re not using repetition as an alternative to understanding. Repetitions are good for identifying areas you don’t understand yet, and for reinforcing things you already know, but they’re not good for learning things in the first place. To do that, you need to go back to your model solution, identify the gaps in your understanding, and do the research or experimentation required to fill them. Only after you finish that process does it make sense to go back to repetition.

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.

Gaining fluency in language syntax is the first step in getting better at expressing the solution to an interview problem in code. But even in a coding interview, you won’t be expected to implement everything from first principles. It’s true that if the interview question asks how to implement a hash table, then you’ll have to understand the internal details of hash tables. But if you just need a data structure you can use to insert and retrieve in average O(1) time, you can use the one provided by your language’s standard library.

For coding interview preparation, the difference between built-in language features and a language’s standard library isn’t too important. The best approach to learning either one is to solve problems and read editorials until you encounter a new concept, and then focus on learning that concept. At some point, you’ll encounter features that are part of your language’s standard library, like the C++ Standard Library or the Java Class Library.

Just as with language syntax, the goal for learning a standard library is achieving fluency. Although you can do well in a coding interview even if you forget exactly how to initialize and use a hash table, being fluent in a language library will speed up the coding process and give you more time to think about the hard parts of a problem. It also shows that you have experience using a language. Interviewers often let candidates choose which language they want to use, so they expect candidates to pick one they’re fluent in. If a candidate isn’t fluent in their self-chosen language, the interviewer might wonder how much programming they actually do on a daily basis.

As you solve interview problems and study solutions, you’ll learn which library features are useful for solving those types of problems. Using code from your model solutions, look for patterns in how features are used. You will only need a small subset of the library, so focus on learning this subset well. Within the useful subset, find a consistent way to use library features, which will make them easier to remember. If a library gives you multiple ways to do the same thing, see if you can solve problems using just one of them.

Just as you can write model solutions to document your best approach to solving a problem, you can also write model code for a library feature. Rather than a full solution, this model code is just a block of code with one purpose. For example, some problems can be solved using a priority queue, which many languages offer as a library feature. A priority queue (also called a heap) provides an efficient way to retrieve the maximum (or minimum) item in a collection. To use a priority queue in a solution, you need to know how to initialize it as a max heap or min heap, insert a new item, peek at the min/max item, remove the min/max item, and check the size of the collection. Through practice, you’ll probably find that these are all you need from a priority queue, even if your language offers more properties and methods. So your model code only needs to show how to use these facilities.

Once you write model code for a library feature, you can use it for reference, as an alternative to looking at the library documentation. As you repeatedly do this, you’ll internalize how the feature works, until you reach the point where you don’t have to refer to any model code for that feature.

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.