.comment-link {margin-left:.6em;}

Thursday, December 23, 2010

 

Will the real'istic' interviewers please stand up?

*
A few days ago, I came across an old post by RethinkDB: "Will the real programmers please stand up?". This is a post in response.

No, I did not interview at RethinkDB. And no, I'm currently NOT looking for a job. I actually like how boldly RethinkDB are going after the database market. I wish them well.

But after having reviewed countless resumes and interviewed hundreds of candidates, their post is too sensitive to not feel strongly about.

"Write a function that reverses a singly linked list"

Why is this an important question and a yardstick? Why do you think that one who can answer this question in a nanosecond is likely a "real programmer"? That's a very narrow view of the world.

* In real life, most people do not work with linked-lists. Basic Linked lists, while inevitable to understand CS fundamentals, are largely an academic topic by now. Once you are out of school, you hardly ever touch them. People actually like to build libraries so these functions can be encapsulated and they don't have to touch them on a daily basis, because touching these low level functions on a daily basis is actually quite dangerous. If every employee in your company mucks directly with linked lists frequently, there is likely something wrong. Encapsulation should have already happened before hiring your first employee.

And if you don't work with things frequently, you cannot expect to excel at them. Anything worth its salt takes time to get good at.

* Not everyone works well under time pressure. You're time-boxing the candidate over phone, which may not bring out the best from them. Not to mention that your workplace most likely never presents time-boxed challenges where there is no help available from colleagues.

* There are several programmers who will struggle with this question, but can still get you running with a solid system sooner than you will expect. They probably only know how to do those in Java, or .Net or LAMP, or a stack of their choice. And they probably know the stack much better than you do. Why are they not "real programmers?"

* There are several programmers who are not great at these questions, but they are critical to a team they are in. They have very complimentary skills and that makes the group tick very well. They are very real.

* So what if someone takes 2 hours to solve this question? Many programmers are aware that they are slow, but they put in whatever time they need and still do solid work. Speed at which code is churned out is but one factor in how fast you can succeed. Market absorption, vendor delays, poor project management, people dynamics etc usually take a much bigger toll.

* What this question tests for, is the speed of that candidate on the phone in answering this particular question, or for this class of questions - not how they are going to fit your team and be able to contribute to your vision. You may end up hiring a brilliant jerk who will kill your overall team-productivity.

* Last and probably the most important: the best programmers are often not looking for a job. Why do you expect to find them in the pile of resumes and answering linked-list questions over phone?


So what to do? IMHO, you should emphasize on more open-ended questions, if you want to know a person's abilities. e.g.

* Ask a question that has progressively improving solutions. Let the first one be easy, then ask them to find the problem with it. Keep doing that until you reach the most robust solve. Such questions quite likely mirror your day-to-day challenges. Does the candidate hold up with tenacity?

* Ask questions that you and the candidate can work with together. e.g. design a class or an interface. Working together and bouncing ideas is also something you quite likely do everyday.

* Ask a question which you just don't expect them to solve (something too hard or too arbitrary). If they give up too soon or too late, they are not what you're looking for.

* Give them a piece of code and ask them to spot bugs and make it faster. Shows if they have gone back and looked over their own code. And if their code has even run in production.

* Present them with a few multiple-choice questions, where the best answer is not present as a choice. See if they just go with what's available or challenge the assumptions.

Last and probably the most important - see if their eyes light up with curiosity as you throw questions at them, and if they have inspirational insights in their solutions. That's an excellent sign.


Happy hiring!

Comments:
Understand almost no Jargon, but like your lucidity of thought and expression. And that you're giving them a real chance, a win-win.

-Stuti
 
Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?