Unpopular opinion: The technical interview, as most companies practice it today, is not a test of engineering ability. It's a test of how well you studied for the test.
Let's stop pretending otherwise.
What's Actually Broken
The standard coding interview loop goes something like this: a stranger gives you a graph traversal problem you haven't thought about since college, you're expected to solve it optimally while talking out loud, on a whiteboard or shared editor, with a clock ticking and your future employment hanging in the balance.
That's not an engineering challenge. That's a game show.
The Memorization Trap
LeetCode has become an industry unto itself — premium subscriptions, "blind 75" cheat sheets, YouTube channels dedicated entirely to pattern-grinding. Engineers spend hundreds of hours memorizing solutions to problems they will never encounter on the job.
And if you haven't done the prep recently? Doesn't matter how many production systems you've shipped. You're going home.
The signal being measured isn't engineering skill. It's proximity to studying.
Unrealistic by Design
When was the last time you:
- Implemented a red-black tree from scratch at work?
- Reversed a linked list under a 20-minute time constraint?
- Solved a dynamic programming problem without Stack Overflow?
If your answer is "never" — congratulations, you're a normal software engineer.
Real engineering involves reading documentation, searching for prior art, asking teammates, iterating on messy problems over days — not weeks. The whiteboard strips all of that away and replaces it with a performance ritual.
Stress as a Feature (Not a Bug)
Proponents of high-pressure interviews often argue: "We want to see how you perform under pressure."
Sure. But the pressure of debugging a production incident at 2 AM is fundamentally different from the pressure of inverting a binary tree in front of a stranger who's silently judging your variable names.
One is real. The other is theater.
The Randomness Problem
Ask any engineer who's gone through multiple rounds of technical hiring and they'll tell you: it's inconsistent. The same candidate can ace one company's loop and bomb another's — not because their skills changed, but because the problems and interviewers did.
That's not a signal. That's noise masquerading as rigor.
The Industry Reality
Here's what a senior engineer's actual day looks like:
- Reading a PR and leaving thoughtful comments
- Debugging a service that's behaving weirdly in prod
- Scoping a feature with incomplete requirements
- Refactoring code someone wrote three years ago with no docs
- Writing a design doc, getting it torn apart, revising it
Notice what's not on that list? Implementing Dijkstra's algorithm from memory.
The gap between what interviews test and what engineers actually do isn't a crack. It's a canyon.
Who It Hurts Most
Junior Developers
For juniors, the LeetCode gauntlet is brutal. They haven't had years to accumulate systems intuition, so they're reduced entirely to algorithmic prep. A junior who spent six months building a real, deployed product gets filtered out by a junior who spent six months grinding hard problems. That's not meritocracy — it's a different kind of memorization test.
Self-Taught Engineers
Bootcamp grads and self-taught devs often have strong practical skills — they've shipped things, debugged real issues, learned by doing. But they're disproportionately disadvantaged by a system that rewards CS fundamentals trivia. The interview loop quietly (sometimes not so quietly) filters for pedigree.
Experienced Engineers
Ironically, senior engineers can fail these interviews too. They've spent years building expertise in solving actual problems — which means they haven't been rehearsing interview patterns. A Staff Engineer with a decade of distributed systems experience might blank on the "correct" way to implement a trie. The interview doesn't care about the distributed systems.
What Should Replace It
Good news: there are better ways. Companies that have ditched the standard loop report better hires, more diverse teams, and candidates who actually want to work there.
Take-Home Projects (Done Right)
Assign a small, realistic problem relevant to the role. A backend candidate might build a simple REST API. A frontend engineer might implement a UI component with defined behavior.
The rules:
- Keep it scoped to 3–4 hours max — not a week-long unpaid sprint
- Review the code in a follow-up conversation, not just the output
- Make it open-ended enough to reveal how people think, not just whether they got the right answer
Pair Programming Sessions
Give the candidate a real (or realistic) codebase and work through a problem together. Watch how they read unfamiliar code. See how they ask questions. Notice if they communicate tradeoffs.
This mirrors actual work far more accurately than a whiteboard ever could.
Code Review Discussions
Hand them a PR with intentional flaws — maybe a subtle bug, maybe a design smell, maybe just some style inconsistency. Ask them to review it as if they were the assigned reviewer.
This tests: communication, technical judgment, attention to detail, and professional tone. All things that actually matter.
Real-World Debugging
Share a failing test or a broken endpoint. Give them the repo, the error message, and time. Watch how they navigate the unknown.
Because navigating the unknown is the job.
Portfolio-Based Hiring
For candidates with a body of work — open source contributions, personal projects, professional work they can discuss — let the work speak. A structured conversation about something they built tells you more than a contrived algorithm ever will.
What Good Interviews Actually Look Like
Here's a framework worth stealing:
✓ Is it realistic?
Does it resemble something they'd actually do in the role?
✓ Is the environment fair?
Do they have access to documentation, a real editor, the internet?
✓ Are you evaluating thinking or trivia?
Can you see how they approach problems, not just whether they solve them?
✓ Is there a conversation?
The best interviews are collaborative, not interrogative.
✓ Is it consistent across candidates?
Same problem, same rubric, same environment — or your comparison is meaningless.
✓ Is it respectful of their time?
Take-homes over 4–5 hours without compensation are not acceptable. Full stop.
The Closing Argument
The industry built the coding interview for a world where CS graduates were scarce, software was narrow, and "can they code" was a reasonable binary question to answer. That world no longer exists.
Software engineering in 2026 is collaborative, contextual, and deeply dependent on communication, judgment, and adaptability. None of those things show up in a LeetCode hard problem.
The companies that figure this out will hire better engineers, retain them longer, and build better products. The ones that don't will keep optimizing for candidates who are good at being interviewed — which is a very specific, mostly useless skill.
The question isn't whether the coding interview is broken. It obviously is.
The question is whether your company has the intellectual honesty to admit it, and the operational will to do something different.
Most won't. But some will. And they'll have a quiet advantage that their competitors won't fully understand for a while.
Written by someone who has been on both sides of this process more times than they'd like to admit.
Top comments (1)
This resonated strongly with me.
I am also curious to know whether you would also consider assessing AI assisted development.
An example task: here is an output architecture plan generated by AI, would you accept this plan? How would you challenge it?