Chapter 42
Leetcode
I can see that fewer and fewer companies are using LeetCode problems during interviews.
For me, this is a good sign — because the only thing LeetCode really teaches you is to... solve LeetCode.
Okay, okay, it also helps you get a bit better at mapping (HashMapping 🥁) the right data structure to the right problem.
And while I could tolerate companies asking easy-to-mid complexity problems, asking hard backtracking is just too niche.
One of my friends works at Google now. But on his way there, another company asked him to solve a Trie problem. He failed — and that company lost a very bright and experienced engineer.
Don't get me wrong — if you have solved even one Trie problem before, it's not hard to reproduce in an interview. But if you haven't, that shouldn't be the reason to reject you.
Enough with the preamble. Let me share what you should actually do.
Do not go to LeetCode. Go to Neetcode instead. Why? Because 95% of success is applying the right algorithm and data structure to the problem. I know many people who just communicated their thinking to an interviewer but couldn't finish the code — and they still passed. Because AI can write code now. Your goal as an engineer is to find the right approach. Neetcode divides all problems by topic, so you're not grinding random problems — you're studying how to recognize patterns. It also has free video explanations with the best solutions.
Do not start coding until you know how to solve it "on paper." Think first, code second.
30–45 minutes and nothing comes to mind? Check the solution and move on. Do not stare at a blank screen for two hours. That's not practice, that's suffering.
Start with edge cases. Check for nulls, empty strings, early returns. Interviewers love this protective approach — it shows maturity.
Do not waste time on hard problems. Three mid-level problems you understood and solved are better than one hard, sophisticated problem you barely survived. And if they ask you a hard problem during an interview — they are maniacs and it's probably not worth working for them anyway.
You do not need to know all the problems. Here's the priority:
- Must know: Arrays and Maps — 70% of questions can be solved with a HashMap
- Should know: Stack, Binary Search, Two Pointers
- Good to know: LinkedLists, Trees, Priority Queue (just enough to be familiar with a heap)
- Nice to have: A couple of Backtracking problems, just so you don't panic if one shows up
Do not grind problems the night before an interview. Just revisit solutions you've already done. Don't solve — just re-read and revive the patterns in your memory. No coding, no stress.
Practice talking while coding. At home you solve in silence. In an interview you need to narrate your thinking: "I think this is a sliding window problem because we need a contiguous subarray..." This is a skill that feels unnatural and needs practice. Do at least 3–5 problems where you explain out loud as if someone is watching.
❗️ A coding interview is actually a talking interview that happens to involve code
- Know your Big-O before they ask. The moment you finish coding, say "This is O(n) time, O(n) space because of the HashMap." Do not wait for the interviewer to ask. It shows you understand what you wrote, not just that you memorized a pattern.