Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

September 16th, 2009 at 6:50 pm

Top 4 mistakes hiring new programmers

with 4 comments

The human factor is the most important element for the successful completion of software projects, hiring the wrong candidate is among the highest costs for the project. Keep in mind the following four mistakes when hiring to make sure you are taking the right decisions.

1.- Only ask specific technical/non technical questions

This is one of the most common mistakes I’ve seen interviewing candidates, there are companies that even rely on a standard multiple choice test to evaluate them. Only asking specific questions is plain wrong for three different reasons.

  1. If the candidate doesn’t know the answer of a particular question, it doesn’t mean anything, maybe he has forgotten the answer, maybe he has never work in that particular area…
  2. Typical specific questions are usually googled by everyday programmers, and that’s completely fine, why do you expect your candidate to memorize them?
  3. Specific questions don’t show at all how good the candidate reading, designing and writting code is, and that’s the purpose of the interview.

I’ve heard many times people arguing that tests are good because they help to make the selection process objective and easy, but that’s like looking for a wife/husband using tests because is objective and easy.

2.- Plainly believe that the candidate is always telling the truth.

Is common for people that has just started interviewing candidates to plainly believe the candidate, keep in mind that there are people who is pretty good at doing interviews and knows how to sound impressive, try always to get the candidate to explain details of the experience and projects he/she claims to have developed and get him to talk in specific terms of his choice rather than explaining them in general, high level topics.

3.- Hire a programmer just because the estimated time for the selection process is over.

You have to fill two positions and the estimated time for the selection process is over, If none of the candidates have fully convinced you, don’t hire anyone, is better to have an empty position than the wrong person.

4.- Not asking the candidate to do some code.

You are hiring a guy to code, don’t forget that, you don’t hire him because he is a convincing speaker, or because he has a PHD, never let him/her go away without testing his/her real coding skills, read this article to get a few ideas on how to check the coding skills of the candidate.

4 Responses to 'Top 4 mistakes hiring new programmers'

Subscribe to comments with RSS or TrackBack to 'Top 4 mistakes hiring new programmers'.

  1. […] This post was mentioned on Twitter by Dahlia Bock and Nenad Alajbegovic. Nenad Alajbegovic said: Top 4 mistakes hiring new programmers: […]

  2. I’d reorder the list slightly to;

    1. Not asking the candidate to do some code.
    Really, they’re going to be programmers, there’s no better way to show their ability than… to show their ability.

    2. Only ask specific technical/non technical questions.
    Agreed, any good interview questionnaire will have a fair combination of specific questions and general questions.

    The latter two I’d simply rephrase,

    3. Plainly believe what the candidate says during an interview.
    While you don’t want to automatically assume the candidate is telling the truth, you do them a disservice to assume they’re lying, simply take what they say with a grain of salt. This works both directions, someones the candidate says things they don’t mean, and sometimes they incorrectly state things they do.

    4. Hire a programmer just because the estimated time for the selection process is over.
    This is much much less a strict rule, and based more on the business needs. If your hiring for a big contract that has a very specific start date, hire A body to fill the spot, while you continue to hire for more, but if your hiring for an internal product with a flexible timeline, by all means hold off until you get the right candidate, its all relative. Basically wait as long as your project requirements allow you to.


    18 Sep 09 at 8:31 am

  3. Each interview should have written test prior interview with basic questions. It helps eliminating junk. Also if onelegged-black-homosexual would blame you for discrimination, you have proof.


    18 Sep 09 at 10:03 am

  4. Hi Alberto, I have translated in french your interesting post : Top 4 des erreurs de recrutement de nouveaux programmeurs. It’s a pleasure to read you. Regards, Fabrice.

    Fabrice Aimetti

    22 Sep 09 at 1:20 am

Leave a Reply