7 Programmer Recruiting Mistakes

We’ve all met them. The programmers that can’t program. They can hardly write anything that compiles on their own. Producing quality quality code is way above their skills. Somehow they still get hired. Trying to find out why, I’ve listed 7 common mistakes made during recruiting.

The Seven Mistakes

  1. Focusing on years of experience.
  2. Trust peoples own assessment of their skill.
  3. Don’t ask the candidate to write code.
  4. Recruiting for “the other team”.
  5. Be forgiving to spelling mistakes in the CV.
  6. Focus on technical skills and not communication skills.
  7. Fear of hiring someone better.

Focus on Years of Experience

Years of experience is simple and objective to measure. For any single individual any added experience adds to the skills, so it’s natural to make the conclusion that the number of years of experience is the most important measure for skill.

Unfortunately that conclusion is totally flawed, especially for programming. The single most important skill to become a great programmer is talent. Some people have the aptitude to become a programmer; some doesn’t. The number one priority when recruiting programmers is to find out if the candidate has the aptitude. If the candidate hasn’t, several years of experience won’t help. The candidate isn’t and will never be a great programmer.

Trust Peoples Own Assessment of Their Skill

When interviewing I always ask the candidate of their own assessment of their skill in different areas. Knowing their own view of their skills is critical, but I would never trust them. The problem is that those with the highest competence will usually be very humble. On the other hand there will be candidates that has some basic skills and will boast about it.

Instead of trusting the candidates’ own skill assessment I’m looking for candidates with a realistic view on their skills.

I also use the question to find out the areas where the candidate claims the highest competence. Then I pick one of those areas for the code test. I’m trying to be nice, letting the candidates show their code skills in their strongest area.

Don’t Ask the Canditate to Write Code

I think that a code test is a critical part of a programmer’s interview, yet many people obviously ignore it. I’m astonished by that, because there are people that can talk, but get completely stuck when asked to write code.

The code test doesn’t have to be very hard. Those who can’t program at all will show that even on a simple test. In my recent interviews I’ve used two tasks.

The first is about data access. I present a small database with the tables Persons and Cars. There is also a foreign key from the cars table to the person table pointing out the owner of each car. I let the candidate explain how the relationship is to be implemented through a foreign key, which also requires establishing a primary key on the person table. Then I ask them to produce a simple result set.

Car Reg No Owner Name
ABC123 Anders Abel
LDB109 Anders Abel
CED456 Albin Sunnanbo

I let the candidate choose between LINQ and SQL for implementing the query. Either way, for an experienced developer that is used to writing data access code the query should be really simple to write down.

The other I’ve been using is to write a subclass Square to a Shape base class that I provide.

public abstract class Shape
  public abstract float GetArea();

I’ve also thought about asking people to solve the fizz buzz problem but haven’t yet taken that step. What do you think, should I give it a try?

Recruiting for “the other team”

At the end of the interview I always ask myself the critical question.

Would I like to have this person in one of my projects, sitting at the desk next to mine for several months?

If not, it’s a no hire. As Joel Spolsky writes in his Guerrilla Guide to Interviewing it’s a bad idea to recruit for the other team:

Never say, “Hire, but not for my team.” This is rude and implies that the candidate is not smart enough to work with you, but maybe he’s smart enough for those losers over in that other team.

Be forgiving to spelling mistakes in the CV

Before doing an interview I always read through the CV of the candidate. Of course I look at the information provided, but I also look closely at how it is provided. Does it have a good structure? Is it spelled correctly?

Written communication skills are always important in any programmer job. Even though the programmer will mostly be writing code they should also be able to write documentation and occasionally write emails to the customer. If they can’t express their CV clearly they will probably not be able to express anything else clearly either.

If there are a lot of spelling mistakes that any word processing would mark as incorrect it is a sign of pure laziness to leave them without fixing. If the candidate is lazy about the job application, there’s a huge risk for laziness in the job too.

Focus on technical skills and not communication skills

People sometimes claim that spoken communcation skills are not important for programmers. As long as they write great code that’s all that’s relevant.

In a team environment nothing can be more wrong. It doesn’t matter if everyone in the team writes great code if they can’t communicate their intentions. To produce a great result the team has to work together on a collective idea.

I usually ask the candidate to outline the architecture of a previous system worked on. It doesn’t really matter what system it is. What I look for is if the candidate has understood the basics of the architecture and can communicate it.

Fear of Hiring Someone Better

The technical interview (if there is one at all) is usually performed by a senior developer or architect. That developer probably has a certain position in the company, being the only one knowing how to solve the really hard problems.

What happens if an equally good, or maybe even better, programmer is interviewed? There are two possible reactions from the interviewer.

  • This person is really good, I won’t be the best at the company any more. This will threaten my entire position.
  • This person is really good, finally I’ll have someone that challenges me. Together we can form a really strong team and become even better.

The threat thought is very common (not only among programmers). Unfortunately it leads down the road of ever falling competence, if everyone always recruits someone that is less competent than themselves.

Would you dare to hire someone that might be better than yourself?

Hiring is Hard

Hiring is hard and requires hard work. It requires self confidence to dare to hire someone that can challenge yourself (in a positive way). It requires some very tough decisions in the end, taking the “no hire” option even if their is a huge pressure from management to grow the company.

I sometimes think of recruiting as having a single date and then having to decide whether to break up or propose. It’s a decisions about what people you will spend 40 hours a week with for the next few years.


  1. Of course every newbie programmer should be able to solve the FizzBuzz, but one thing that tells of the programmer is experienced or not is the use of design patterns.
    Give the candidate a small and easy to solve task and take a look a the implementation details. Is the code smelly or does it comply with a design pattern. Don’t be afraid that it could take some time for the candidate to solve the task.

    A common task could be: Create a program the read files from the disk and for each file type do something different. Hint: Don’t break the open-closed principle.

    Such a task will tell you a lot about the candidate; is he able to develop maintainable code, is he able to understand design patterns and is he able to read a specification :)

  2. I continue to be shocked at how often candidates make it to a face-to-face interview and then fail to be able to write code for very simple problems. Fizzbuzz is a great example. It seems trivial, yet many candidates will not be able to code it. At my company we often have candidates implement a simple string processing function from the C runtime library. It’s something that any competent programmer should be able to code in a short time, yet people often spend 45 minutes on it without getting to a working solution.

  3. You forgot one important bullet point for: “Fear of Hiring Someone Better”

    This person is really good, finally I’ll have someone that challenges me. Unfortunately the flip side is that they eventually realize that their manager is not as good as them and they learn nothing.

    I have learned my lesson and never join a team that is not on par with my abilities. If I find the interview questions to basic (write an outer join in SQL, what is encapsulation?) I pass on the company. If the manager is a non-techie, that is another bad sign.

  4. I’m sorry but i can’t agree with “Be forgiving to spelling mistakes in the CV”. Maybe it is fair for english written CV, but it isn’t relevant for east european languages.The best programmers I have hired have made too many grammar errors in their CV ;-)

  5. Thanks, that was a great article with lots of useful hints. Love the concluding message with breaking up or propose :)

  6. For quite some time now I have a dilemma regarding the difficulty of coding test.
    You see quick and straightforward tests will definitely weed out the candidates that just aren’t a good fit (that do not possess the pure basics).
    But as Ivan mentioned in the comments if the test is not a challenge at all for them then they will start assuming that this is some kind of level threshold for hiring…
    But it isn’t, this is a simple filtering mechanism which helps a lot in time saving…

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.