As a test of bare minimum coding skills, definitely. You wouldn't believe the number of people who apply for junior software engineering positions yet can't do an easy leetcode problem. That's like a medical intern not knowing how to install an IV
I don't go further than that (no complexity questions, no silly google-style "let's pretend you haven't learnt this by heart" knapsack problems). And I don't care about syntax. It's just a way to know who is a developer and who is a stackoverflow cut-and-paster
I am surprised this needs to be said but the medical intern analogy is terrible and emblematic of why this style of interview is terrible. Medical interns will likely be doing things like installing an IV on a daily basis. It is a great work sample task. Your garden variety web developer will not be building algorithms from scratch virtually ever. This is not a valid work sample task.
>Your garden variety web developer will not be building algorithms from scratch virtually ever.
Web developers like this are those that introduce O(n^2) complexity in places where it could be done in O(n), which makes for poor application performance. Sure, they aren't writing algorithms per se, but their lack of knowledge of algorithms still tends to create problems not-that-rarely (assuming the product is above certain size and complexity).
Also, what constitutes a "basic algorithm" is pretty vague. I've seen quite a few people interviewing who couldn't solve fizzbuzz. Until that moment, every time i heard about people not being able to solve fizzbuzz, I though it was an exaggerated joke to describe someone incompetent , but nope, plenty of people legitimately don't know how to solve it.
I don't think fizzbuzz could even be legitimately called an "algorithmic" problem, but no matter what, if you cannot just do a trivial for loop and a couple of if-elif-else checks, you are not qualified, algorithms or not. And there is no quicker way to filter those people out at the initial stage than a simple whiteboard problem.
Remember the selection bias in observing who fails fizzbuzz. Those are the people who are repeatedly interviewing because they can't fizzbuzz. Those who can will get a job and remove themselves from the interview pool. Fizzbuzz-failers are a much greater share of interview candidates than of all programmers.
Agreed, this is an important bias to remember. I was just impressed that those people actually existed at all in the numbers beyond just a rounding error, because I used to think it was just an exaggeration, kind of like saying "he can barely figure out 2+2". Reality ended up being much more grim. I wouldn't be as baffled by tons of people failing fizzbuzz, if it wasn't for most of them having actually pretty legit-looking resumes though.
Like, you would have a great programmer who aces all the interviews, but their resume is just decent. While people failing to solve fizzbuzz might have pretty impressive-looking resumes at times. Which is why, unfortunately, leetcode feels like a necessary evil. Because we live in a world where even the most incompetent people might have enough years of experiences of skating-by to craft a top-tier looking resume. Way too easy to bs your way in if you rely mainly on resumes, and firing people later (as opposed to not hiring them in the first place) is just too expensive in every single aspect (from money to opportunity cost to team morale).
The questions asked in junior interviews are truly trivial operations which any engineer should be able to understand. A common one might be to loop over an array and build a hash map counting object occurrences. Another one I see is iterating over a log file and printing only certain types of messages.
Working with simple data structures isn’t even writing algorithms, it’s quite literally the building blocks of programming.
Depends on what you call an algorithm, of course. As GP mentioned bare minimum coding skills, I assume he uses really simple ones. This can, of course be relative, but maybe he was intentional with the analogy.
Because you can't really code without writing algorithms. Yes, you are never write a quick sort or implement a red-black tree, but you do have to understand problems and provide some kind of solution to them and then translate that into code. I.e. come up with an algorithm.
I used to use two simple problems, both involved math. One of them is a bit harder and the ideal solution assumes that you do remember high school math (not very complicated but something that you may have forgotten or at least something that you won't think should be used there). But it's nice, because you can come up with more and more optimal solutions and the naive one (which is O(n^2), IIRC, really just shows that you managed to understand the problem). I don't use that one anymore though. I almost exclusively just use the one that I thought was embarrassingly simple and which I used to use as a "warm up" exercise. Not more complicated than the fizz-buzz (which I hadn't heard of at the time I picked this one).
I'm not telling you here what it is, but it indeed does weed out people who can't really think through a simple problem and then can't think of a solution that consists of several steps following each other. (I.e. an algorithm.)
Now I'm not interviewing 'top' developers, just your average web devs most of the time. Another thing I'm doing in the past few years is code review. I have 2-3 pieces of badly written code that I have reviewed and/or rewritten.
I think the problem with your thinking, and something that I've been trying to figure out as I sit on/direct more interviews myself, is that this doesn't actually tell you that the candidate can't code, but just that they couldn't code in that setting with that problem in the way you chose to frame it for the interview.
Meaning, I often sit with candidates who come in with 3-5 years experience in industry who can't do a relatively simple programming task. That can either mean that we consistently are drawing applicants who have been pulling the wool over the eyes of their past employers for 1/2 a decade, but actually can't program.
Or, it could mean that they get incredibly nervous coding in front of strangers, aren't used to doing more abstract problems, and once they realized this, experiencing a "snow ball effect" of nerves, wherein they train wreck in the interview.
Sure, in theory it can mean that some of them are just super nervous. But, of course I do help them if I see that they don't get anywhere. I don't think that there are too many people who will just 100% shut down without showing any sign of actual nervousness.
I didn't mention how much these guys were working at other places, but it's completely possible that they were doing a job where they could just get along somehow. E.g. the last guy who wasn't able to get anywhere with my puzzle was a candidate from an agency for one of my clients. I think he was some junior guy, but I don't know for how long he has been earning money as a developer. Obviously, the agency wanted to sell him.
Besides not being able to solve the coding problem, which I told him was not a big issue (so that I don't make him more nervous) he didn't find any issues in the sample code in the code review task. (And it has about 10 issues in 15 lines.) So yeah, some of these people may have been just copy&paste programming, they may have been tinkering with larger existing projects here and there (I don't know, maybe customizing CMS-es) or are complete beginners who haven't faced with the fact that they can't (yet) write code.
After all, you have to prove somehow that you can write code if you want an employer to hire you and pay you for writing code. Sure, it could be a take home challenge too. Some companies do that. Once I interviewed for a company where I didn't want to work for a role I was not interested in (embedded C++ developer), just out of curiosity and because they were pushing it. They had a quiz about C++ (like what is a constructor, what does this piece of code print and why, etc.) which they said I aced. Then they gave me a laptop with VisualStudio and a simple task (something like writing a text wrapping algorithm in an hour). Now not having any recent C++ experience (other than on Symbian, which used a completely different std lib) and having never used VisualStudio, I wasn't able to finish. But they have a more complex take home task. That could work for nervous types. It was an interesting experience, but I believe being able to communicate about the task is much more important than being able to type out the code on your own without any help. Well, at least for most organizations.
I don't go further than that (no complexity questions, no silly google-style "let's pretend you haven't learnt this by heart" knapsack problems). And I don't care about syntax. It's just a way to know who is a developer and who is a stackoverflow cut-and-paster