Skip to content

Leetcode Hard

Over the years I conducted many interviews and recently I have interviewed with a couple of companies. While preparing for interviews, I solved a bunch of leetcode problems including hard ones. Practicing makes it easier to solve problems and reading the solutions of other people improves the perspective. Hard problems require combining multiple approaches such as dynamic programming, sorting, and searching. At a first glance, there’s a chance you can think through a solution for a hard problem immediately. Nevertheless, I don’t feel like this would be the case if you didn’t study such problems for a long time. Therefore, I see no benefit whatsoever in asking such questions during an interview for the reasons I will discuss in this post.

Leetcode

The reason we conduct interviews is to see whether a candidate solves a given problem with some help and direction. While solving the problem we would like to see how the candidate communicates and explains his/her approach. If we ask a hard question, we lose many of these. It’s highly likely that the candidate would be completely lost with the question. When people are lost, it’s harder to give feedback or direction. Moreover, the candidate might go silent to think about a solution to the problem. We want them to communicate but a hard problem would take more time for someone to come up with a solution. In the end, we can’t see how a candidate approaches the problem or communicates. Thus, we lose a big data point.

In a technical interview, we also want to see how the candidate code. We would like to know whether they can use standard functions or modules for the solution. Moreover, we would like to see how the candidate applies language-specific conventions. When we ask a hard question, it’s possible that the candidate would rush and couldn’t focus on writing good code. If they can’t figure out a solution, they won’t be able to write any code. Hence, we again lose many data points simply because it’s hard to solve the problem and write good code with a limited amount of time.

In consequence, I don’t see any benefit of asking a hard question to a candidate. I’ve never asked once and I’m not planning to ask anyone. At this point, I’m also skeptical about companies which ask such questions. Do you want to hire engineers who write good code or do you want to hire algorithm champions? There’s a chance someone can be both but I would like to concentrate on the former.

Oh hi there 👋 It’s nice to meet you.

Sign up to receive awesome content in your inbox, every month.

We don’t spam!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.