Reciting all x86-64 opcodes and their possible encodings from memory is even more difficult, so it must be an even stronger signal. Why not test programmers solely on this essential knowledge? It’s almost unavoidable that their code will execute on an Intel/AMD CPU at some point, so it’s best to filter for programmers who have the strongest grasp of the fundamentals.
If you let people know that they can get a $300k job by memorizing x86-64 opcodes, you will start getting >0 pass rates on this test. It’s a given.
When people have time to prepare for the test and the incentives are high enough, you only get what you measure. The leetcode fans don’t seem to understand this.
As someone who hires a ton of engineers, I wholeheartedly disagree with this.
I actually really like this concept. The main benefit is that this approach allows a more conversational interview and also allows to cover a broader range of real-world problems.
There is almost 0 correlation between candidates ability to be effective collaborator and their ability to solve leet code problems. The former is a lot more important to us than your ability to chew out code.
More than that: a lot of candidates who are good at leetcode challenges are good at them because they specifically practice them.
Does this translate to creative problem solving and thinking? To productivity when encountering novel tasks? To being a good teammate? There is a stronger correlation with "having free time" and "solving leetcode" than being a great engineering teammate, IMO.