Hiring Developers


Pam Selle's blog post about burning your resume struck a chord with me. Resumes are antiquated and counter-productive; optimized for people to not read them. She goes on to say that, as a developer, your best bet to find a good job is through networking and provides some helpful tips to get you started. I couldn't agree more.

Some people think GitHub is your resume (I disagree). Others think life would be better if resumes were JSON. I think there is plenty of focus on "solving the resume problem." What's more important to me is the tragic state of hiring in our industry overall:

There's much room for improvement, but I don't expect tech hiring to vastly improve in the short term. Developers create so much value that any waste in the hiring process (and the occasional bad hire) has become a relatively low economic priority. That doesn't mean these problems don't do very real damage to the people involved. A bad hire can be toxic to a team. A poor screening process can contribute to burnout. You may join a team and find out they are terribly dysfunctional and find yourself stuck there.

In my 15 years-or-so of experience as a developer and manager in a wide range of companies and technology stacks, I've been on both sides of the interview table too many times to count (i.e. a three-digit number) . I've noticed some patterns I wanted to share with the rest of the class.

Tips for Employers & Interviewers

First, make sure you actually want to hire a developer. If you don't self-identify as a "software company" then it's very likely are you should bring in a contractor. This can be perilous but will save a lot of money in the long run if you do it right. That's a topic for a future post.

Assuming you really do need to hire a developer, you must invest in a screening process. Expect to spend a nontrivial part of your time focused on it. It's like a sales funnel, where leads become prospects become customers. You don't just "wing it" when it comes to managing a sales funnel do you?

A common complaint from employers is it's "hard to find good people". Since this isn't universally true, it means your screening process needs some work. If the ideas in this post seem like too much work, seriously reconsider your desire to hire a developer, for the sake of everybody.

1. Finding Qualified Candidates

The core of a screening process is identifying which traits you are looking for. Writing a job description is very subjective, but one piece of advice I can give is to avoid long lists of specific languages, tools, libraries, frameworks and so on. A tool-heavy job description says to many readers that you are looking for a cog in your machine, not a human being who is capable of (and enjoys) learning. Try to strike a balance between technology, experiences, preferences and soft skills your team needs. Explain without jargon what important problems your company solves.

Once you have a description, don't just delegate resume intake to a commissioned tech recruiter. Any time/money you think you will save will be lost on either recruiter fees or politely fending off sales tactics. Of course networking is a great way to qualify people but what else can you do to avoid getting spammed with resumes?

Remember your goal here is just to find people who can code!

DuckDuckGo is a good role model. They look for developers who contribute to their open source projects before progressively engaging with them. It demonstrates the candidates are genuinely interested in the company and yields real code to review.

If this doesn't work for your company, a simple homework assignment is probably the best screening technique. Design an exercise which would take no more than two hours to complete, is appropriately challenging and has minimal/no set-up time (e.g. just a text editor and few dependencies). Optionally, you can make the instructions a little ambiguous just to see how people handle it. Simply require that all resumes be accompanied by the homework assignment and a list of whatever questions/assumptions the candidate had along the way and presto.

Don't worry about this tactic turning away good candidates. In my experience, good candidates view it as an encouraging sign.

Some homework examples I've encountered in the past (these can be very fun to design, by the way):

2. Initial Phone Screen

Your next goal is to ensure no time is wasted on pointless in-person interviews. Have a 15-30 minute casual phone call with them to ask the important questions (e.g. their motivations) and confirm they can communicate. Do not grill them with technology questions. You cannot reliably assess technical depth on the phone. Allow time for them to ask questions about the position to make sure their time is also not wasted.

3. In-Person Interviews

There is a lot to be said about specific interviewing techniques, but overall, the most important thing is to simply prepare for them.

Make sure the candidate is comfortable by explaining the dress code, where to park, who they will meet with, etc. Put yourself in their shoes. Do it as a courtesy and to avoid their stress reactions from clouding the assessment.

Make sure the interviewers understand and agree on what traits they are looking for. Since you will need to make a group decision afterwards, try to keep the total number of interviewers to a maximum of seven people (think dinner party). Don't worry about people asking the same questions of the candidate, it's not really possible to avoid overlap.

Do not engage in any of these practices:

Try asking questions which focus on the important stuff: how they learn things and apply them to achieve goals in a team environment.

4. Decisions

This is probably the hardest thing to get right. The root causes for failure at this stage I've seen are:

How you make this decision is entirely dependent on your team's needs and culture. I think the most important thing is to reject any candidates you are unsure of. Everybody should be unanimously excited about this person joining the group and ready to "step up for them". Anything less is almost always results in a bad outcome.

Take time to do a short retrospective on the hiring process each time you reach this stage, regardless of the decision, to make any course corrections. Don't be surprised if you reject the first batch of people who make it through to the interview since you are still refining your process.

Tips for Job Seekers

If you're having trouble finding opportunities then you probably need to do the usual stuff: re-train, network, contribute to open source, etc. If you are inside the hiring funnel, here are some bits of wisdom I've acquired the hard way:

Do It For the Kids

Computer Science and Business degrees are all the rage. Let's do our best as an industry to improve hiring if not for us then for the next generation. If you are in a position to influence a hiring process, reject the status quo if it doesn't make sense to you. If you are a job seeker, don't tolerate any shenanigans.

[ Archive · Home ]