We're engineers.
If you don't like something, make something better.
Take home projects and how many marbles in a jar are extraordinarily worse than traversing a binary tree.
I suspect that any interviewing practice will always being in detractors. It's a process of culling, those culled will dislike it.
That said, I'm partial to good leetcode questions. Some of them are worded terribly, some of them are essentially trivia, some of them are overly esoteric and not applicable to most roles. Some of them are great but have "optimal" solutions which take an absurd amount of research and effort to produce, like quickselect. These questions are bad and should not be asked.
Others I find fantastic questions. "Scheduling meetings", anything that requires you to walk a tree or do a binary search/BFS/DFS, and tasks that require you to combine two data structures like the "Hashmap with O(1) get random" question really helped me get better t my job.
There's others I'm lukewarm on, like many topological traversal, shortest/longest path, and knapsack/space filling questions. I personally love them and have gotten good at them, but I also don't expect joe schmo to remember how to implement the relevant algorithms off the top of their head. I'd consider this question cohort good for "open book" interviewing at "less prestigious" companies. I'm totally fine with Google/Meta/Amazon asking these closed-book for normal roles.
I dislike leetcode style puzzles so much that I will simply drop out of the interview loop rather than subject myself to them.
Like interviews aren't lengthy enough as-is. I had an onsite the other week with two sys design, two leetcode-esque, a hiring manager, and a project manager.
I'd take that any day over the take home project I had to do in a subset of common LISP fresh out of college. Twas NOT a fun weekend, especially since I had no familiarity with LISP. With few exceptions, I don't do takehomes anymore. I don't want to spend an hour or so fuddling with your/your vendor's poorly documented, buggy environment (or setting it up myself) on my own time, outside of office hours, talking to exactly zero human beings during the actual process. It teaches me nothing about the company or team I'd be working on, doesn't allow for any gauge of culture fit, and (unlike leetcode) doesn't make me a better programmer.
Take home project: typically capped at 4 hours.
Hmmm, this is a tough one...
Every such test is supposed to be calibrated. Leetcode... Is not.
It's not even the same order of magnitude. Like I mentioned, it is common to spend months grinding leetcode. How can people rationalize this and prefer it to a closed scope assignment? I honestly don't get it.
I've personally learnt a lot from Leetcode, and found the process really valuable. I learnt a ton from bashing my head against the wall until dynamic programming made sense.
I anecdotally code much, much faster, in all languages, having done it. It's like doing college homework again. Something useful that makes you a better "coder," (not necessarily a better engineer). It was a damn hard slog, but having done the hard slog I really enjoy having done it.
I'm not going to pretend it's not time consuming or I'd be happy doing it if I was a busy parent.
But in hindsight I've really enjoyed having done it, and found it extremely valuable.
I suppose it's for people who just have that kind of time/energy/enthusiasm for programming/their career.
Leetcode-style problems as an interview technique are probably the one that’s furthest away from testing the from day-to-day software development challenges most organisations face.
As others have said, open to extreme abuse in terms of timeliness.
> A system design exercise around a whiteboard
I've worked with a frankly extreme number of architects who can talk the talk but cannot (or will not) code the code.
If you're hiring for someone to code the code system design isn't the signal you want.
> Pairing up to fix a bug in the org’s code during the interview
Open to cheating. Very difficult and time consuming to rotate the problem. With Leetcode you can take the problem out of a college textbook.
> Talking the interviewer through some previously-written or open-source code.
Works well for small companies where you're hiring someone who fits a team well. Probably the best approach for small companies.
For big companies, it's open to extreme racial and personal bias.
And I don't mean racism in an abstract sense. I mean that I've interviewed with a company that pairs with a particular coding exercise across all candidates.
They asked me back whilst knocking back my INFINITELY more qualified good friend who was interviewing with the same company.
We walked through the same code base, I'm a LOT less qualified than they are. We got far different feedback, to the extent I genuinely can only assume unspoken racism.