[tags]hiring, resume,interviewing [/tags]

You're growing your team. How do you sift through the pile of incoming resumes? For younger candidates, how important is a GPA? For more experienced candidates, how do you qualified relevant experience?Most job applications arrive electronically these days. Email is a wonderful thing and makes it extremely easy to receive applications without the overhead of taking phone calls. Unfortunately, this also means that many unqualified applicants can submit their resumes with relative ease. Applications will come from people with little or no correlation to those listed in the description of your job opening. Traditional wisdom would be to read all the resumes and sort them into a pile of 'good', 'questionable', and 'no'. You schedule the 'good' pile for interviews first and if no worthy candidate presents them self then you proceed to the 'questionable' pile.

Identifying interview candidates this early falls short of my needs in third respects.

  • I need to keep hiring rolling. I cannot wait three weeks for the pile of resumes to build, and then cutoff accepting new resumes to begin the process.
  • In my experience, a resume proves tangentially helpful to assessing an candidate without additional information. Specifically, a resume cannot tell you whether a candidate possesses the skills they put on their resume or not. How do you get a good read when candidates only send a resume and cover letter?
  • The 'questionable' pile contains too many candidates for me to interview.

Don't read them. That's right, ignore them entirely. Instead, send them a questionnaire in response. This brief questionnaire will ask the applicants to rate their skill level on a 1 through 10 scale in six to ten technologies/topics that were listed in the opening or relate directly to the opening. The responses to this questionnaire are not necessarily a good indication of skill. That means that someone who rates them self as a six might be just as good if not better than someone who rates an eight. However, if someone lists a zero, one, or two for some or all of the skills then you can be pretty sure they're not a good match unless you're planning on lots of training.

The biggest suprise with this tactic will be the honesty of the respondents. You will get a number of people who might have made it into a screen interview who will tell you they have absolutely no relevant skills or experience for your position in response to this questionnaire. This alone saves you from wasting lots of time talking to them and discovering that they are indeed beginners of their craft. Since we've skimmed these self-proclaimed unqualified applicants off the pile it's time to figure out who actually knows their stuff.

For developers I hire, I have a list of the top 30 topics under four or five headings (such as Linux, PHP, MySQL, Design, and Process) that we discuss and use every day. These include everything from 'vi' to 'Extreme Programming'. Choose topics that are quintessential to the job. It's important that some require insight and some that can be answered with a simple query to your favorite search engine. It's just as valuable for this list to be somewhat vague. This will increase the variety of answers you get some of which are "right" and some of which are just "off". These are in quotes because only you will learn which answers are off base and which hit the mark. For example, when I ask people about security in PHP some people say things related to input validation and SQL injection, while others mention topics like protecting your SQL password or turning on safe_mode. What's important is knowing which answers come from someone who's worked with the given topic and the answers from someone who hasn't.

Use your other resources to evaluate their answers. Compare their answers with their skill levels professed in the first questionnaire and their experience on their resume. Any conflicts raise questions--

  1. "how can your skill in PHP rate 9/10, but you cannot describe PEAR?",
  2. "your resume indicates you spent 4 years working with XHTML/CSS but you rated yourself 2/10, why?"

Do realize, that with a long list of topics a very few number of candidates will know all the topics to the desired depth. I make no stipulations in the instructions for whether or not it's acceptable to research the topics in order to provide an answer. Some people admit ignorance, others cite their sources, and some copy and paste. After reviewing a number of them it becomes more and more clear how to distinguish. Those who know their stuff will answer consistently with ample information to back up their claims and admit areas of lesser experience.After the second questionnaire you will notice a decrease in responses. Hopefully those people have either decided it's too invasive to answer all these questions, or have decided that even though they lied in the first round their bluff has been called. The time has come to schedule interviews (or telephone interviews for those off site). Each respondent goes into the 'interested' or 'not interested' category based on the two piece of standard information (the two questionnaires) and the entirely nonstandard information--the resumes. The questionnaires will show some people apply knowledge and intelligence to their answers while others don't. Look for answers that show experience or even preference. Using the example above, I get many responses to the 'vi' topic that say 'I prefer emacs', or 'I use BBEdit'. These show to me that someone has heard of vi and have made their own judgment as to what they like better.

In evaluating the second set of responses I mentioned the value of comparing with experience and statements made on a resume. At this point, insight into the history and personality of a candidate emerge by reading the resume by itself to learn why and how people might have obtained the knowledge you saw in their questionaires. Do they have three degrees from prestigious universities? Do they scour the internet for interesting tidbits about technology? Or did they search for the answers on receipt of the questions? Thinks I like to see: diversity shows an ability to learn new things quickly, but means you should verify depth of knowledge in the interview.

In your decision of who and who not to interview start considering the fit with the team. Make sure to welcome candidates to the 'interested' pile who have skills or experience which complement those of your team. Perhaps they have expertise in an area which your team lacks. As you consider the candidates during the interviews this will be more crucial.

An interview will allow you to untangle all these indicators and weave a more complete picture of the candidate. I save the interview process itself for another time...