[GuB-42]

The thing is, all these arguments can apply to any test you do during an interview. It is always under pressure, and it will always be incomplete. You will never know for sure before you actually hire the candidate.

If the interview for a coding job doesn't involve actual coding, how do you know that the candidate can code? What you may get are people who are just really good at selling themselves. Maybe a good fit for the sales department, but not so much for the technical position you are hiring for.

LeetCode is not perfect, but no test is.

As for the "memorization" aspect. You can certainly memorize solutions. But you can't just memorize every character of every solution and regurgitate it perfectly. You will need to make some generalizations, just to fit everything into your brain, and as you type it back, you will probably misremember something, and have to fix the bug or bridge the gap. Those are useful, real life coding skills.

[waythenewsgoes]

> If the interview for a coding job doesn’t involve actual coding, how do you know that the candidate can code?

LeetCode problems seldom resemble real-life coding scenarios, which in theory is what you are supposed to be most concerned with.

Why not present them with a real problem that you actually had to solve for your business? And ask them to walk you through how they would try to solve that? Perhaps as part of a take-home assignment?

Leetcode test or nothing is a false dichotomy. Accepting it is lacking without attempting to look into alternatives doesn’t seem logical.

>You can certainly memorize solutions

You can most certainly memorize the high level steps to LC problems. In fact I would argue that this is already the status quo. You may still be able to learn how they would approach a problem this way, but if they are good at “selling themselves” they can make all that “seem” real as well.

[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.