45
loading...
How to shortcut the Leetcode grind
I'm a professional technical interview coach, and Leetcode-style interviews aren't going away any time soon. There IS a way to shortcut the process of grinding hundreds upon hundreds of challenges. Here are my favorite tips.
I outline a lot of notes and ideas in a 90-minute YouTube video on the subject, but wanted to write them up here as well to help others.
There are good platforms out there such as intervieiwng.io and Pramp. For disclosure, I'm an interviewer on IIO, and my promo code for Pramp was in exchange for some blogging I did on their platform a few years ago.
Without a good coach, it's hard to get better. Grinding on leetcode problems won't tell you what you're doing well, or things to improve, unless someone can guide you along the way.
Get on a platform where you can be given some direct feedback on what you're doing well and where you need to improve.
Nver jump straight into coding when given a technical challenge. Always break the problem down into smaller pieces to solve, and ask clarifying questions along the way.
Pseudocode should be written like a food recipe:
"crack an egg in a bowl"
I'm not telling you how to crack the egg, where to tap the egg, how to hold the egg, how hard to tap the egg. I'm going to presume that (a) you know how to crack an egg, and (b) through your own experience you know the best way to crack the egg for this kind of recipe.
By keeping the pseudocode really high-level in this fashion, you're not locking yourself into an implementation. If you write down "for loop over the array" then you've locked yourself into an implementation to strictly use a "for" loop.
Your pseudocode should be flexible enough to give you the ability to change your mind on "how". As an interviewer, I can ask questions about how you MIGHT implement something, but your steps should remain high level.
Start vague, add more detail, but if you've added so much detail that you've locked in your implementation, you might want to back up a bit.
Okay, leetcode.com. I appreciate their platform more than others because of the discussion forum for each problem, and because they give you actionable feedback when you run your code to see what didn't work based on inputs and expected output and actual output.
Next, we're going to use Sean Prashad's awesome Leetcode Patterns site. From here we're going to pick any category of problem, say "DFS" (Depth First Search), and then pick any of those problems at random.
From here we'll visit the discussion forum for that problem -- the link will usually look like "Discuss (999+)".
By using languages you don't know it will force you into higher-level thinking like "okay, they're passing a parameter called 'menu', and I see they're doing a 'for' loop with that parameter, so I'm going to write down 'loop over menu' as my instruction."
If you look at an answer in a language you DO know, you can certainly write down your pseducodeo quicker because you'll have a better idea what's happening, but you're (a) more likely to lock yourself into an implementation, and (b) more likely to memorize the SYNTAX, where we're here to learn the STRATEGY.
Once you have pseudocode written out for 4 or 5 answers, compare them side by side. Highlight lines that are similar, and try to come up with a 4 to 6 line algorithm from there.
For example, if you were solving a maze, the algorithm might look like:
work until you get to an intersection
from a list of possible directions
go in that direction
repeat/recurse all of the above
rewind to previous intersection if that didn't work
if we're at the exit, we're doneStudy these often.
The next time you try a problem of this type, see whether that algorithm will work. If not, repeat step 3 for that new kind of problem.
Now that you have a condensed list of study notes, you can form a plan for studying different kinds of problems every day.
Research shows that repeating something 2 days later and 3 days later is optimal for long-term memory. PROVIDED that you start over from nothing. Don't review old notes, don't review pseudocode, start all over again.
Come up with a calendar where you try a new kind of problem every day, and then sprinkle in when you can repeat a previous problem.
I give some examples of this in my YouTube video around the 48-minute mark, but could look something like this:
Sun: DFS-1
Mon: Heap-1
Tue: BFS-1, repeat DFS-1
Wed: DP-1, repeat Heap-1
Thu: DFS-2, repeat BFS-1
Fri: Array-1, repeat DP-1, repeat DFS-1
Sat: break day
Sun: F&S Ptr, repeat DFS-2, repeat DP-1
Mon: etc etcI have two DFS problems on this schedule because maybe the company where I'm interviewing is more likely to ask DFS-style questions.
I describe the "break day" in the video. It's important to let our brain rest, and to take time to just analyze problems for the "type" of problem it may be. This will help you more quickly identify a leetcode-type challenge in a real interview.
To sum it all up: practicing mock interviews with someone else is the best way to get feedback. Without feedback you're not going to get better as quickly.
Next, learn the algorithms by studying how other people have solved particular kinds of challenges. Condense them into very concise steps, and study those.
Finally, come up with a regular schedule for studying different kinds of problems every day, and repeating them. Add the same kind of problem in the mix more often if you think the company is more likely to ask that kind of problem.
I stream every Sunday and Thursday on Twitch around topics of technical interview prep. Come by and check out the stream, chat and say hello and ask questions. I also do live resume reviews on Sundays. The link above will give you all of the info you need.
45