Are the sheets holding you back?

It is common to hear that NeetCode 150, or Striver's A2Z, or one of the other big sheets is the obvious place to start, and that grinding a few hundred of their problems is the settled path to an offer. I want to be precise about my disagreement, because the problems themselves are genuinely fine, and this is not the tired complaint that the sheets are low quality or that LeetCode is beneath you. As a source of problems they are perfectly good, and doing a few more on a topic right after you learn it is exactly how they should be used. The issue was never the problems, it is the three things that sit around them, and each one quietly trains a habit that works against you for years afterward.

The first is what the video walkthroughs do to you over time. Watching someone else solve a problem trains you to reproduce their reasoning instead of generating your own, and most of these videos skip the thinking entirely and narrate only the finished solution, so the whole thing feels productive while it wires in the wrong default. Plenty of them are worse than passive, because they actively teach the wrong lesson, and a perfect example is the video NeetCode made on the longest increasing subsequence. To give you an idea of what it does, he spends about half of it on the O(2ⁿ) brute force, which is a very unconventional thing to dwell on for someone just learning this problem, then explains the standard O(n²) dynamic program, and that is basically it, because he finally glosses over the clean O(n log n) solution, the one that keeps the smallest possible tail for each length and places each element with a binary search, and says something along the lines of, "if an interviewer expected that, I'd just walk away rather than learn it." That is incompetent, and a naive thing to teach, because a solution the interviewer was not expecting is the best opportunity you have to stand out, not something to run from, and this one is easy to write the moment the idea clicks. You are shooting yourself in the foot, leaving free points on the table and handing the offer to the better-prepared candidate next to you, all so you can stay comfortably average. Why would you settle for that when slightly more effort puts you in the top five or ten percent of the room?

And it compounds, because once your first instinct on a hard problem is to go and see how somebody else approached it, rather than to work it out from the constraints in front of you, that habit is genuinely difficult to undo, and it is hardest to undo precisely when you are a beginner and it is the only habit you have ever built. You are not learning to solve problems, you are learning to follow solutions, and those are different skills that feel identical right up until you sit in front of something with no walkthrough to watch.

The second is the culture that grows around these platforms, which is its own problem entirely. The streaks, the solved counts, the state of the big subreddits, the editorials written by people who do not really understand the material, the AI-generated code farming upvotes, and the steady drip of cheating in contests all add up to an environment that rewards the wrong things, and you tend to quietly become the average of the room you spend your time in. You can see how shallow most of it runs the moment these communities try to organize themselves. People are forever spinning up Discords and Telegram groups to grow and learn together, and out of plain curiosity I once joined something like ten to twenty of them purely to socialize, which is something I genuinely enjoy, and nearly every one was dead inside a week. That is not bad luck, it is that the people in them never worked out why they were there in the first place, because they were not chasing understanding, they were following the herd, doing X because some post promised it would get them Y, collecting the exact roadmap that supposedly lands a Google Summer of Code spot or a FAANG offer. Once the roadmap is the entire motivation there is nothing left to actually talk about, so the room goes silent in a few days, and you pick that up whether you notice it or not. This matters most for beginners, because the habits you build in your first couple of months are the hardest ones to undo later, which means weak fundamentals are not a reason to start somewhere worse, but exactly the reason to start somewhere better, before bad taste has a chance to become your default. Plenty of strong engineers did come out of LeetCode and NeetCode, but that happened despite the environment rather than because of it, and it is far rarer than the people who grind for months and still cannot solve anything genuinely unfamiliar.

The third is the belief that the sheet is the fast path when you are short on time, which was true once and has quietly stopped being true. Doing the bare minimum to pass feels fast because it gets you through a single interview, but the cost simply arrives later, because you pass, you forget, and the next time you job hop or get laid off you start again from zero and re-prepare the entire thing from scratch. People who actually understand the concepts never have to do that, because the ideas have become intuitive and every future loop rests almost entirely on work they already did once. There is exactly one real exception, which is that if your interview is two weeks out and you are genuinely underprepared, then yes, cram, because pattern drilling is a perfectly good way to brush up fast when the clock is that short. But if you are a student, or a junior with some runway, there is no reason to spend your energy hunting for tricks to do as little real practice as humanly possible, since you have the time to build the thing that compounds and you should simply build it.

It is also not wasted effort outside of interviews, which people conveniently forget when they are talking themselves out of it. Real practice wires your brain to break a problem down, reason about tradeoffs, and debug faster, and all of that carries straight into real engineering, because it is a stripped-down version of the same skill rather than a separate one. And here is the uncomfortable part, which is that getting better at this is about as easy as self-improvement ever gets, since the material is standard and the feedback is instant, so if you cannot figure out how to improve at something this legible, then improving at real engineering, where the feedback is slow and the problems are ambiguous, is going to be much harder. People love to point at Linus Torvalds or George Hotz not grinding LeetCode, and sure, both of them would be terrifying at it if they ever bothered, but the mistake is reading that backwards, because you are not operating at their level of engineering, so being bad at LeetCode does not secretly mean you are cracked at the real thing, and you do not get to borrow their exemption.

All of which brings me to the ordering, since the most common version of the advice is to do A2Z or NeetCode first for the fundamentals, then LeetCode for fluency, then the harder material someday later, and that order is backwards. It front-loads the passive habits, the watch-recognize-repeat loop, and saves actual synthesis for last, when it is far harder to unlearn the habit of waiting for a pattern label than it is to never build that habit in the first place. Being weak at trees, graphs, recursion, binary search, or dynamic programming is not a reason to go run a static sheet first, because those are exactly the topics you should be learning through rated practice and deriving solutions yourself, rather than through flashcards and a video for every problem. There is nothing you need to go and finish somewhere else before you are allowed to start learning the right way.

So use the problems if you want them, because they are fine, but skip the videos, refuse to let a sheet quietly become the whole of your practice, and do not save the real reasoning for a later stage that never actually arrives. I am aware that most people will read all of this and keep doing the comfortable thing anyway, because being handed a roadmap will always be easier than learning to think for yourself, and that is a genuinely hard truth to sit with. But these guides are not written for everyone, they are written for the roughly one in ten who is already a cut above the average CS student and is willing to hear honest criticism from people who actually want them to get good, and if that is you, the move is simple: build the habit of deriving from the very first topic, take the discomfort of working it out yourself as the entire point, and start now rather than after a year spent carefully building the wrong instinct.