Mastering Leetcode: 6 Problem Picking Patterns for Technical Success

I recommend you prepare for whiteboard programming interviews using the 5 to 23 Patterns approach over the Blind 75, the NeetCode 150, or even doing the NeetCode 150 3 times over. I wonder how long that took. I wonder how much the opportunity cost was paid.

The Blind 75 has gone stale in part because it selects particular problems and the most frequently asked problems in Big Tech change over time. In contrast, the 5 to 23 Patterns article provides evergreen advice: It asks you to search Leetcode at your time of reading. One gap in this advice is that it doesn’t tell you how to search Leetcode. That’s what this article does.

In the first section, I discuss technical performance calibration, or how to determine your own skill level relative to leetcode difficulty tiers, which is important for problem picking. In the second section, I describe my preferred six problem-picking strategies.

Finally, in a third section, I ironman the practice of massive brute repetition that I lambasted in the opening. tldr; the key is to repeat in a non-blocking way with respect to landing your first full-time role.

1. Technical Performance Calibration

There are five ways that I currently recommend picking problems. Notice that the 5 to 23 Patterns article only encourages picking three easy problems to start with. That is because you may do three easy problems and find them to be too easy. This brings us to calibration before we get into problem-picking. Calibration means picking problems that are ideal in difficulty to you personally.

A simple approach to calibration is:

1. If your current tier is too easy, pick a problem in a higher tier
2. If your current tier is too hard, pick a problem in a lower tier
3. Else, remain in your tier

How do you know whether something is too easy? Is it an objective rule based on your personal acceptance rate? No, it’s a subjective feeling of confidence. Your acceptance rate will influence this, but some people will be risk-seeking with respect to the interview process and they will be comfortable interviewing with companies even with a 33% acceptance rate, while others will have crippling anxiety going into a real interview with such a low acceptance rate. The key is to make sure you go into a real interview without crippling anxiety 😅.

I will give you two objective guidelines, though:

1. If your acceptance rate is statistically insignificant, keep practicing.

   1. To this end, try to complete a minimum of 24 problems with a minimum of a 33% acceptance rate before performing real whiteboard interviews. You should be able to fit this into two weeks, so it shouldn’t slow down your job search.

      
      

2. If your chance of failure is statistically insignificant, your bar is way too high.

   1. This indicates you are probably trying to guarantee performance at your company of choice. This is a strategy that will often result in anxiety even if you are technically skilled, and there are other problems with this meta-strategy including the fact that it puts you in a poor negotiation position even if you succeed in the interview. In short, I don’t recommend you do this. Don’t get your heart set on a single company.

      
      

   2. Given that you don’t have your heart set on a single company, why should you even care if your acceptance rate is 33%? For pure anxiety management, it’s nice to tell yourself “I usually answer things correctly.” So fine, put an upper target on an acceptance rate of 60%, which is significantly above half the time.

      
      

   3. If your acceptance rate is over 60% and you have done more than 24 questions, stop wasting time. Get off of leetcode, go apply to jobs, and go social network. Do some exercise and get some sleep. Landing a job is about more than just grinding leetcode. You should continue only a maintenance level of leetcode practice: 1-5 hours or 3-5 leetcode problems per week, up to whichever boundary is greater, but not exceeding that range.

Calibration is the process of developing a nuanced understanding of your skills, strengths, and weaknesses.

Here are some important additional notes to technical performance calibration:

1. Identify ways to rank problem difficulty then identify the boundaries of your skill and target those problems just on the edge of your ability for maximal growth. The acceptance rate on leetcode is a great ranking tool.

   
   

2. Don’t be surprised when you jump from an easy to a medium and your experience goes from too easy to nearly impossible. These are low-nuance labels with much internal variation. Consider the qualitative explanations for your experience and do some internal root cause explanation, debugging, and troubleshooting.

   
   

   Often, it will turn out that:

   1. The higher level question touched on a skill you haven’t learned. Please do backtrack this is a good development practice not a shameful thing.

      
      

   2. The lower level question was uniquely easy even for its own tier, or happened to be a type of problem that you are already good at. Consider checking horizontally around the tier for problems of other kinds or with a lower acceptance rate.

      
      

   3. Other sources of variation; tiredness, nutrition, stress, and so on. 1-to-1 comparisons are awful ways to calibrate. Calibration as a best practice is a statistical exercise. So, you really won’t be very well calibrated at a level until you have done one or two dozen problems in that level. In the real world, many programmers land junior roles before they are even generally calibrated to the leetcode easy level 😅😅

2. The 6 Problem Picking Patterns

I have put these in order of most to least recommended, but I recommend all six approaches so feel free to choose any of them in any combination. The 5 to 23 Patterns article suggests picking three easy questions to start with, so you may end up moving into the medium tier before you exercise all of these problem-picking patterns. That’s fine.

The 6 Problem Picking Patterns are:

1. Sort by Frequency. In Leetcode, this is behind a paywall. This is ideal because it reflects you investing time into the questions you are actually likely to be asked. After sorting, pick the most frequently asked questions.

   
   

2. Sort by Difficulty. In Leetcode, you can approximate this by sorting the acceptance rate and choosing problems in an easier tier. After sorting, pick the following three questions:

   1. Pick the easiest question in a tier.

   2. Pick the hardest question in the same tier.

   3. If they are both too easy, move up a tier. If the harder question is too hard, bisect the difficulty window you created and iteratively calibrate to hone in on your exact ideal difficulty.

      
      

3. Random Selection. This is nice because eventually, you will get total topical coverage and a high-quality calibration. Of course, you probably want to set additional criteria so that you don’t jump into hards too early. You might randomly select within a tier, within a problem type, or among a few specific problems that you are considering for other reasons.

   
   

4. Select from a standard source, like the Blind 75 or NeetCode 150.

3. akshully, brute force repetition is kinda op, and career advice

Brute force repetition is a powerful technique and I do recommend it, I just don’t recommend blocking yourself from interviewing. As I say in the 5 to 23 Patterns article:

Mastering the 23 patterns at the hard level frankly doesn’t seem necessary even for me at the Senior/Principal level, and it’s a thing that can take years to achieve.

After landing your junior role, I recommend you continue to practice 3 leetcode problems per week. Strike a balance between repeating problems you already know and picking new problems.

You may end up memorizing solutions and that’s a good thing! Memorization isn’t bad. Memorization to the neglect of deep learning is bad, but memorization joined with deep learning is how we build deep intuition or technical instinct, which is extremely powerful. Some people pick this up quickly, but for many people it takes years and for others it never happens.

Technical instinct is an excellent skill for developers, particularly during a technical interview, but there are other ways to develop technical instinct, such as experience. Technical instinct is not a requirement at any step of the career ladder. On the job, thinking slow and planning collaboratively and carefully in a way that integrates system-level, social, and low-level concerns is a key skill for seniors. Having ninja reflexes for some classes of low-level problems is an optional nice-to-have.

For the move from junior to senior, here are two final pieces of advice:

1. If you feel that you are an excellent design thinker, team player, and communicator, with the behavioral interview in the bag, but you fail to interview at the senior level, then do consider reviving the leetcode repetitive grind game. Don’t adopt the mindset that “I’m a senior, I’m beyond these games.”

   
   

2. If you are a leetcode ninja but you can’t get a promotion, focus on the other things mentioned. Improve your collaboration, social behaviors, emotional intelligence, and communication, and build a backlog of anecdotes for behavioral interview use. Don’t adopt the mindset that “I’m an elite coder, I deserve a senior position.” Once the social and technical elements are both in place, consider leaving your current company for at least two reasons:

   
   

   1. You may have already built an internal professional brand as an excellent technician with minimal social ability. Changing your internal professional branding is an extremely difficult and long, often multi-year, process. Changing jobs allows you to redefine your brand immediately.

      
      

   2. Switching roles every 6-18 months is an ideal practice for career growth below the senior level anyway.