Where I work, we have a really just absolutely radical hiring process.
We sit the candidate down, and present them with a task. Then we all sit down as a team and work the problem. The most recent one was building a game of marbles. None of us knew the rules of marbles, but the candidate knew how to take a vague task and work with the team to produce something functional.
Which is what the job is. We ask the candidate to show us that they can do the job and then hire whoever 1) did the best work and 2) vibed with the team.
Anyone who places real value on leetcode is not someone who should be managing programmers because that's not the job. In precisely zero real-world situations does any programmer need to be able to write a red/black tree blindfolded on a whiteboard standing on one leg and signing the national anthem. In the real world you just grab the algorithm out of a book or stack overflow.
Exactly. I get why interviewers want some sort of "can they code" filter. The test can be extremely simple though. If knowing data structures and algorithms were by heart was so central to every developer's work, then they wouldn't be interview questions.
We sit the candidate down, and present them with a task. Then we all sit down as a team and work the problem. The most recent one was building a game of marbles. None of us knew the rules of marbles, but the candidate knew how to take a vague task and work with the team to produce something functional.
Which is what the job is. We ask the candidate to show us that they can do the job and then hire whoever 1) did the best work and 2) vibed with the team.
Anyone who places real value on leetcode is not someone who should be managing programmers because that's not the job. In precisely zero real-world situations does any programmer need to be able to write a red/black tree blindfolded on a whiteboard standing on one leg and signing the national anthem. In the real world you just grab the algorithm out of a book or stack overflow.