.NET Zone is brought to you in partnership with:

I'm a software developer working as a senior consultant at Kentor in Stockholm, Sweden. My core competence is as a technical specialist within development and system architecture. In my heart I am, and probably will remain, a programmer. I still think programming is tremendously fun, more than 20 years after I first tried it. That's why my blog is named Passion for Coding.  Anders is a DZone MVB and is not an employee of DZone and has posted 74 posts at DZone. You can read more from them at their website. View Full User Profile

7 Programmer Recruiting Mistakes

06.25.2012
| 26426 views |
  • submit to reddit

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.

Published at DZone with permission of Anders Abel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Michal Xorty replied on Mon, 2012/06/25 - 6:00pm

About fizz buzz - I don't like companies that want me to solve unrealistic computer science problems that won't occur in my daily job. If you're applying for job that includes writing internals of Oracle database, Windows operating system or JRockit virtual machine then it's probably good idea. If you're applying for job that requires to write controllers, SQL queries, business interfaces then fizzbuz-like tasks suck. You better ask them for architecting small application to see if programmer understands layers, loose coupling, ORM, dependency injection etc.

Chuck Dillon replied on Mon, 2012/06/25 - 2:48pm

The Fizz-Buzz spec...

"Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz"."

The above is a poorly worded and ambiguous, spec.  I'd be inclined to look less favorably on those that took it without asking for clarification.  If it was given to me and my criticism of it was not welcomed I'd look less favorably on the organization I was interviewing with.

 

Tom Autera replied on Mon, 2012/06/25 - 4:00pm

I agree with all of your points!  Excellent article!

Cristi Constantin replied on Fri, 2012/10/19 - 9:53am

  Hi, in case you have an error that you are trying to find in your code, here is an article I wrote as a general guideline for finding it:
http://efficient-work.blogspot.com/2012/08/find-error.html
  Feedback is welcomed!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.