Nowadays It seems that the bigger the company is, the bigger the paranoia to hire one of these Secretly Terrible Engineers. Driven by a fear that they might hire one of these idiots, interviewers tend to always ask the same old, back-to-basics, algorithms/data-structures related questions, even when interviewing experienced engineers. Unfortunately, as recognized by many (including Google, Facebook), such interviews result in a significant false negative ratio.
Instead of refreshing their interview strategy, most companies try to improve this awful false negatives ratio by asking/expecting engineers to “prepare” to these questions by reading books like “Cracking the Coding Interview” and practice weeks or months on solving problems (in most cases) completely unrelated to their daily work.
To be honest, ever since I joined Microsoft, I’ve based most of my interviews on these questions. I also wrote down all the questions (and answers) that I have asked and being asked, it’s all right here: Get Ready for Software Interview.
As an interviewer, algorithms questions are the easiest to ask. You don’t have to sweat nor think too much. You know the questions and answers by heart, and you are always surprised to see engineers struggle when they try to solve them with their back against the whiteboard (except for the ones that solved a similar question in their recent past).
What I have learned is that cutting off developers based on their ability to quickly solve algorithms questions on the whiteboard results in a significant false negative ratio. You end up ignoring the best of talent, the x100 multipliers, the ones that you are so desperately looking to find.
If you ask me, hiring managers should know better by now. Instead of settling on these awful odds, they should join the 21 century and refresh their interview strategy. They should hand pick the interviewers based on the candidate current set of skills. They should guide the interviewers to focus less on whiteboard coding (come on already!) and more on good old, one-on-one software related conversations. A good interviewer should be able to asses the quality of a candidate simply by talking with the guy for 15-30 minutes. For the rest of the time, show the candidate existing code and see if he can tell what's wrong with it and how it can be improved. Talk about his past experience and check if he became an expert in the areas that he worked on.
Some of the best developers I know have degrees in Electronics, Physics and Art (some don’t have a degree at all). They have been developing software since puberty. They are passionate about it. It’s their hobby. The would work for free. Some of them don’t know (nor care) what’s the Big O of Merge Sort (god forbid!), but they have been rockstars in every company that they worked on, the kind of talent that you don’t want to miss.
If you search for topics currently asked in Software interviews, you will find the following: binary search, tree traversal (pre/in/post), sorting algorithms (merge/quick/and some O(n^2) ones), recursion/iteration, graph search, dynamic programming, breadth first search, depth first search, stacks, queues, hashtables, heaps, priority queues, and linked lists (single/doubly/circular).
We expect all candidates to solve these questions on the spot, under pressure, irrespective of their past experience.
The problem is that 95% of developers don’t get a chance to implement most of the above in their daily work. Someone else already did it better. So, you are optimizing your interview to find the 5% that implement these algorithms in their daily work, plus 5% collage grads that just finished the Introduction to Algorithms class, and another 20% that spent couple of weeks preparing to these interviews.
The rest 70% are in serious disadvantage. They might or might not pass your tests. It’s more than likely that hiding in this group are the 100x multipliers, the ones that can ramp up quickly on the most complex codebase, the ones that write beautiful and maintainable code, the ones that can design, the ones that can test, the ones that make the difference between successful and unsuccessful projects. Isn’t that what you are looking for?!
Having said all that, I have no fantasy that interviews will stop using the whiteboard so extensively any time soon. It's just too easy. Plus, software engineering is spread across so many areas (web, mobile, SQL, OO, concurrency, distributed systems, cloud, etc) - that Algorithms and Data Structure seems like the only common denominator. Just that it isn't.