Current mood:

lethargic

Recruiting programmers
One of my favorite job functions in my nearly 5 years at the Danish portal site Jubii was the one as recruiter. There was no common HR department at Jubii, so the departments had to hire people themselves, and once I started acting as a lead programmer, my boss at the time also thought I should hire the people I was going to be working closely with. In the beginning we were both together at the job interviews, but soon we decided to split up, so that the applicant had to “get past me” in order to get the final job interview with my boss.

It was not easy to get past me, and I am going to tell you why. To me, a job interview with a programmer isn’t just going through the resume and talking about this and that. The applicant has to be more than a nice guy with an IT-related education and some business experience; he also has to prove that he thinks like a programmer, so I created a series of small tests the applicant had to go through during the job interview – I will get back to them.

I am fascinated by the significance of the first-hand impression at a job interview. I would like to be able to say that I didn’t judge the applicants by the very first glimpse I got of them, but I have to admit that it was unavoidable not to do it. The first-hand impression always gave the applicant a slightly better or a slightly worse starting point – it’s impossible to stay neutral. I can’t really control what I look for in a first-hand impression, but I think it comes down to this:

• Does the applicant look like someone I could have as a friend?
•  Is the applicant wearing the expected “working clothes”? (A programmer doesn’t wear a suit in my mind, but rather relaxed jeans and a t-shirt with a funny logo.)
• Is the applicant nervous or relaxed?

It’s extremely unfair to judge applicants by questions like these, so my point with this is; that if you are recruiting someone, you should be aware of what you are looking for in the first-hand impression, and then try to control it.

Back to the tests. Most of the test I “created” are actually stolen directly from Joel Spolsky’s excellent article; The Guerrilla Guide to Interviewing, and the whole structure and focus of my job interviews was also heavily inspired by that article, so I can’t encourage you enough to read it. For the job description “ASP and ASP.NET programmer” I chose to use the following tests:

• Programming on paper: Reverse a string.
• Questions about object orientated programming
•  The design question
•  The impossible question
•  The LEGO assignment
  

I won’t dig to deep into the first two tests, other than saying that it’s actually rather hard to find a  programming assignment that can be solved in 10 minutes using nothing but pen and paper, and it’s even harder to think of a small assignment that will show if the applicant understands object orientated programming. Try it.

Both the design question and the impossible question are explained in Joel’s article, so I won’t do it here, but just give some examples. My favourite design question is this:
“The first skyscraper in Copenhagen is being built for renting out as office space, and you are the designer of the elevators of this 50 floor building. How will you design the elevators?” Remember that the primary focus of the design question is out-of-the-box thinking.
My favourite impossible question is this: “How many litres of milk did the Danish population drink last year?” I’ve got answers all the way down from a couple of million litres up to several billion litres, but the important thing is that I have no clue about what the real answer is. The impossible question is all about watching the process of the applicant reaching his answer.

The LEGO assignment is my own invention. Joel has his mantra that a programmer should “be smart, and get things done”, and I think that’s a great guideline for hiring programmers. However, I wanted to be able to test the “get things done” part, and the LEGO assignment is my attempt to do this. The applicant gets a huge box of mixed LEGO bricks, and then he gets three minutes to solve the assignment: “Build a transport vehicle that has to the following characteristics:

• It must work on land, in water and in air.
• There must be seats for at least four persons
• It must have a parabolic antenna
• It must have front lights, rear lights and warning lights
• It must be blue”

Three minutes is of course not enough to build anything that actually looks real, but it is indeed possible to incorporate all the characteristics if you make a couple of compromises and prioritizations. And that’s were the real benefit of this assignment comes in; the talk about the vehicle and the decisions of the applicant after the three minutes has passed.