Leetcode Interviews - Thoughts

So this has turned out to be somewhat of a controversial subject. Some of the most heated discussions I've had with peers have been on this very topic. "Leetcode" style interviews for senior engineering candidates (think architects, staff engineers, etc). I've been on both sides of the table in many interviews, delivering and participating in these coding exercises. These are my thoughts...

The Disconnect

Coding exercises fundamentally fail to evaluate what actually matters most in senior engineering roles. These positions require system design expertise, architectural decision-making capabilities, and deep understanding of engineering practices - none of which are demonstrated by implementing a binary search tree, creating a tic-tac-toe game, or solving random, dynamic programming puzzles.

What We're Actually Testing

When we ask senior engineers to complete coding exercises, we're testing:

• Algorithm memorization - tests are often recycled and recruiters are regularly prepping candidates.
• Performance under artificial pressure - this is very real. How many times have you coded with someone looking over your shoulder and stumbled?
• Skills rarely used in day-to-day work - especially since these are typically the easiest to solve using LLMs, Stack Overflow, or "just google it".

Instead, we should be evaluating:

• Design capabilities - the thought process in designing systems they build and not specific algorithms.
• Critical thinking - do they question the approach from all levels, even going as far as asking "should this even be built at all?"
• Understanding the unstated or non-functional requirements - not just building based on blueprints handed to them.
• Leadership and mentoring abilities - people at this level should be able to teach and grow those around them - not just junior engineers.
• People skills - the biggest of all! Do you ever ask yourself "is this someone I really want to work with?"

The Cost of This Approach

This interview practice has some major downsides:

First, it drives away experienced candidates. Senior engineers with proven track records often decline to participate in processes requiring leetcode preparation, viewing it as disrespectful of their experience and time. Personally, I will decline the interview if this is a requirement.

Second, it provides false negatives. Strong senior engineers who excel at building complex systems may perform poorly in artificial coding exercises simply because they spend their time solving real engineering problems. We risk hiring really great people that could really solve some of our personnel gaps simply because they may have struggled with something that we'll probably never ask them to do once they are hired.

Third, it creates a misleading picture of the role. Success at coding puzzles doesn't correlate with performance in senior engineering roles, where system design and engineering judgment matter more than algorithm implementation. Setting expectations of the actual role they would be filling is key to success early on. We get to find out, from both sides, if this is a good fit.

Better Alternatives

Instead of coding exercises, we should consider some of these examples:

Technical discussions about past projects, focusing on:

• Design decisions and their outcomes
• Challenges encountered and how they were overcome
• Trade-offs considered - the why
• System evolution over time and lessons learned

System design discussions that evaluate:

• Approach to gathering requirements and other interactions with stakeholders
• Consideration of various architectural patterns
• Understanding of scalability, reliability, security, etc
• Validation of operational concerns - identifying the real needs and ensuring they're actually being addressed

Moving Forward

We need to evolve past coding exercises for senior roles. Focus on evaluating real-world engineering ability through substantive technical discussions, analyzing people and communication skills, and addressing system design problems. Spend more of your time actually talking!

For organizations still using coding exercises, consider whether you're actually measuring what matters. The best people might be the ones you're turning away.

As said earlier, this can be controversial so I'd love to discuss in the comments below!