Hiring a Developer

Hiring a software developer is an important step in creating a good quality software product. Unfortunately, building a great team is a lot trickier than it seems.

I've been part of hiring processes that have gone well and lead to adding good, quality individuals to a team. Unfortunately I've also have been witness to some of the worst decisions ever made in a hiring process. Through this list, I will try to expose some of the mistakes I've experienced in building a great team of developers, and help you make the best decisions in your search for better software developers.

Mistake #1: Giving Too Much Credit to a Resume

Any search for the perfect candidate starts with a pile of resumes. These can be an excellent tool for finding those candidates you want to invite in for a face-to-face interview.

A typical developer's resume consists of three important parts: work experience, education, and a list of technologies they've worked with. While work experience is critical in finding a good developer, giving too much weight to these last two sections is a sure-fire way of making a poor hiring decision.

Education

It is incorrect to make snap judgements about the skill of a developer based on their education. If an individual attained an extremely high GPA, that's an indication that they're very studious, and have an excellent work ethic. That doesn't necessarily reflect how they work with other people. If a candidate graduated with a bachelor's degree in computer science, they probably have an excellent foundation in the history and basics of theoretical computing. That doesn't mean that they are skilled in current development practices, which is an important trait attained by doing, not studying.

If you're hiring a candidate directly out of school, look instead for any internships or apprenticeships they may have had. On-the-job experience is worth its weight in gold. If they put in time at a reputable development shop, even better.

Skills

The skills portion of a developer resume is a useless list. To drive this point home, let's take a look at the skills section of my own resume from 2007

Now here's the truth about this list: I couldn't write a line of PHP from rote memory if my job depended upon it, and my Apache administration skills consist of googling for the problem I'm trying to solve and copying and pasting it. And I don't remember a single CVS or Subversion command.

So what's the takeaway from this? The skills portion of a developer's resume is simply not dependable. In this section, people can get away with outright lies. That's not to say that everybody does, but the information contained in this section is largely unverifiable. But really, that's not the most important thing on a resume. More important than technical skills in a developer is the kind of developer you'll be hiring.

Technologies are fleeting. They are often pushed out of the way in favor of newer, better technologies. So if you hire a developer solely based on the technical skills they know when they start, logic would dictate that their usefulness would get pushed out of the way along with the technologies that they know. Meaning you would have to replace them.

But that's not very nice, and this model is not realistic. What you should really look for in a developer is their soft skills. These soft skills (communication, the ability to adapt quickly, work ethic, general problem solving skills, empathy), are things that are difficult to glean from a resume. Soft skills are things that you can only make assumptions about when you're working with an individual. I'll touch on how to to this later in the article.

Mistake #2: Working With a Technical Recruiter

Technical recruiters are commonly employed to help find skilled labor, and they seem like an economical solution to a tricky problem. Technical recruiters spend a majority of their time networking, and finding out who is looking for employment in the area. This gives them a large pool of talent to tap into to satisfy the needs of employers.

But as a developer who's worked with technical recruiters to find employment, there is one major observation I've made. Technical recruiters have one goal: to place talent with employers, not to find the best fit for either parties.

For me, a typical phone conversation with a technical recruiter goes something like this: (My cell phone rings with a phone number that I don't recognize)

While that recounting is somewhat hyperbolic, it's not too far from the truth. Recruiters are very pushy when it comes to placing individuals, and that makes for a poor fit for both parties.

Instead of relying on a recruiter to find talent, it's not that difficult to find it on your own. Local users' groups are an excellent source for finding talent. It may seems daunting at first, especially if you're not a developer yourself, but the participants are welcoming and would be happy to give you advice in your search for hiring a developer. The individuals participating in user groups are going to be knowledgeable, but even more importantly, they're going to be passionate about what they do. People don't get paid to go to these meet-ups. They attend because they love what they do, and are excited to hone their craft and share their knowledge with others. Isn't that the kind of developer you'd like to hire?

Mistake #3: Minimizing Your Team's Role In Hiring

Decisions

Once, I was part of a hiring process where the team was not given enough credit for making hiring decisions. A manager (who was technical, but not a software developer), was in charge of the hiring process. He'd created a job posting on Monster.com for a Ruby on Rails developer.

We'd had several leads which led to interviews. The other developer and I spent time with about three interviewees, all of which had no relevant web development experience. We could have been spending our time doing much more important things, but instead we had to slog through these interviews that went nowhere. When I expressed my concerns to the manager about the need to explore more efficient channels of candidate search, my pleas were met with:

"You can't be so picky! This is Grand Rapids [Michigan] not San Francisco. You're just not going to find good[web] developers here."

These assumptions were unfounded. Grand Rapids has a vibrant and passionate development community. In it, there are technical individuals who range from freelance developers to seasoned individuals who work for corporations like Microsoft, Apple, and Google.

This manager was not able to make a proper assessment about the development community as a whole, because he was not a part of it. If you're a non-technical manager, or a leader who is somewhat divorced from the development process, you probably do not have the proper insight to make a decision about who would make a good fit on a development team, but your developers do.

Developers need to play a significant role in your hiring process. They know the type of people that would fit well in the team culture, and they understand the tools and technologies that are required better than anybody, thus making them the perfect people to evaluate potential candidates.

Mistake #4: The Wrong Kind of Interview

Tell me a little about yourself.

Describe to me a situation you found difficult and how you handled that situation.

These types of “getting to know you” questions are difficult to avoid. But they get the ball rolling in a conversation between strangers. Unfortunately I've seen developer interviews resulting in hirings that didn't get too far beyond this, usually performed by HR representatives or non-technical managers. This is possibly the worst way that anybody could hire a developer.

At Mutually Human, we split up interviews into multiple parts. The first part is a general interview. This is where we get to know a candidate a little better professionally and personally. It's a good idea to make this interview as comfortable as possible. In the past we've taken a candidate out to lunch, or have driven to a local park and played bocce ball. The idea of free food or friendly competition alleviates the nervousness that's inherent in more traditional sit-down face-to-face interviews.

If we get a good impression from the candidate, then we invite them back for a second interview. During this interview, we pair the candidate up with a developer, ideally several different ones throughout the day. That way, more of the team can get a feel for the candidate, democratizing the decision. The candidate is placed onto a project with a little ramp up and expected to pair program with the other developer. Pair programming is a practice in which you have two developers in front of one computer. One developer types on the keyboard, while the other talks about what they are doing. It's a social activity, and this exposes how well the candidate can communicate.

It's at this point that we can tell with pretty high accuracy how a candidate will work with other developers. We're not looking for technical skill. We want to get a good feel for those soft skills mentioned earlier. We're looking for a candidate to make mistakes, learn from them, and be humble enough to ask the right questions when the time is necessary. We also look for general personality fit. If it's easy to have a conversation with an individual when you're working with them for the first time, it's likely that you'll still be able to continue that rapport after time. And this is a positive skill to have when you're working in a trade where good communication is critical. If it's difficult to have a normal conversation with the candidate, that's a red flag that it might be difficult to interact with him/her later down the road.

Conclusion

Hiring can be a stressful and time-consuming endeavour. In general there's always a good chance that you might hire somebody who's not a good fit for your needs. But there are always a few good practices that you can take to ensure that this doesn't happen.

As long as you make sure you're looking for the right criteria in a candidate and including your development team in the hiring process, you're bound to be able to find a potential hiree's strong points, and easily expose qualities that you might not want in a developer. Happy hiring!

If you're a developer looking for work, our hiring process is still open. Please read this post for application guidelines and contact information.