James Routley

Like many people looking for a CS job, I've had to do LeetCode style assessments, and have practiced by solving problems on leetcode.com. I have solved around 35 thus far. The process I describe below has worked for me, but it may not work for you.

tl;dr: I use Grind 75, always try to solve a problem immediately and without help, and then use Claude (section) to improve my solution. I think section 4 is the most important.

In an earlier version of this essay, I didn't address what counts as success on LeetCode problems.¹ That was a mistake.

Fundamentally, my goal is to become a better programmer, and LeetCode is one aspect of that. It's not the reason why I do them, per se, but it is how I approach the process. It's possible to do a lot of LeetCode problems and not learn anything lasting. One friend of a friend memorized enough answers to get a job at Amazon but did not know the difference between = and ==.² I find this really sad; he probably put in a lot of time in, but all he will get out of it is a line on his resume.

That being said, performance still matters. I don't think it should be the goal, but it is worth paying attention to. I believe (though cannot justify) that if one practices LeetCode with the goal of becoming a better programmer, their performance on LeetCode assessments will improve. If this is true, than one can take performance as one check on learning: if I solve a problem which requires a specific approach and I cannot apply it the next time the approach comes up, then I have not learned enough from the previous problem. Even if takes longer, however, I think it is better to focus on getting a deeper understanding of every solution you write than to pattern match on solutions that others have written.

This means that the process I am using may not work for your needs. If you need to prep quickly for an assessment, it may not make sense to spend as much time as I do on each problem. You might try to determine what problems that company asks, and do a lot of those. You might learn less, but do better in the short term. Also, if you are more experienced at coding, there might just be less to learn from doing LeetCode problems, which makes my attitude less useful.

Sidenote on attitude:

How do I fit LeetCode into the rest of my efforts to improve my coding abilities? I treat them as warmups, and as something to do when I need a simple win. So much of programming (and of life) is ambiguous in scope and success. Leet code is a lot more fun for me when it is a "little treat" rather than an obligation for job searching.³

I use the default Grind 75 list of problems. This is customizable to increase and reduce the number of problems. I have found this useful for a couple of reasons:

Leet code style problems are often solvable using a smallish set of strategies.⁴ Using a crafted list like this has helped ensure that I solve problems which require each of these strategies
The Grind 75 list does a good job of ramping up the difficulty gradually. It begins with Leet Code easy problems where basic strategies are cleanly applied before moving towards harder problems
It makes it easier to do problems because I don't have to figure out which problem to do. This helps make it seem like a "little treat" as mentioned above.
Personally, it makes progress easier to see; I slowly progress down the page and can quickly see how many problems I have done thus far.

There may be good reasons not to follow a list like this, but it has worked for me.

I have the least amount of advice here. A lot of solving is practice. But I do have a couple of principles I follow:

Solve the problem first!

This is sometimes a hard one. If I am feeling unmotivated, it can be easy to look at the hints, or ask an LLM for the answer. This is especially true if all I can think of are bad or hacky solutions. But, I think it is worth the effort, even if it requires coming back to the problem later.

LeetCode practice is trying to develop two skills. The first is learning common problem solving strategies (which we isolate further after submitting a solution; see below). The second is learning how to solve a problem under pressure, even if we cannot figure out a clean solution. The only place to practice this is during one's first attempt at a problem, so I try not to waste it.

This is not always true, of course. But at the very least, it is worth spending a little bit longer than you think you should before getting help⁵

If I am completely stuck, I try to follow this list of strategies:

I take a break from the problem. This may be to work on a different problem, or take a walk, or work on something completely different. Often, the problem will feel a lot easier when you come back to it.
If I am still stuck after coming back to it and giving another effort, I look for a hint. I check if the LeetCode problem itself has a hint; otherwise I ask Claude for a small hint to the problem.
I try my hardest to solve the problem given that one hint. If I am still flummoxed, I repeat steps 1 and 2 with progressively larger hints as necessary.

[Note: John Yamashiro shared a tip with me that I think is useful here. When he feels stuck and wants to look at a hint, he'll set a timer for 5/10/15 minutes to give himself one more try. That extra bit of tiem pressure/motivation can make the difference!]

This one is simple. Knowing about a problem but not actively working on it makes it easier to solve when one starts a solid effort. Unfortunately, one does not have the luxury to do this in an assessment. Where necessary, then, I try to only read a problem statement when I have the time to solve it.⁶

Note: this does not contradict the previous section. If I am sufficiently stuck that I would not have gotten the problem in an assessment anyways, then taking a break won't hurt me.

The principles of debugging still apply!

I don't have leetcode premium, so I can't use their built-in debugger. But, I do what many people do anyways and use print statements. The "Run" option is your friend here. Being systematic here is really helpful. Maybe practice debugging separately?

I believe this is the most important section. It is easy to feel like you are done after you have submitted a working solution, but there is a lot to still learn. There are two broad questions that I try to answer:

How could I improve this specific solution?
What other approaches should I be aware of to solve this problem?

The second question is super important. It gives one the chance to learn about "ideal" approaches even if one did not come to it during the process of solving the problem initially.

How do I solve these problems? With three main approaches:

I look for hints
I ask Claude
I look at other's solutions

Hints:

It may seem a little bit weird to look at a hint after solving the problem.⁷ However, they can be really helpful. Hints are a way to test whether the solution that you came to is the same as the solution that the hint expects you to come to. If they are the same, great! If they are not, you can, with the aid of the hint, solve the problem again in a new way, and learn even more from it.

Where do I look for hints? Primarily in the LeetCode problem description, if they exist.

Chatbot/Claude:

After I have looked through the hints, I ask for further suggestions from Claude.⁸ I use the following prompt template to ask for more suggestions:

I am trying to solve LeetCode [Problem #], [Problem Name]. [Brief description of my solution].

Answer the following questions:

[Some specific question about how to improve the solution].

What are other ways I can improve this approach?

What are other approaches to solving this problem. List at least three.

Do not give me an answer, but briefly describe the ideas. For all questions, don't give me a working code sample, but you are free to use code snippets to illustrate your answers.

[Add solution]:

I customize the text in brackets. There are a couple of things worth noting:

Brief description of my solution: This is a good exercise for communicating code, and I often find it helpful for recognizing what pattern I used. E.g: I might say "I used a depth first search to find the target cell" or something.
The specific question: I started doing this when I wanted to decrease the number of for-loops I was using in my code.⁹ However, over time, I customized this question for each problem. This has helped me be more thoughtful about the weaknesses of my code.
List at least three: This is something I am trying out. Occasionally, Claude won't give good alternatives. (Sometimes there are none). But, asking for it to list at least a couple improves the chance it points out an important approach that I missed.
Don't give a working answer: This one is important. If I ask for alternate approaches, it will give full code snippets that I can submit as is. But, I learn less from that. By asking for it to only provide a high-level approach, it gives something closer to a hint.

This is the product of a good deal of iteration, and I encourage you to do the same!

After getting a response from Claude, I decide whether it is worth implementing another solution. (Sometimes a problem only has one good solution). If so, I then chat with Claude about how to implement the solution; I take the lead but don't hesitate to ask questions.

One bonus is that it lets me practice skills that aren't traditionally measured by leetcode; for instance, when editing a solution today, I learned about __slots__ and practiced doing a DRY implementation.

Leetcode solutions

I occasionally look at the Solutions sidebar, but I don't find them useful. Primarily, they are a sanity-check. If the solution is quite different from my approach, then I try to understand it further. If my approach is similar, however, then I won't look further. If I find a good repository in the future, I may link it here.

This is something that I don't currently work on, but is worth mentioning. It probably makes sense to take notes on what one has learned from different solutions, and use other types of quizzing strategies. Like trying to recall a solution from memory. Or using spaced repetition somehow.