Wednesday, March 11, 2015

Software Interview Nightmares

The below is from my Quora answer to ”Has Cracking the Coding Interview made it more difficult for recruiters to evaluate software dev…” @ http://qr.ae/j5qwX

The problem with the hiring process in many software companies (especially the big ones) is that instead being optimized to establish diverse teams of smart, creative and passionate engineers – it is heavily optimized to filter out the Secretly Terrible Engineers, for the most part by using the same old, back-to-basics algorithms questions, irrespective of candidates experience and background. Unfortunately, as recognized by many (including Google, Facebook), this interview strategy result in an outstanding false negative ratio.

Now, can a company come out with an alternative system with much lower false negative ratio without compromising the hiring bar and increasing the false positive (miss hire) ratio? yes they can! Myself and my extended team have been doing just that in the past 4 years.

The honest truth is that very few of us (if any) have the wisdom to assess the programming skills of experienced engineers in a 45 minutes algorithms quiz which is performed under extremely stressful conditions.

Trust me, I've been asking these questions for years. I even documented all the questions (and answers) that I've 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 experience struggle when they try to solve these questions with their back against the whiteboard.

It never really felt quite right, and the more I interviewed the more I realized that I simply can't evaluate years of experience using 45 minutes quiz. That definitely wasn't the way I wanted to be evaluated.

We can do better. We should do better. Hiring managers must know better. Instead of settling on these awful odds, they should refresh their interview strategy. They should hand pick the interviewers based on the candidate experience and current set of skills. They should guide the interviewers to focus less on algorithms on the whiteboard (enough already!) and more on good old, one-on-one software related conversations.

I believe that a good interviewer, with 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. Talk about his/her past experience, look at the code that he/she has written, and check if he/she became an expert in the areas that he/she worked on. Every interviewer that is asked to participate in an interview loop should carefully read the candidate resume and make sure that he can ask coding questions related to the latter past experience. If a technical interviewer doesn't have the appropriate experience to ask these questions (no shame in that), he should excuse himself from the loop instead of defaulting to good old , one size (doesn't) fit all algorithms quiz. I mean, it makes little sense to base an interview on algorithms 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. Dare to add those people to your mix and you’ll get a diverse (=more productive) team that create great products that appeal to a wider range of users.

If you search for topics currently asked in Software interviews, you'll 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 most 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 are in serious disadvantage. They might or might not pass your tests. It’s more than likely that hiding in this group are the 10x multipliers, the ones that can ramp up quickly on the most complex code-base, 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