My take as someone with a PhD in CompSci , Bsc in Software Engineering, and with 10+ in the software dev industry my take is that Leetcode type problems suck. They are "gotcha" types of tests for which you only need to know their specific answer.
As an interviewer I learned that they don't tell me anything useful: people who show they can solve them just show that they spent months churning.
Most of the problems in Leetcode are related to CompSci theory (DP, DFS, efficient graph or tree reversal, etc). Reality in most software Engineering jobs couldn't be further away from the that. Even if you are working with C, you'll likely use Boost or a similar library to solve a problem that requires any of that (implementing your own low level libraries is a sign that you are a jr dev... I've seen lots of them trying to implement their email validation fn or similar).
Exactly. I think it is reasonable to ask candidates to demonstrate basic programming competency, but "gotcha" questions are terrible.
Consider the interview question: "Write a function that can detect a cycle in a linked list."
> Between 1955 and 1967, the problem of “how do we determine if there is a cycle in a linked list without modifying the list or using an extra memory” was a essentially an open problem. Meaning, any number of PhD candidates in Mathematics or Computer Science could have written about it as part of their dissertation. With all of those hundreds and hundreds of minds, this problem remained open for 12 years.
> Do you honestly think you could, in a twenty minute interview, from scratch, come up with the solution to a problem that remained open in the field for 12 years, all under a pressure far more intense than any academic? Seems pretty damn unlikely, the only reason you think you could do so is that you’ve heard the answer before, and it seems obvious and simple in retrospect. In other words, “a-ha!”
While I agree that this is an example of a particularly ridiculous interview problem, and "gotcha" type interview problems are bad in general, I don't think it's accurate to say it was an open problem for 12 years. An open problem is one that has been posed but unsolved. In this case, the invention of the linked-list data structure in 1955 does not mean anyone had actually posed the problem of cycle-finding. It's possible, even probable, that the problem hadn't been seriously considered until Floyd did so and came up with the algorithm he published in 1967.
OTOH, if you've never done a few of those problems, you won't even know it's called a cycle, why they're bad, how to avoid them or find the library. There is usefulness in knowing the basics, and one way to know if your candidate knows, is by taking a look at the problems he/she tackled, or the courses taken. I agree it's a problem most devs won't encounter.
But that interest in the technical/algorithmic side of programming has turned into a paid job competition board ... I'm baffled.
Knowing that someone has the ability to grind leetcode for a few months is a pretty good signal of high conscientiousness. That's useful.
If they can use what they learned to solve variations on the problems they previously solved it's probably a good signal of above average intelligence. That's also useful.
Funny thing is I had an interview some years ago and he asked me about cycle detection, so I gave the basic set approach, then added the tortoise and hare as a memory free solution.
It immediately made him uncomfortable and I didn't get the job, because he didn't like the tortoise and hare solution not being as "tractable" as the set solution.
As an interviewer I learned that they don't tell me anything useful: people who show they can solve them just show that they spent months churning.
Most of the problems in Leetcode are related to CompSci theory (DP, DFS, efficient graph or tree reversal, etc). Reality in most software Engineering jobs couldn't be further away from the that. Even if you are working with C, you'll likely use Boost or a similar library to solve a problem that requires any of that (implementing your own low level libraries is a sign that you are a jr dev... I've seen lots of them trying to implement their email validation fn or similar).