Unpopular opinion: Leetcode interviews are filtering out the best startup engineers
The engineers who built the most impressive things I've seen never practiced Leetcode.
They learned by shipping.
They debugged at midnight. They read someone else's broken code and fixed it. They reverse-engineered systems nobody documented. They optimized something 40% faster because it was slow and that bothered them.
None of that shows up in a binary search question.
Startups especially can't afford this mistake.
You don't need someone who can invert a binary tree in 20 minutes.
You need someone who will stay until the problem is solved, figure out what they don't know, and ship something real by Friday.
Those two people are almost never the same person.
I get why big companies use it. It scales screening.
But for a 5-person startup copying the same playbook?
You're optimizing for the wrong signal entirely.
The best hire I've seen for an early stage company was someone with a portfolio of things they built, zero competitive programming experience, and a genuine inability to leave a problem unsolved.
That's the filter that actually works.
What do you think? Am I wrong?
Agreed for early-stage. Timed algorithm puzzles optimize for a different job than "ship ambiguous work under constraints."
What I've seen work better for startups:
LeetCode still has a place when you need to screen 500+ applicants cheaply. For a 10-person team hiring one engineer, a portfolio + work sample usually tells you more in two hours than a puzzle does in forty minutes.
The hard part is staying consistent so "portfolio review" doesn't become vibes-based hiring.
I agree that LeetCode is usually a weak proxy for early-stage work, but I’d be careful with “stays until the problem is solved” as the replacement. That can reward burnout and stubbornness when a startup often needs someone who knows when to simplify, ask for help, or stop solving the wrong problem.
Portfolios are useful too, but they can hide team contribution and favour people with spare time to build polished side projects.
I reckon the best filter is a small paid work sample taken from the company’s actual environment: unfamiliar code, an incomplete bug report, a few trade-offs, and a time limit. Watch how the person investigates, communicates uncertainty, chooses scope and leaves the code. That tests startup engineering more directly than either a binary tree or a heroic shipping story.