The problem (other than your casual insults) is that leetcode does not demonstrate the ability to conceive, plan, structure, or write code. The whole method behind it is nothing but rote memorization of trivia questions, almost all of which are pulled from one or two websites. There are piles of books made specifically to help people memorize the solutions to these puzzles. This has nothing to do with actual software engineering work which very rarely involves rote memorization.
A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.
When the OP gives any kind of examples of interviews gone bad, maybe we can discuss something meaningful. But the moment someone says they object to programming challenges that aren't "practical", that raises huge red flags. Too too too many people call simple programming demonstrations "irrelevant" and "impractical" and "not realistic" and "leetcode" and then proceed to show that their brains are mush, that they lack the talent for understanding code and what it's doing and why it was written and how to write it themselves. It's a meme at this point for people who call themselves software engineers to complain about being asked to write code because they're above it while simultaneously being terrible at it.
A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it.
Hard disagree. It's far too easy for people to talk about concepts without having a brain that understands code well. That's the difference between knowledge and talent. A talking approach may find knowledge. I'm looking for talent.
Comments
The problem (other than your casual insults) is that leetcode does not demonstrate the ability to conceive, plan, structure, or write code. The whole method behind it is nothing but rote memorization of trivia questions, almost all of which are pulled from one or two websites. There are piles of books made specifically to help people memorize the solutions to these puzzles. This has nothing to do with actual software engineering work which very rarely involves rote memorization.
A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.
When the OP gives any kind of examples of interviews gone bad, maybe we can discuss something meaningful. But the moment someone says they object to programming challenges that aren't "practical", that raises huge red flags. Too too too many people call simple programming demonstrations "irrelevant" and "impractical" and "not realistic" and "leetcode" and then proceed to show that their brains are mush, that they lack the talent for understanding code and what it's doing and why it was written and how to write it themselves. It's a meme at this point for people who call themselves software engineers to complain about being asked to write code because they're above it while simultaneously being terrible at it.
Hard disagree. It's far too easy for people to talk about concepts without having a brain that understands code well. That's the difference between knowledge and talent. A talking approach may find knowledge. I'm looking for talent.
"design of a system"
The open-ended system design interview comes after the initial leetcode interview now.