We Don't Do Leetcode Interviews (And We Get Better Engineers)

Here’s what our interview process doesn’t include: whiteboards, algorithm puzzles, system design questions about designing Twitter, take-home assignments that take 20 hours, or live coding sessions where someone watches you type while you sweat through FizzBuzz variations.

We’ve never asked a candidate to reverse a linked list. We’ve never asked anyone to find the optimal path through a graph. We’ve never tested Big O notation knowledge. And in three years of hiring this way, we’ve made zero bad hires.

Zero.

What Leetcode Actually Tests

Leetcode interviews test one thing: whether someone has practiced Leetcode. That’s it. A developer who spent three months grinding problems on Leetcode will outperform a developer with 15 years of shipping experience — in a Leetcode interview. And then they’ll join your team and struggle to write a clean database migration or debug a CSS layout issue, because those skills have nothing to do with dynamic programming.

The entire system is backwards. You’re filtering for people who are good at interviews instead of people who are good at the job. Google figured this out years ago when they studied whether interview performance predicted job performance. The correlation was nearly zero. They published the data. And then most of the industry kept doing Leetcode interviews anyway.

How We Actually Hire

Our process has three steps:

Step 1: A conversation. Not a “behavioral interview” with STAR-format questions. An actual conversation. What have you built? What are you proud of? What’s the hardest bug you’ve debugged? What do you want to work on? This takes 45 minutes and tells us more than any algorithm test ever could.

Step 2: A paid trial project. This is the core of our process. We give candidates a real piece of work from our actual backlog. Not a toy problem — a genuine feature or bugfix that Miru needs. They work on it for 2-3 days, at their own pace, on their own schedule. And we pay them for it. Market rate. Because asking someone to do real work for free is exploitative, full stop.

During the trial, we’re watching for the things that actually matter: Do they ask good questions? Do they communicate progress? Do they write code that other humans can read? Do they think about edge cases? Do they care about the user, or just the implementation?

Step 3: A team conversation. The candidate talks with 2-3 people they’d work with daily. Not another grilling session. Just: do we want to work with this person? Do they want to work with us? Culture fit matters, but not the way most companies think. We’re not looking for “culture fit” as in “went to the same school and likes the same beer.” We’re looking for: do they communicate well, do they take ownership, and are they kind?

The Results

Three years. Fifteen hires. Zero regrets. Every single person we’ve hired through this process has shipped meaningful work within their first two weeks. Not because they’re all 10x engineers. Because we tested for the right things: shipping ability, communication, and care.

Basecamp and 37signals have been hiring this way for years. So has Shopify’s early team. The approach isn’t novel. It’s just uncommon because Leetcode interviews are easier to standardize and scale. HR departments love standardization. Engineers deserve better.

The best predictor of whether someone can do the job is watching them do the job. Everything else is theater.

If you’re hiring and you want better engineers, stop testing for algorithms. Start paying people to do real work. You’ll be shocked at how obvious the right candidates become.