The problem with the hiring process in most companies is that instead of optimizing the process to establish diverse teams of smart/creative/passionate engineers – they obsess on filtering out the Secretly Terrible Engineers, mainly by asking the same old, back-to-basics, algorithms/data-structures related questions - even when interviewing experienced engineers. Unfortunately, as recognized by many (including Google, Facebook), this interview strategy result in a significant false negative ratio. Software companies try to improve this awful ratio by asking/expecting engineers to prepare to these interviews 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 and past experience.
To be honest, ever since I joined Microsoft, I’ve based most of my interviews on these questions. I 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 with great resume struggle when they try to solve these questions with their back against the whiteboard (except for the ones that solved a similar question in their recent past).
What I have learned, mainly by watching internal candidates that we rejected thrive in other teams, is that cutting off developers based on their ability to quickly solve algorithms questions on the whiteboard makes you pass on the best of talent, the talent that you are so desperately looking to find. Sadly, other than my personal experience and conversations with my colleagues, I have no solid data to prove this. It's easy to collect data on the success/failure of engineers that got hired, but it's extremely hard to measure the % of good talent that a given team missed on.
If you ask me, hiring managers should know better by now. Instead of settling on these awful odds, they should 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, that has similar background as the interviewee, should be able to asses the quality of the latter simply by talking with him/her for 15-30 minutes. Show the candidate existing code and see if he/she can tell what's wrong with it and how it can be improved. Talk about his/her past experience and check if he/she became an expert in the areas that he/she worked on. Every single interviewer that participate in the interview loop should carefully read the candidate resume and ask coding questions related to the latter past experience! It makes little sense to base an interview on algo questions when interviewing an engineer that spent the last 5 years building web applications focusing on HTML and java-script (and then rationalize the no-hire decision on his/her lacking 'core' engineering skills). Yet it happens all the time.
Some of the best developers I know have degrees in Electronics, Physics and Art. They have been developing software since puberty. They are passionate about it. It’s their hobby. They would work for free. Some of them might not know what’s the BigO 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. Add these people into your mix and you’ll get a diverse (=more productive) team that create great products that apeal to a wider range of users.
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 even half of the above in their daily work. They reuse existing algorithms or services encapsulated nicely in most modern frameworks/platforms. 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 maybe another 20% that spent couple of months 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 can lead, the ones that stop at nothing and get things done, 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 interviewers 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, big data, etc) - that algorithms seems like the only common denominator. Just that it isn't