Hiring programmers, or anyone really, can be a bitch. Sifting through resumes loses its novelty roughly after resume number three. There are only so many times you can read:
I work well independently as well as in a team and I have a willingness and ability to learn quickly.
And if you have advertised on a major Internet job board such as seek.com.au, believe me, you read this a lot.
When hiring programmers in my previous position at WebSpy, I used a programming challenge as part of the initial application. I found this incredibly valuable, but I’m surprised to see that not many other organisations (at least in Australia) use this approach when hiring developers. Here’s why I found it so valuable.
Programmers come in a large variety of flavours. Mint (green, green, green), Vanilla (coding meh-style), Nutty (insane), Rainbow (colourful, but no gold), Triple Choc Liquor with a hint of Strawberry (ambitious and accomplished), Rocky Road (brilliant, but disruptive), and Pralines n Cream (absolutely freakingly awesome in every way).
A resume might help you sift the Mint flavours from the Vanilla, but it won’t help distinguish the Pralines and Cream from the Rocky Roads or the Rainbows. You need to see code.
Resumes are futile
My idea behind the programmer challenge was simple. Show us how you code, and if we’re impressed you get an interview.
A programmer applying for a job with a stock-standard resume is like an actor standing in an audition holding a sign saying “I’m a good actor”.
The challenge was not the typical ‘reverse a string in place’ or other such brain teaser than can be sketched out in two minutes and 5 lines of pseudo code. It was an actual situation one might encounter in the job, and would take a good programmer at least 20-30 minutes to complete.
The challenge at WebSpy involved parsing a tab delimited log file, and producing a summarised table of results. A fairly simple task, yet all solutions we received were highly unique.
From each solution we were able to glean how the applicant approached the problem, how they structured their code, and whether they coded in an optimal way.
And from this, we were able to identify the Nutty Rainbows and the Pralines and Creme.
Why not submit existing code?
You might ask that if seeing code is so important, why not make it easier on the applicant and allow them to submit code they’ve already written?
There is no doubt that if the applicant has been actively involved in an OSS project, or has some killer code available, that it definitely helps their application. For this reason, I still offer submitting existing code as an option instead of completing the challenge.
But there are a few reasons why this option can actually be a barrier for an applicant:
- The applicant’s hobby project was written a while ago and they are embarrassed to submit it as they have since discovered better ways to do things. I’m still happy to receive this code with side notes on how they would go about it now, but it’s still a hurdle for the developer to get off their butt and submit the application.
- They are hesitant about handing over the code to their hobby project as they hope to one day commercialise it.
- The most recent code (or in some cases all code) the have worked on was for a previous employer and they can’t submit it due to obvious intellectual property concerns.
So if the only option was to submit previous code, then we would miss out on many good applicants.
Advantages to a challenge
There are also a couple of major advantages to posing a challenge in the application process.
One of the keys reasons I found the challenge so useful was because it was relevant to the job and we were able to get an idea as to how successful an applicant would be without any specific training. Their solutions to the challenge often proved more insightful than looking at their existing code on a totally unrelated project.
For the applicant, completing a challenge is often more interesting than digging out previous code. When good programmers read the challenge, they can’t help but start thinking about their solution and it soon becomes something they just have to get off their chest. In fact I received an application long after the position had closed, just because the programmer felt like doing it.
Employers – Entice kick arse applications
I personally feel like I’m wasting my time reading resumes or interviewing someone without knowing how they code first.
If you are like me, create a customised challenge for something they may encounter in the job. It should take a good programmer at least 20 minutes and a maximum of an hour to complete otherwise programmers just won’t be bothered applying.
There is also no reason why you can’t use this approach for other occupations too. For example, ask marketing candidates to critique your website, or do a competitive analysis on one of your main competitors.
Then you can interview the best candidates to determine their personality fit and so on.
Employees – Just kick arse!
One of the best applications I’ve received included the solution to my challenge, as well as links to open source projects with explanations, as well as a link to their Stack Exchange profile and development blog.
Ultimately, if you want to win the job, just prove you can kick arse in any way you can. The more original the better!