Oh Yeah? Prove it!

It’s been a while since I’ve interviewed for a job.  The last time was when I was working at Lockheed and wanted to find something closer to home.  I went to a small, local software developer and two guys put me through the ringer with test questions.  At the end of a day of work, I was tired, uninspiring, not very sharp, and I didn’t get the job.  Some things are just as well, I suppose.  You won’t get every job you interview for because you’re not right for every job.  I probably wasn’t right for that job anyway.

In my 24 years of software development, I’ve given and received numerous types of interviews.  From grueling take home tests, on the spot tests, mind puzzles, behavioral interviewing, mindless “what did you do at your last job” questions, “what’s your greatest weakness”, etc.  In my experience, they all suck.  Interviewing just plain sucks.  I participated in the hiring of my new manager many years ago.  We put several guys through a two day process, finally chose one, and he still was clueless.  The fact is: interviewing is a crap-shoot.

Your best bet with interviewing is to try a combination of things.  If it’s for a programmer, then you have them do some programming.  They can do it at home or on paper during the interview, but it should be something that’s not a trick problem.  The purpose of something like this should simply be to make sure that this person can actually write some code.  Have them design a simple class to do a simple job (some people can code a procedure, but class design is beyond them).

Skip the mind game problems.  They’re dumb and all they prove is that they can either remember the answer or can figure out a mind game problem.  What color is a newborn African-American baby’s teeth?  Really?  The answer isn’t white.  It’s nothing – babies don’t have teeth when they’re born.

Your job when you’re interviewing someone is to find out if they can work with you and do the work.  Yes, make them do some coding.  Show them your code and ask them about it.  You might try some pair-programming with them.  Give them a demo of your product and see what their reaction/questions/comments about it are.  Are they engaged?  Interested?  Do they have a clue about your domain?  Can they understand what you’re talking about?

Talk about their previous work.  Find out what they’ve worked on – in detail.  What pieces of a product did they actually code?  In what language?  With what tools?

Finally, remember this is a two-way street.  Don’t treat your interviewee like a child.  You want them to want to work with you at your company.  I’ve been on many interviews where companies treat you like they’re the last hope you have of finding work, rather than courting you, and I’ve turned down jobs because of it.  Who wants to work for people who seem like they enjoy putting you through a ringer?