> terrible interview technique in the first place.
I'm really not a big fan of whiteboard tests, but I have yet to find an initial filtering method that is as quick and cheap as 30mn with coderpad or whatever.
I'm really not a big fan of whiteboard tests, but I have yet to find an initial filtering method that is as quick and cheap as 30mn with coderpad or whatever.
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
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.
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.
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.
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.
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).
Working with simple data structures isn’t even writing algorithms, it’s quite literally the building blocks of programming.