Originally Published on February, 2023
🕒 5 min read
I’ve been asked a lot recently about my opinion on LeetCode challenges during the interview process. My answer is simple: they're ineffective and often irrelevant.
Why? Because they’re a generic solution to a specialized problem. They don’t reflect how real engineering work happens, and more often than not, they reveal that the company doesn’t truly understand what it’s hiring for.
“You’re only saying that because you failed one!” Yes, that’s true, I once failed a LeetCode challenge. But I still got hired. Why? Because the engineer who interviewed me saw something more important: how I approached the problem, how I thought, and how I communicated. I didn’t pass the coding test, but I sure got the job.
And that’s exactly my issue with coding challenges: they miss the point. It’s like going shopping without a list, sure, you’ll come home with groceries, but you’ll probably forget the one thing you actually needed.
Glad you asked, dear reader. My interview process is intentionally simple, human-centered, and focused on real-world engineering skills. It consists of three straightforward stages:
We start with a relaxed conversation where the candidate walks me through their previous work, personal projects, and anything they’re proud of. I’m looking for genuine passion, clear thinking, and ownership, not buzzwords or rehearsed answers. This part also helps the candidate to get into a engineering focused mindset.
This is the core of the interview. Together, we look at a real or simplified codebase and work through some common bugs. The candidate doesn't write code, instead, they read it, analyze stack traces, and help guide me to a fix. I want to see how they understand code, think through problems, and collaborate in a real-world setting.
We finish with a conversation about architectural and system-level thinking. This could be about distributed systems, trade-offs, scalability, or design patterns. I care more about their thought process and adaptability than whether they can recite textbook solutions.
With this simple process, I’ve successfully screened high-performing engineers for companies like eBay, Disney, Viettel, and Uber.
Interestingly, of all the companies I’ve worked with, only one used a traditional coding challenge. The rest relied on a process similar to mine: conversational, collaborative, and based on how engineers actually work. And that’s no coincidence.
My interview process is based on what I’ve seen work at the highest levels: assessing engineers the way they actually work, not how they perform under artificial constraints.
Don’t use a hammer when you need a screwdriver.
Until next time..
- Bardur