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 pile of them just for fun: some before my AWS interview in 2013, and after that a long run of leetcode problems, including the hard ones. Practicing makes it easier to solve problems, and reading other people's solutions widens the perspective. When you stare at enough of these puzzles, you start seeing the same patterns again and again.
And that is exactly the problem.
What Practice Actually Buys You
After solving enough of them, you realize hard problems require combining multiple approaches such as dynamic programming, sorting, and searching. At first glance it can look like a candidate thought through the solution on the spot. They didn't. They recognized it. The pattern was already filed away, left over from the fortieth variation of the same trick they saw two years ago. A hard problem doesn't measure how well someone thinks. It measures how recently they studied. 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
Hard Problems Kill the Conversation
The reason we conduct interviews is to see whether a candidate solves a given problem with some help and direction. The interview room is not a contest arena. While solving the problem, we would like to see how the candidate communicates and explains their approach. If we ask a hard question, we lose most of that. It's highly likely the candidate will be completely lost, and 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. We want them to communicate, but a hard problem takes longer to crack, and every one of those minutes is spent inside their own head instead of with us. In the end, we can't see how a candidate approaches the problem or communicates. We lose a big data point.
You Never Get to See Them Code
In a technical interview, we also want to see how the candidate writes code. We would like to know whether they can use standard functions or modules for the solution. We would also like to see how they apply language-specific conventions, name things, and handle the edge case they spot halfway through. When we ask a hard question, the candidate rushes and stops caring about any of it. If they can't figure out a solution, there is no code to look at. A blank editor tells you nothing except that the clock ran out. Hence we lose more data points, simply because solving a hard problem and writing good code inside a limited amount of time are two different jobs.
What I Ask Instead
A medium problem with a twist buried in it does everything a hard one is supposed to do. The candidate gets moving in the first five minutes, which means the remaining forty are ours to spend. We can push on the data structure, hand them a nastier input, or ask them to refactor what they just wrote. The best signal I've ever gotten from an interview came from watching someone change their mind about their own solution. That never happens while someone is still hunting for one.
Engineers, Not Champions
So I don't ask hard questions. I've never asked one and I'm not planning to. If the goal is to assess thinking, don't design a test that silences thought. At this point, I'm also skeptical about companies that ask them. Do you want to hire engineers who write good code, or do you want to hire algorithm champions? Some people are both. That's luck, not a hiring strategy. We don't find out who writes good code and communicates well from a hard problem.