In this video I break down why I don’t really “practice LeetCode” as a software engineer, even though I’ll be the first to tell you LeetCode is basically essential if you’re trying to get into big tech. LeetCode trains one specific slice of problem-solving—algorithms—and a lot of the time the problems (and especially the solutions people celebrate) don’t look like real work. In the real world you’re dealing with infrastructure constraints, team code style, readability, and long-term maintainability—not just a fancy one-liner that happens to pass. I also talk about how LeetCode feels closer to competitive math than actual software engineering. Speed and chasing runtime optimizations can create the wrong mindset when most of your job is collaborating, understanding existing patterns, and shipping changes that scale. On top of that, LeetCode barely touches the real development cycle: debugging (which is honestly a huge part of the job), meaningful testing, and dealing with ambiguity. Most real tasks start with unclear requirements, and you have to ask questions, compare approaches, and make tradeoffs across performance, stability, and maintainability. My takeaway: if your goal is to become a good software engineer, grinding LeetCode alone won’t get you there. But if your goal is to pass FAANG-style interviews, you still need to master it—just recognize it’s interview prep, not the full job.