The topic of ‘hiring’ always generates a lot of discussion. And why not? Talking about hiring is a convenient way to pass judgment on large groups of people while keeping a professional, detached demeanor.. Ouch! But the topic has enough technical basis to warrant the interest of experienced developers, so here we are.
This post is for those who handle the technical evaluation necessary to hire candidates, especially in the Ruby and Rails scenes, although the overall strategies are language-agnostic (though I’d hope if you’re hiring folks to work on missles and nuclear power planets, all bets are off).
This is a guest post by Tim Goh of Trikeapps, an Australian software development company. More info at the bottom of this post.
Some Structure
While hiring processes differ, I’m organizing my advice by the following components that, assumedly, most processes include:
The job posting itself
The coding test
The phone screen
The Job Posting
You need a permanent “Careers” page
You should have a permanent careers page on your company site and constantly correspond with candidates, even if you’re not hiring at the time. The goal is to populate a queue of developers you can subsequently start to contact the moment you have an opening. This way you hire only after the need, while identifying talent before the need.
You can also continuously refine and test your hiring process against more candidates in this way as well as get a more accurate picture of who’s looking and who’s available, instead of peeking out your window to see who’s there only when you’re hiring.
Include a filter question
You want to easily distinguish the genuinely interested from those who are simply applying everywhere (blasting resumes out semi-automatically has become very common in these shaky times). With the right question you can design a mail
filter around the answer and automate away those who aren’t paying attention.
Such a question might be as simple as:
What is the MD5 hash of the string ‘I am not a resume spammer’?
Make the question more difficult if you’re getting too many resumes that qualify at this stage. The Dropbox Challenges and Facebook Puzzles pages have good examples of non-trivial coding questions.
Providing a larger set of questions and making some optional allows candidates to signal their desire, and gives you an easy sorting function to use on your incoming applications. If you want to hire someone who’s particularly creative, their response to the question may also be an indicator of this.
Include more information about your company
Qualified applicants will be more choosy and select a small group of job ads to send their resumes to. Help them make that decision by providing as much information about your company and the role you’re hiring for as possible. Just as you would balk at a resume that solely said ‘I’ve been coding in Ruby since 2008’, a job description of ‘develop web applications using Rails’ would deny valuable data to the talent you’re looking for.
In days of yore it was popular to include the Joel Test in job postings. This is a high signal way to communicate about your company’s processes, and you could follow a similar template.
Job boards may not allow for the best presentation of your company (Ed: Tim is lying, the Ruby Inside Jobs Board is undoubtedly awesome! ;-)).
(No Ratings Yet)