I find competitive programming to be creative and expressive. For most problems, there actually can be multiple ways to solve the same problem, with each approach having both hard (perf, memory) and soft (simplicity) trade offs. Leetcode problems remind me a lot of Celeste levels or rock climbing, where even though there might be an optimal solution, everyone solves the problem in their own unique way. No two solutions look the same. Even if everyone is solving the problem with the exact same algorithm, every submission has its own code style, and that's really cool.
I also find that Leetcode translates really well into the code I write in my freetime (a roguelike. Real work is boring fullstack crud). I personally hate reaching for libraries in my side projects, so being able to have these data structures and algos at my fingertips and being able to implement say A* or a weighted rng function or something else on the fly has been super handy. I honestly don't think I would be able to implement a vertex fragment shader w/ lighting without the skills I've picked up from Leetcode grind.
I'm sure Leetcode and similar exercises are great recreational activities, whose benefits leak into daily work in some shape or form. The problem I see is that the practice has been manifested as a one-dimensional interviewing practice:
"Solve this problem in 45 minutes. Top to bottom, single pass, no typos, right now, while I'm watching and interrupting your thought process. You are not permitted to feel anxious. You now have 43 minutes - Go!".
I understand there are companies which treat Leetcode as a "representative field test", but IMHO (based on my 8+ yrs experience working across FANGM, w/ ~200 interviews conducted) any company that uses Leetcode this way, is doing it wrong.
The "right" way to use Leetcode, is to treat it similarly to how IBM does their weird IQ test screening, except Leetcode is strictly better than an IQ test. It is NOT a simulation of work. It is also NOT an "intelligence" test (thank god for that).
If anything, it is closer to how professional sports teams evaluate young athletes via a training combine or a set of individual drills/tests. Doing vertical jumps or sprinting really fast are not "representative field tests" of how well you actually play a sport (the whole sport, not just a single part of the sport), but they are good-enough filters for an athletic "interview".
However, in the same way that IQ tests are bad for a multitude of reasons including implicit demographic biases, so too are Leetcode tests flawed (including a heavy element of age-ism, as there is a strong anti-correlation between "years since college" and affinity for Leetcode-style tests).
I don't agree, but one upvote is from me because I'm impressed at the clear justification of your opinion in your comment.
I disagree for the same reason that I didn't like D&D-style magic, where magic-users memorise their spells and can only do magic as far as they still have spells in their memory "slots". That's not how real magick, a.k.a. programming a computer, should be like. Memorising solutions is useful and you should not reinvent the wheel (ahem, which means you should use libraries actually) but I am not convinced you can really learn The Laws of Magick (principles of programming) by solving specific coding exercises and memorising their solutions.
> For the most problems, there actually can be multiple ways to solve the same problem, with each approach having both hard (perf, memory) and soft (simplicity) trade offs.
True, but my understanding is in interviews, which is the context most people are interacting with leetcode, the interviewer is looking for only one of those answers, and you have to regurgitate the right one fast.
As someone that does interviewing, I am not looking for one specific “right” answer. Acknowledging the time constraint and pressure of an interview, I find it acceptable to get non-optimal solutions. As long as they’re able to come up with a reasonable solution and can recognize it as being non-optimal, and offer ideas for how to optimize it outside of an interview setting.
I’m not sure how common this way of thinking is, but I wanted to point it out since many of the comments here make it sound like only the best answer will do.
I also find that Leetcode translates really well into the code I write in my freetime (a roguelike. Real work is boring fullstack crud). I personally hate reaching for libraries in my side projects, so being able to have these data structures and algos at my fingertips and being able to implement say A* or a weighted rng function or something else on the fly has been super handy. I honestly don't think I would be able to implement a vertex fragment shader w/ lighting without the skills I've picked up from Leetcode grind.