10 techniques to pass 90% of algorithmic interviews
Learnings from my long-overdue LeetCode grind
In my 10ish years of experience (always round up), I’ve so far managed to deftly flit between startups with under-developed hiring processes. I’m a master of slipping through the cracks and convincing entrepreneurs that I’m hot sh*t at iOS.
What I’m trying to say is, I’ve managed to avoid actually learning how to answer algorithmic technical interview questions, a.k.a. LeetCode.
Many people consider LeetCode to be the “highest ROI activity in tech”. This is because it unlocks the door to big American tech companies that typically pay way better than everyone else.
Why does this filter have zero bearing on day-to-day work in a tech job?
And why do these companies all support have the same hiring process?
LeetCode enforces a minimum competency bar.
LeetCode interviews help avoid “false positives”. Big tech is optimising to avoid bad hires, at the expense of rejecting some good candidates. LeetCode provides a very standardised way to discover if a candidate can perform a moderately complex coding task under time pressure.LeetCode selects for people willing to endure an arbitrary grind.
(You aren’t meant to say this bit out loud).
In economics, LeetCode is called “costly signalling”. People who grind LeetCode to land a job are probably conscientious, have a high tolerance for bureaucracy, and will happily sacrifice their free time for career advancement.
As big tech hiring scaled up, and everyone wanted to cargo-cult Google, the mythical “algorithmic challenge” devolved into a cookie-cutter exercise, where candidates pretend to be a secret genius improvising a novel solution as they go*.
*Top tip: don’t actually refer to this as “kayfabe” during your LeetCode interview”
LeetCode was a moderately embarrassing weakness I’d failed to address, until now.
It wasn’t for lack of trying!
I halfheartedly started LeetCoding a few years ago, but after sinking in a few commutes into Two Sum and Valid Parenthesis, decided it’d be more interesting to focus on my blog.
In retrospect, perhaps that was a good decision.
I’m meandering. “Can you get to the damn point?”, I hear you ask from the future.
Big tech devs (mostly) aren’t geniuses. They’re pattern-recognition machines.
LeetCode is purely an exercise in pattern recognition.
The same ~10 patterns, over and over. In various configurations.
That’s why I can legitimately tell you that there’s 10 techniques that will carry you through the vast majority of LeetCode interviews.
You can take my word for this as well, because I’ve got a 100% pass rate on the 4-5 legit LeetCode interview loops I’ve actually done, and I will not be updating this if things go badly with Snap tomorrow.
Okay so what’s on the menu today?
I’m going to demonstrate the 10 techniques that virtually every LeetCode question maps onto.
For each technique, I’ll show you a bona-fide LeetCode question that applies it, alongside my actual diary notes I wrote while trying them for the first time, so you don’t feel so alone when you do it.
Finally, I’ll give you my rough field-guide for staying sane in The Grind™. To be honest, I would recommend reading this first, because then you feel less bad during the rest of the article.
Contents
This post is super long, so your email client may cut it off. Read on my website here:
The 10 Techniques
Hashmaps
Hashmaps (a.k.a. Dictionaries) are the basic cheat code for any algorithmic question, because they offer O(1) lookups (a.k.a. constant time complexity)*.
Virtually every time I’ve done a real-life LeetCode interview, I’ll write a solution that’s messy, inefficient, but works. After verifying my code, I’ll be asked “how efficient is that?” and check the time complexity, and be gently prompted to make it more efficient**.
This is usually code for “use a hash map”.
*Sets also have constant time lookups, but you’ll use those less often.
**If you’re a better candidate than me, you can do this without being asked.
Hashmap problems take many forms. You might build a dictionary to count the frequencies of each character in a paragraph. You might use a hashmap to cache values, and efficiently check if a value has already been computed or not. You might do something clever with keys, by computing a value that you’ll need later, à-la the O.G. Two Sum problem.
The core pattern is making one pass through the input data to construct the hashmap, then another to query whatever you need. Sometimes, you can do both at the same time and exit early.
That was a lot of words. If you’re a LeetCode novice, I hope I haven’t scared you off. Here’s a nice LC Easy to cleanse the palette.
My LeetCode Diary: #383 Ransom Note
Surprisingly, I’m actually pretty good at traversing a collection and populating a dictionary. This might be the first LeetCode problem I found, dare I say, fun.
This is the classic hashmap approach, iterating through to count the characters, and traversing again to decrement and check you have enough characters for the target.
You aren’t limited to integers and characters in your hashmap either.
You can store Linked List or Tree nodes in a dictionary. This is often the solution to any “make a data structure with O(1) reads and writes” problem (see LRU Cache).
You can also place Graph edges into a dictionary for a topological sort (see Course Schedule), or just track “visited” nodes for a depth-first search (see Clone Graph).
Two pointers
This is probably my favourite technique, because I feel dead smart every time I use it.
Upgrade to unlock this article, plus much more:
🌟 Access Elite Hacks, my exclusive advanced content
🚀 Read my free articles a month before anyone else
🧵 Master concurrency with my course and advanced training
