Hacker News new | ask | show | jobs
by GuB-42 622 days ago
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.

1 comments

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.

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.