Interviewing Programmers

Recently I had a client ask me about an article that claimed 99.5% of programmers they interviewed couldn't even write a few lines of simple code.

His question: "From your experience, how true is this article"

While finding good people who can do what they say they can do is very difficult, the article exaggerated a lot.  If someone is testing programmers and 99.5% of them fail the basics, they must be doing something drastically wrong in their pre-screening process.  Those people should never have made it to that point in the interview process.

If you have kept up with American Idol recently (yes, I do watch that show), you will have seen the absolutely horrendous "singers" who try out and think they are great only to show they have no concept of pitch or being in tune - the basics of singing.  There is an endless supply of people who delusionally think they are great at something when they haven't a clue.

To add to the issue, with the recession you get a lot of people who apply to anything and everything they can find in hopes of landing a job.

Here are some simple techniques you can use to screen out nearly all of the people you shouldn't even talk to.  As with everything, the more you do this the better you get at it.

  • Post your job opening and give some simple instructions like"include 5-20 lines of code to show your programming skills".  If they don't follow the instructions they either are not paying attention (they are applying to anything and everything they see) or they just cannot pay attention to detail.  Either way, that resume is filed in the trash.
  • Look through the resume.  If the person has experience and training in a related but different field, set it aside or file it in the trash.  For example, if you are looking for a programmer and they were a system admin or network engineer, they just are not what you are looking for.
  • The person needs to show some experience in doing what they say they can do for you.  With how easy it is to write code at no cost to the budding software developer, there is absolutely no excuse for not having put together their own web site, built out a database and written some code that ties their web site into that database.  Most college students fall into the category of "book smart, street stupid" because they learned it in class but never did it in real life.  They don't need to have done it for money.  Get rid of those with no experience - they have no excuse.
  • Respond to the potential candidates with a few simple to answer questions.  Keep it to 2-5 questions that could be answered in a few minutes.  Make it relevant to the job but not necessarily critical.  If they don't reply, they obviously are not interested in the job.  This weeds out the people who blast their resumes all over the place.
  • Look at their experience.  If they have not stayed at any one place for more than a year over the last few years and especially if they don't stay the same place for more than a few months at a time then they probably aren't going to stick around with you either.  Some contractors do jump from job to job.  These people are fine if you are looking for a short term freelancer but not if you are trying to fill a full time position.
  • When looking at experience, if they have been out of a job for over 3 months, you may talk to them but ask them what they have been doing to keep their skills sharp.  Why do I say you "may" talk to them?  If they are still doing stuff on the side it should be on their resume.  If they have been doing things on their own, taking classes, etc. then great.  If they have just been looking for a job, have them look somewhere else.  They don't like the work enough to be passionate about it.  I don't hire people who are not passionate about their job as they just don't perform well or keep up on the latest in the industry.
  • Look at their list of skills.  If the skill sets you list in the job posting are not at the top of their list of skills, they are out.  For example, if I say I want Java and the person puts a list of 20 languages and technologies with Java last, I am not interested.
  • Formulate a quick list of questions that are either right or wrong.  I like to have 10 of these.  Then have an assistant call the candidates you have left and ask the questions.  Remove those people who don't get at least 70% on your test.  For example, I like to ask questions like "What attribute do you use on an HTML button tag to make it fire off a JavaScript function?" Answer: onclick.  Keep to questions that address what the person should be doing on a daily basis.  These should be very easy for the right person to answer.

Personally I think most people who interview programmers miss the most important thing about screening the applicant.  They want the applicant to write a program that outputs the first 100 prime numbers, skips every 3rd number or lists the Fibonacci series.  A lot of time they ask so specific questions(while they think it is generic) that even if a person knows the answer they get tripped up on the wording or a term they hadn't heard before.  I read an article just last week that did that to me.  They suggested asking a question that used a couple terms about database locking that I had just never heard before.  Once I looked it up on Wikipedia, I knew exactly what they were talking about.  I despise questions that revolve around knowing technical terms.  I know how to do it even if I don't know what the blasted thing is called in the academic community.

What is most important is that the person has the right personality to fit your company culture, is bright, has a great work ethic and can learn quickly. Give me a guy who doesn't know it yet but can learn it fast any day over the person who already knows it but has difficulty expanding his knowledge.