[eesmith]

Do not let the perfect obstruct the useful.

A FizzBuzz coding test - which is also imperfect - will weed out those who cannot code, and without the false negatives from LeetCode.

Programming is far more than writing code. Do you test their documentation skill? Their ability to work with others? To fix someone else's code? To identify and resolve ambiguities in the spec? To estimate development time?

Is the additional time needed for a LeetCode test over a FizzBuzz test worth the time taken from evaluating these other factors?

[GuB-42]

I actually never did LeetCode interviews, but I did some competitive programming, same idea.

And it tests more useful skills than FizzBuzz. I wouldn't recommend hard questions, as they usually require techniques that are not very useful for most jobs and that you have to specifically train for (ex: dynamic programming). But for easy to medium questions, in my experience, the bottleneck is usually misunderstanding the problem, and simple bugs like typos, off-by-one, reversed conditions, etc...

Understanding of the problem relates the the ability to read a spec correctly, and the ability to identify and resolve ambiguities is related. And if you can fix your own bugs, it also helps when fixing others.

Of course, it doesn't test everything, particularly not teamwork (I mean, it is similar to competitive programming, the opposite of teamwork), but it was never meant to, other parts of the interview can do that.

As for documentation, I think writing skills are important and undervalued. I mean it in the traditional sense, like writing novels. We could have candidates write essays, but like LeetCode, people will complain. I will, because I suck at this, but I understand the value. By the way, I find that LLMs help a lot for this, language models, are, after all, really good at language, especially technical writing that is more formal than creative writing. Of course, the LLM require guidance, but once it gets the technical part right, I find the writing is pretty solid.

[eesmith]

It seems in poor taste to respond to someone specifically criticizing LeetCode questions, by using your experience in non-LeetCode evaluations.

I too did competitive programming. A team working together to prioritize from a list of programming tasks which cannot all be completed in time even by the best team is a far cry from a LeetCode interview problem.

[GuB-42]

There are different kinds of programming competitions. Some are about solving relatively easy problems individually and as fast as possible, which is most of what I did. The best candidates usually can solve all the problems and time determines the winner. Others are about solving hard problems, sometimes as a team, like in a hackathon. I was talking about the former.

I also did a mock LeetCode-style evaluation, which my company made me do as a benchmark. It was a lot like the kind of competitive programming I mentioned. But I don't count it as an experience because it was not a high-stakes, stressful situation. Note that I had no say on the recruitment process, they just asked me and other employees to do the test to see what to expect from someone of our skill levels, it also included some other, more knowledge-oriented questions.