Is NeetCode / Strivers A2Z bad?

Short answer: Yes.

The most popular advice is to start with NeetCode 150, Blind 75, Striver's A2Z, Take2Forward, CP31. People are telling me that CS students "swear by their mothers" to use Strivers A2Z in India. People have been sold the idea that by doing a set amount of problems, it is the smooth sailing pathway to a FAANG offer. Certainly, there are people who did these sheets and got big tech offers. However, in my opinion, this is mostly survivorship bias. Due to the sheer raw number of people using these sheets, and the tendency for people to spread their stories, you are statistically going to hear more success stories with these existing methods.

I want to be precise about my disagreement with platforms / sheets like this, because the problems themselves are not the issue. By doing problems, it is by nature more likely than not you are going to absorb ideas and improve. This is also not a biased judgment that oh "competitive programming is superior to LeetCode." As a source of problems these sheets are perfectly good. If used correctly they could be very efficient for learning. However, the community and advice surrounding it makes it EXTREMELY difficult to do so. For my opinionated ranking on various platforms, please check here.

Video Solutions

Video solutions are a big part of these sheets. Many even gate them behind paywalls, and people pay for specifically these video solutions.

The first issue is chronological: video solutions are long and vastly slower than reading text editorials. You are objectively wasting time in the long term by being locked into someone else's linear verbal pacing rather than parsing text at the speed of your own thoughts.

Now, the fatal flaw. When you watch someone else solve a problem, you are training yourself to reproduce their reasoning instead of generating your own. You are essentially forced to fit your brain to their specific line of derivation, regardless of what partial solution you had before. Even if you were close to correct, you are forced to trash your progress, start from zero, and watch someone else explain their thoughts.

It is proven over and over that passive learning is significantly worse than active synthesis, especially for STEM subjects. A much better approach is utilizing LLMs for targeted scaffolding. I've seen people who are completely averse to asking AI because they feel like they're "cheating" themselves, yet they will willingly wait eight hours to ask a friend, "Give me the answer pls". You are only cheating if you are deceiving yourself about whether you actually understood the core mechanics of the solution. AI is a 24/7 coach if you use it to protect your active thinking state.

Instead, you could ask an LLM something like this:

hey my current idea is X and I've tried Y approaches, without spoiling the answer, give me the minimal hint such that I could solve it myself.

Using an LLM for selective hints acts as a form of instructional scaffolding within the Zone of Proximal Development (ZPD), a framework from Lev Vygotsky where a learner is given just enough targeted support to solve a problem that is slightly beyond their current independent ability.

Plenty of such videos are even worse than passive learning because they actively reinforce the wrong habits. A perfect example is the video NeetCode LIS. This is another reason why we don't recommend NeetCode, not due to a total lack of effort on his part, but because his lack of depth is masked by a good reputation, meaning most people just applaud his content blindly without knowing any better.

To give you a summary of that video, half of it is spent on an O(2^n) brute force and DFS with cache solution, which is a very unconventional thing to dwell on for LIS because it is not even natural to think about. Then he explains the standard O(n^2) dynamic programming approach. Then finally, he completely glosses over the most important and optimal O(n log n) solution. To top it off, he says "I really doubt your interviewer is going to expect you to get this without a hint; if they do I'd just walk out of the room".

That is pure incompetence. I'll give him the benefit of the doubt because this is back during COVID hiring. It really IS that easy back then, but not anymore. If you have learned the optimal solution and an interviewer asks you about it, don't you think that is the absolute best opportunity to stand out and separate yourself from all the other candidates grinding the same exact sheets? You are essentially 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 this bad habit 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 very difficult to undo. 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. The green accepted status on a submission screen gives a quick dopamine hit, but it is completely empty if you just transcribed it from a video playback.

Goodhart's Law and Metric Fixation

The culture that grows around these platforms is its own structural disaster. The environment completely shifts the goal from understanding systems to maximizing empty metrics. This is a textbook manifestation of Goodhart's Law:

When a measure becomes a target, it ceases to be a good measure.

LeetCode and its community heavily gamify the grind with badges, daily streaks and problems, and problems solved counters, pushing people to optimize for the count rather than the skill. Beginners end up solving fifty variations of the same trivial problem or copy pasting solutions just to keep a virtual number alive. Sure, WhiteBox also has quests, but our community does not actively push you towards it.

When the primary target becomes changing a number on a dashboard from 100 to 150, the depth of learning is completely compromised. People stop asking themselves whether they can handle an arbitrary tree constraint and start checking whether they can get the green checkmark as fast as possible. This is precisely why we must take contest rating into account. People should be looking at the ratio between contest rating & problems solved to determine a person's skill level.

In my opinion, this dynamic we're seeing is the computer science equivalent of Duolingo. It is built entirely around behavioral hooks, flashing lights, and streaks designed to keep you clicking, while completely insulating you from the deep, agonizing cognitive friction required to actually master the domain. Just like someone who spends three years maintaining a 1000 day streak on Duolingo still cannot hold a fluid, unscripted conversation with a native speaker, a student who grinds 500 LeetCode dailies will completely freeze the moment they are dropped onto an unseen problem under time pressure. Anyone who actually wants to be exceptional at language learning dumps the app and forces themselves to read real books and speak with real humans; anyone who wants to build actual software engineering / DSA mastery dumps the daily gamification and forces themselves into the solitary, uncomfortable labor of unscripted problem derivation. If you let a streak counter dictate your intellectual schedule, you are letting an engagement loop talk you out of thinking (Why am I not improving?).

The Dunning Kruger Effect and Fake Fluency

This metric fixation feeds directly into the Dunning Kruger effect, breeding an epidemic of fake fluency. When you rely on prepackaged sheets, your brain mistakes post hoc recognition for independent mastery. This is exactly the well known behavioral effect called the "illusion of competence". Because a video explanation makes sense after the fact, or because you successfully transcribed code to secure a green "Accepted" checkmark, your ego inflates. You trick yourself into believing you have built fluency, when in reality you have just completed a glorified typing test.

To fix this, here is something LGM maspy told me.

Instead of stopping at the level of "I kind of feel like I understand it," I think you should consciously try to increase the number of things you can properly explain with confidence.

Being able to teach someone about a problem you just did / a concept you just learned or being able to re-implement it knowing why each line works the way it does is a good way to verify your understanding.

Unqualified Editorials & Coaches

In my opinion, NeetCode is not qualified to teach DSA in 2026. Hot take, I know.

Whenever I bring this up, people defend NeetCode with a version of the "coaches don't play" line, as if a teacher's own skill has nothing to do with how well they can teach derivation. I've been told countless times that I "simply don't get it" and that NeetCode is an excellent teacher who cleared up all their doubts. So let me ask: have you actually tried anything else? 99% of the time the person has only ever used NeetCode and still jumps to defend him. I've tried over 20 platforms and built my own before reaching this conclusion.

NeetCode's skill level shows it: his LeetCode contest rating sits below the median active contestant if you consider ghost accounts (at around 1750), topping out at 0-2 problems per contest back in 2021 (which is much easier!). Not to mention the extremely outdated videos and roadmap. He's also out of touch with the 2026 interview scene, since he has not interviewed in years. Yet his massive internet reputation completely masks his lack of structural depth. Endlesscheng, a Chinese DSA educator is top 10 globally on Leetcode, was 3500 rated, top 0.01%, masters on codeforces, and solved over 10000 problems. Solved every problem on leetcode with multiple languages, and wrote editorials for all of them, FOR FREE.

I genuinely think you'd be better off learning from google translating or AI translating his editorials, over learning from Neetcode's solutions. This is how unbelievably huge the skill difference is.

Are we seeing the comparison here? I've had the pleasure of joining several Asia based Leetcode servers. Most people there are also studying for interviews, for FAANG. These servers, despite people coming from different backgrounds, many not even CS, most people are able to reach guardian, or at minimum 2000 leetcode rating, which is top 2% within 6 months. One particular server, almost every week, someone was landing their dream job at FAANG. I think don't have to elaborate why.

LeetCode's editorial section is also polluted with AI slop. You click into the top rated text solutions, and it's some "FASTEST SOLUTION 100% GUARANTEED TO UNDERSTAND". You are greeted by a Sung Jin-woo or Ayanokoji anime picture with a caption saying "Upvote plz". These engagement farmers push code packed with comments for every line, unreadable macro heavy shortcuts, bad implementation. Beginners swallow these terrible paradigms whole, mistaking viral forum engagement for actual technical competence.

Herd Mentality and Productive Procrastination

This toxic herd mentality manifests clearly in how the community attempts to organize. People are forever spinning up Discord servers and Telegram channels to "grow and learn together." 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 single one was dead inside a week. That is not bad luck; it is productive procrastination. Joining a study group feels like work. Collecting roadmap PDFs, bookmarking Notion templates, and talking about the grind feels like progress. People surround themselves with a herd of anxious peers precisely to avoid the cold, quiet discomfort of sitting alone with a difficult problem and failing for two hours straight. Once the roadmap motivation burns out, the room goes silent, and you pick up that passive, low agency behavior whether you notice it or not.

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 belief that a static sheet is the fast path when you are short on time is another delusion that 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. 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. 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.