Things that I find more interesting in a candidate:
- Can structure modular code
- Writes testable code; knows _how_ to test code
- Clear communication
- Good documentation
- Can read, work around, and isolate janky code
- Understands higher order concepts and structural organization of code (class and inheritance hierarchies in OOP for example; lambas and closures in FP)
- Shows a sense of curiosity and eagerness to learn
What's the appeal of leetcode interviews? If you or your team have used them as a primary filter, did it work out?
In short, "it gives some signal, it's easy, it requires less infra, and it's common so people won't criticize you for it".
- It gives some signal: I can generally rule out people who are clearly unable to write basic code (loops, good variable names, not getting lost while retracing code). In my experience, this camp accounts for some 80%+ of the people coming in for interviews, even at Google.
- It's easy: the up-front costs of asking a Leetcode-type question are low. As an interviewer, I can prepare for such an interview well with 2-3 hours of question searching and an hour or so of doing the question myself. Contrast this with "closer to real" interview questions, where you may create an entire "fake project" for candidates to work in which may get leaked. It could easily take 10-20 hours to think of a "right size project" with natural extensions for candidates, which is an eternity as a hiring manager that's hiring because they're strapped for time
- It requires less infra: you don't need any sort of "shared environment to see and run code", timers to ensure that people don't spend too long on take home questions. All you need is a shared notepad or white board
- It's common so people won't criticize you for it: "Nobody ever got fired for choosing Microsoft". These types of things have a self-perpetuating nature where people cargo cult what works for large successful companies.
I don't at all endorse asking these types of interview questions and agree that there are better ones, but I do think it's important to acknowledge there are real reasons why they get asked.
The other challenge is that most jobs don't need you to be that great of a developer they need you to be a decent developer and then it wouldn't matter if your Donald Knuth or Donald Rumsfeld you can perform within expectations.
So there isn't an easy way to really determine whether or not some produces lasting good work in a reasonable way in an interview, and you don't really need rockstar so much as you need people that can perform the minimum.
So you get crazy ideas that certain companies use and can use because they are making money hand over fist,and everyone assumes since that company is making so much money and hire people like that, that must be why they are making so much money, so they copy it in a cargo cult management fashion.
And if you think the leetcode is bad it at least has a tangential relation to development. You should've seen things back in the MS years when you'd have people ask you with a straight face "how many ice cream shops are in San Francisco?" "How many marbles can I fit in a bus?" "How many fields could our team fertilize using only what is produced in staff meetings?"
Stuff like that is even more annoying.
Google also had an initial product which was primarily based around having a really good algorithm. Actually, several of their top early internal products also were about solving difficult problems with interesting and novel algorithms -- which gave them a huge bias in terms of what they were seeking.
Of course, at Google's scale and popularity, books were literally published about their interviews and both how to pass them and how great they were -- so naturally others who either were or wanted to be top-of-market adopted similar strategies. Lots of top companies also had Ex-Googler founders or early hires, which helped perpetuate the familiar structures throughout the industry.
For myself, I really dislike leetcode-style interviews. I think there is some value in asking, say, two different leetcode easy problems to verify that the candidate can produce reasonable code samples, and that they can express their ideas in code (and hopefully, also, verbally either while they code or in response to probing questions from the interviewer).