Technical Interviewing December 10, 2010 at 7:40 am

I’ve been thinking a lot about some of the questions I have been asked in the past for technical interviews recently and I have come to the conclusion that they mostly suck and I have no idea how to make them 100% better.

It is not that the questions aren’t relevant, but that they don’t (to me anyway) generally do a good job of showing what a candidate offers.  For those fresh out of school, one of the generic algorithm questions is probably a good way to see what a candidate will offer.  It give will you an insight to what they have likely been exposed to in an academic setting and is likely a good way to engage the candidate because it will be similar to what they were exposed too.

For a well seasoned developer I am convinced that they are a complete waste of time (and at least in my case will can make me seem like an idiot).  Unless you are constantly exposed to the types of scenarios that require the use of the raw algorithms it is likely that they will be extremely rusty.   The following is a highly contrived example of one of these types of questions.

“Write a function to count the number of spaces in a string.”

If and of itself this function is fairly simple at first glance:

The problem with this type of question is that no one should be writing code like this.  When writing on a white board simple is better, but simple only gives the verification that the general process can be followed.  A better example of this would be as follows:

However, I would contend that even the above shouldn’t be in most production code.  If the parameter validation fails then zero is returned.  Programming errors are masked.  Not to mention that raw string handling is rarely a good thing.  Are your really hiring the candidate to re-invent the wheel?

At the end of the interview what have you really learned about the candidate that tells you how they would function in a complex system.  Nothing.  (IMO)

But how do you determine if a developer is able to follow complex ideas?  Hell if I know.  I wish I did. The closest question I have seen that was a good screen was something like this:

“Take this RFC and implement this subset transformation.  Use your language of choice and write highly efficient bullet proof code.”

It gives the candidate a chance to think about the problem and present a good polished solution.  The drawback is that unless you sit them in a room with a camera on them you can’t really tell if it was that person doing the work or not.

I think the best way to really get to know if a developer is good for your team is “try it before you buy it.”  Contract to hire is likely the best bet.

I know that I have done poorly on interviews that I am fairly sure I would have been a perfect fit for the job.  The problem was the technical screen and the stumble bum way I came across.  I have a hard time “disengaging” my brain and writing what I consider to be substandard code.  However that “substandard code” is what goes well on a white board, because you are trying to illustrate an idea.

Comments are closed.