IGNAZ Softwaremanufaktur

I am not a human resources guy and have not hired a lot of people. But I am a freelance developer and I love my job so I know what is important and what is not.

The client I am working for needed an extra developer to get all the work done. So he assigned me to search for a great developer.

I wrote a job ad describing what was important to us. I was searching for a Django developer. A person that has a passion for writing beautiful code, has a "getting things done" attitude and knows our core technologies. I also gave an overview of the job they will have to do, so they get the feeling that they will indeed do an essential part. That their doing really matters to the system as a whole. I also requested them to send a CV and a "why i am the best for the job"-letter to our contact e-mail address.

Than I posted the job ad to mailing lists for developers that use our core technologies. I posted it also to Twitter, Facebook, Google+ and sent it to the hacker space in our town. I also asked ex coworkers and friends from university.
And after setting the bait, the waiting began.

I got three kinds of responses:

• The first were the guys that just sent a link to their website.
• The second were the guys that wrote a two sentence letter accompanied with a CV where they listed every technology they ever used or just heard someone talk about. 
• And there was the third kind – the ones that really wrote an actual letter why they like to develop software, how they work, what projects they have done and what they contributed.

You can forget about the first two. A person that is not able to write a letter why he is the right for the job is probably very sloppy in doing his work. And a person that lists a whole lot of technologies will do everything if you pay him, but will probably not be really good at one particular thing.

So send them a short email where you thank them for their application, but you found someone else. (This is important – at least to me. They are people too and need to plan their future. So just give them a short note and do not waste their time while waiting for your reply, not being sure about your answer.)

Ok, focus on the third group. Invite them to an interview. (By now you probably have your favorite candidate.)
In the interview you get to know your candidates. Focus on the following questions: Do they fit into the team? Do they have experience in the field you are searching someone for? Is he confident? (After the interview your favourites might have already changed. Maybe your former number one just looked good on paper.)

At the interview you should also tell them that they will have to do a coding test. Tell them about the process: You will send them two assignments via e-mail. After one hour they send you back their code. The candidates just need one hour more of uninterrupted time.

We did test assignments that where closely related to the work they will have to do in the job. Preparing a basic project setup, we also built in some little problems (e.g. unicode issues).
We also put “.git” directory into the barebone app. So they could earn some extra points if they would commit their changes to git.

When you get back the test code, a lot of things will become clearer – at least in our case. You will get a quite good feeling for how someone is programming. Is he sloppy? Does he document the code intensely? Does he use standards? How is his naming of variables? Does he write test code? And so on.

We had three really promising candidates: Tim, Jack and Michael

In our case Tim was our favorite candidate after the e-mails followed by Jack and Michael.
Tim simply had the best CV and had a lot of experience on the job.

After the interview Jack lead the race since he made a confident impression and seemed to have an opinion on quite every subject you would throw into his direction.
Followed ex equo by Michael and Tim. Tim was especially nervous and not very good in selling his strengths. Also being a little bit shy about his skills and clearly not overstating his experience.

Then, at the code test shy Tim blew us away. He did really clean and readable code. Almost a perfect 10. Michael did also a great job but not as perfect! The confident Jack sent us some really sloppy code – some stuff was just plain wrong and he only got half of the stuff done. Pretty disappointing – especially after the good and self-confident impression we had from the interview.

So after all this, we were pretty sure Tim and Michael would be perfect fits for the job. Jack was out. Imagine yourself who was our winner in the end.
But that’s not the point! Just going by the default hiring process we would have stopped after the interview and probably hired Jack and let go of our two finalists.

Sure, all this takes some time of preparation, but it is worth it. You just can not afford to employ B-Grade people if the success of your company depends on the software they are writing.
Just invest the time needed to complete this process. What is one day of preparation compared to (maybe) multiple months or years of co-working with the second or third best fit available.

(by Anton Pirker and Stephan Pötschner)