Over the years, I’ve been on both sides of the interview table. To become better at conducting interviews and preparing for my own, I spent time solving and reviewing coding problems. I ended up solving a bunch of problems just for fun. I did some before AWS interview in 2013. After that, I completed 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. When you stare at enough of these puzzles, you start seeing patterns that aren’t obvious to the untrained eye.

After solving some, you realize 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 H-Index example

The reason we conduct interviews is to see whether a candidate solves a given problem with some help and direction. But here’s where things start to fall apart: the interview experience is not a contest arena. 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. I’ve seen candidates freeze not because they lacked skill, but because they didn’t know what kind of answer the interviewer wanted. 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. If the goal is to assess thinking, why design a test that silences thought? 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. Real engineering is about clarity, collaboration, and the courage to ask the right questions. I don't think we get that out of hard problems.