I’ve had the opportunity since the beginning of the year to be involved in the hiring process at my work. It’s been an interesting experience, and I’ve learned a lot during the process. Most of all, though, I’ve learned that hiring well is really hard.
The hiring process in a smaller company like Agency Fusion (we have 13 people right now) usually consists of screening resumes, sometimes pretesting, inviting for an interview, and then reviewing internally. The testing is sometimes done after the interview instead of before it, and at other times we skip it altogether.
Our CEO usually doubles as HR Manager, and as such, he usually screens resumes as they come in. When he’s thinned out the pile a bit, he’ll send the ones with potential my way, where I do an additional screening. The hardest thing about screening resumes, in my experience, is that most of our applicants are University of Utah students, and their resumes are all pretty much exactly the same. That doesn’t mean that the individuals themselves are exactly the same, but they mostly just list their school projects, which always include a Boggle game, a spreadsheet application, and a new codec for FFMPEG. Very rarely do they include outside projects (which is understandable for kids going to college), so there’s no good distinguishing factor. This is where the testing usually comes in.
Over the past few months we’ve been experimenting with testing our applicants. I don’t like the idea of asking random mathematical or logic puzzles, so we’ve created a test that is directly applicable to our line of work: a rails application. It has a little bit of scaffolding already included and requires the applicant to figure out how to accept data from a form and then spit it out again into an HTML table. There are subtle complexities in the problem, though, that really tease out the ability of our applicants. So far it has been very telling. The applicants that have just gone through the motions in school and done what they were told often miss the main point of the test entirely and deviate from the specifications. Those that have potential are able to work through the problem and come up with a solution that matches what we’ve put in the requirements.
Giving applicants the test also is telling in other ways. Many applicants end up never getting back to you after receiving the test, and others ask question after question, seemingly trying to find an easy way out, or to elicit the answer out of you. Just sending the test in itself becomes a way of weeding out applicants that aren’t really interested or who don’t have a strong work ethic. If you ever apply to Agency Fusion and you get our test (and you actually want the job), complete the test! We don’t care so much that it’s perfect, but we like to see that you put forth the effort necessary to get somewhere with it.
If we actually get the test back from applicants (and sometimes before), we’ll ask them in for an interview. I tried doing quick phone interviews beforehand, but it turned out that I never really rejected anyone after a phone interview, so it wasn’t super useful.
The interview is useful because we get to see what the person is like, face-to-face. This is especially important for our company because we’re so small — everyone gets to know everyone else super well, so culture is a high priority when hiring. Our company is full of different personalities, hair styles, music preferences, etc., but we like people who we can talk with without feeling completely awkward, and we especially like people who have passion for what they do.
The Decision: to hire or not to hire
Then comes the hard part. We usually sit down and discuss what we thought of the applicant. There have been a couple of times where we didn’t need to discuss anything because we knew the person was going to be a good fit. But the majority of the time we just can’t tell. And we’re often sympathetic with the person’s current state of affairs and think that Agency Fusion would be a great place for them to gain experience before moving on to something else. But if we hired those people, we’d both lose out in the end. We’d be paying for someone that we’re not super excited about, and they’d feel that. They might also be overwhelmed by the way we work, or not feel at home with people that are so dang passionate about what they do.
The thing that makes hiring the hardest is when I put myself in their shoes. A few years ago, when I first decided to get into web development, I applied to a whole slew of companies before one finally had me in for an interview. It just happened to be the biggest web development firm in Hawai’i, and they just happened to decide to hire me (I have no idea why!). If I were the person in charge of hiring over there, I have a hard time believing I would have hired myself.
Maybe there’s a super accurate method for figuring out if an applicant is right for your team, but I think I have a ways to go before I figure it out.