Interviewing Techniques

I don't read a lot of instructional books.  I prefer to do things my way.  First time I had to "review" a boss's performance at work, my chief complaint was, "Don't tell me how to do my job.  Tell me what needs to be done."  It's a quirk that I'm particularly fond of.  If someone tells me something that needs to be done and I don't know how to do it, I'll read and look things up and experiment until I find the best solution.  It's what I do.But seriously, don't tell me how to do something.  It'll force me not to ever do it that way just out of spite.

With that prologue in mind, you must consider that I'm a leading interviewer where I work.  I've developed this system of testing people before they get hired.  It's not perfect and we don't hire enough people for me to work on its perfection, but it is approaching fun (at least for me).  I wish, before an election, I could interview prospective candidates.  I assume debates attempt to do this to some extent, but debates mostly bore me.  It's like a test to see how well someone can beat around the bush.

When I interview people at work, I'm mostly hiring programmers.  The first thing I want to find out is if they can listen. My first statement might be, "Do you know about the Fibonacci Sequence?"  This can get a whole host of answers.  Yes or no will usually suffice.  I don't like excuses or beating around the bush.  I'm all about efficiency.

I remember when I first graduated from college, the placement counselors teaching me how to go on interviews would always advise, "Keep talking until they ask another question."  I don't like that advice.

If they answer no, I'll explain it to them the best I can.  If they say yes or after my explanation I'll ask them to write it in a programming language of their choice.  This gets me into another topic for another blog, but I'll hint at it here.  Good programmers don't need to be experts at any particular language.  Good programmers can be experts at a language in less than a month whereas someone programming in the same language for 10 years can still be mediocre at best.

At this point in my interview game, I want to hear questions.  If they just start writing code, I'll usually kick them out the door.  I want someone who'll take the time to ask questions and get it exactly right the first time.  If I'm feeling mean spirited I'll let them write the code for 15 minutes and then tell them that's not what I wanted and start making things up.  I wanted it done this way, I wanted you to do it that way, it needs to be more efficient, I don't want recursion, etc.  It forces them to start over and it makes me giggle on the inside.

Once they've asked all the questions and have it designed and written to meet my requirements, I'll throw out enhancements.  Do they hack the enhancements in or do they take the time to re-design?  Do they remove the things that don't work for the enhancement?  I have a do it right the first time philosophy.  There are a group of people that just, "make it work".  I don't want to hire them.  I need the perfectionists or at least a smattering of due diligence.  It makes future maintenance and enhancements easier.

These types of techniques can be applied to any position.  When we elect government officials (like the President), they should have to go through a similar interview process.  The election cycle should be every 6 years, but with a 1 year introductory "contract to hire" basis.  If, after 1 year, they are inadequate for the job, replace them.  Oh, and I guess we're going to have to implement Internet voting to defer the costs of having to reelect so many dead beat civil servants.