Leetcode Is Not Engineering
LeetCode Is a Filter — Just Not for What You Think
There’s a belief in the software industry that a strong LeetCode profile means something important.
It doesn’t.
Or more precisely: it means something, just not the thing people think it means — and not the thing you want if you’re trying to hire good engineers.
This isn’t a beginner’s take. This is the perspective you arrive at after you’ve shipped systems, debugged production outages, maintained legacy code, and watched well-intentioned abstractions rot in real time.
What LeetCode Actually Measures
LeetCode is very good at measuring a narrow set of skills:
- Tolerance for artificial constraints
- Willingness to grind puzzles
- Comfort re‑implementing solved problems
- Performance under contrived time pressure
- Familiarity with interview patterns
None of these are useless. But they are largely orthogonal to real-world software engineering.
What It Does Not Measure
LeetCode does not measure:
- Judgment
- Taste
- Readability
- Maintainability
- Debugging ability
- Production awareness
- Skill at choosing the right abstraction
In fact, it often penalizes these things. The moment a candidate says, “I’d use the standard library,” the exercise pushes back: No — reinvent it.
The Interview Code Smell
Review enough LeetCode solutions and the same traits appear:
- Clever control flow
- Minimal naming
- No comments
- Reinvented algorithms
- Obscured intent
This isn’t accidental. LeetCode trains people to optimize for being judged, not for being read. That habit does not stay confined to interviews.
Why Experienced Engineers Bounce Off It
Senior engineers don’t dislike LeetCode because it’s hard.
They dislike it because it’s misaligned.
Experience teaches you that:
- Libraries exist for a reason
- Clarity beats cleverness
- Maintenance dominates initial implementation
- The hardest part is deciding what not to write
LeetCode inverts those lessons. So the most experienced engineers quietly opt out.
The Filtering Problem
Here’s the uncomfortable truth:
LeetCode disproportionately filters out the people you most want.
What remains skews toward people with time to grind, people early in their careers, and people optimizing for interviews rather than long-term effectiveness.
Organizations then act surprised when systems are brittle and over‑engineered.
The False Objectivity
LeetCode feels objective. It produces scores, ranks, and pass/fail results. That makes it attractive to companies that don’t want to invest in interviewer training or nuanced evaluation.
But objectivity without relevance is just theater.
What Actually Works
The strongest hiring signals are mundane and effortful:
- Discussing real code a candidate wrote
- Reviewing a pull request together
- Debugging a realistic issue
- Talking through a design tradeoff
These approaches require time, skilled interviewers, and trust in judgment — precisely what LeetCode is often used to avoid.
Algorithms Aren’t the Enemy
Algorithms matter. But algorithms in context matter.
A good engineer knows when to use a library, when performance truly matters, when readability is the optimization, and when cleverness is a liability.
LeetCode strips away that context and then treats the remainder as the job.
Final Thought
LeetCode does not measure engineering ability.
It measures how well someone trains for LeetCode.
That may correlate with intelligence or discipline, but it does not reliably correlate with judgment, taste, or the ability to build and maintain real systems.
Using it as a primary hiring signal is not neutral. It is a deliberate choice to favor interview performance over engineering craft — and to exclude many of the people most capable of doing the actual work.
That choice may be convenient.
It is not wise.