Ultimately the proof is in the pudding, I've had loads of candidates that could barely code and Leetcode-style problems are a great filter against that.
Otherwise you risk just getting PM-style bullshitters as engineers, who talk persuasively about projects that other people actually implemented.
The more I learn about software development the more I try to _not_ have leet code style parts in my code - in the very rare circumstances would I see something like that and say - yes there is _no_ other library out there that has a battle tested algo to solve this particular problem, _and I have to code my own_.
Worse people who excel at Leet Code could start to bring that sort of thing into your codebases, optimising small parts of your code to perfection, and then leaving the whole thing a mess or just plain reject to work on solving business issues and concentrate on polishing their small bit of algorithm.
Of corse there are positions where that sort of mindset is welcome and sought after. Especially in very big companies, but for the most developers out there leet code is _just_ for the interview part and they would (should) never use that kind of problem solving in their day-to-day work.
When I have to interview somebody, and there's leet code involved:
a) they are _really_ comfortable with those types of challenges - that tells me they have spent a lot of time preparing - either for this interview or just generally, either way that wouldn't _really_ tell me much about their problem solving skills
b) they feel uncomfortable and fail to solve anything due to stress or anxiety - again no really knowledge gained, as real-world work environments tend to try to minimise those, at least in the places where I work in.
c) they feel uncomfortable but get the hang of it - now I _might_ have a glimpse of their problem solving skills, but I've put a human being in a very uncomfortable position just to _test_ them. There _has_ to be a better way.
The way I like to conduct interviews where possible is to ask people to walk you through some of the code they've written and ask various questions about decisions - much more relaxed and I still get the sense of how they organise their stuff and how they work.
If that's not possible - a take home task or something. Or even "hire fast fire fast" approach works too.
The problem is that a take-home task can be impossible for some people already in a full-time job with kids, etc. and so has its own bias. And the "hire fast fire fast" approach doesn't really exist here in Scandinavia, even though there is a probation period it's still frowned upon to use it for anything but extreme circumstances, and if done en masse would likely raise issues with the trade unions.
This sounds incredibly specific. Most places requiring at most LC easy don't really need any of this, and I'd be worried about the interviewer looking for key words and specific answers over actually testing whether the candidate grasps things or can learn what is necessary.
That way, some of the pressure is off of coding with someone looking over your shoulder, and you still have time allocated off already.
> ...
> Or even "hire fast fire fast" approach works too.
Comment "c" shows a high level of care/concern for the candidate. "hire fast fire fast" does not.
What if the candidate left an unsatisfying but steady job to join your company? And they get fired in the first few weeks. Now they are unemployed. This is much more uncomfortable than an awkward interview question.
The coding round is supposed to test that.. you can code.
For the record I’m also not a fan of the Leet Code style rounds, even though I actually find completing them (outside of an interview) quite fun.
The point of leetcode is not to show what you can do, it is to show what you can't do.
To keep up with your analogy, being able to design a simple website doesn't make you able to set-up an enterprise-level infrastructure, but if someone isn't able to design a simple website, I don't want to hire him for my enterprise-level infrastructure.
As for "outside the box" thinking, it only works if you know where the box is, otherwise you are just being clueless.
And by the way, because it is an argument I see way too often, calling the "sort" function of your favorite library instead of doing the exercise "as intended" is not "outside the box" thinking, it is literally the most obvious thing to do. What could count as "outside the box" would realizing that you can solve the problem more efficiently by not sorting anything at all, which requires you to know your sorting algorithms to show that it is indeed more efficient.
What does the code do? Does it work? How would you get it working? How do you test it? What is the complexity? etc.
They aren't suggesting to not do programming tests, they're saying make the tests more aligned to the role and domain being hired for.
I use a pretty similar approach and find it works very well.
I'm a great engineer, I just suck at leetcode questions because...shocker! They have absolutely nothing to do with my day-to-day. It's similar to puzzles; I hate puzzles and doing puzzles/escape rooms/etc, but I'm a pretty smart guy.
Leetcode is merely a gatekeeping methodology that proves almost nothing and weeds out a lot of amazing engineers who aren't skilled at grinding leetcode or hate brain teaser shit.