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