The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

Slightly Less Awful Hiring for Engineering Talent · Code for America Blog Archive

Posted on Dec 11, 2015 by William Pietri

Tags: CfA Staff, News, and Technology

When I set out to hire new engineers at Code for America, I hadnt been here long myself. I remembered how painful a job hunt is and wanted to do hiring differently. Plus, Code for America is committed to building a team thats as diverse as America, a goal I enthusiastically shared. Most hiring processes are built for the convenience of companies and managers, not applicants. That seemed like a mistake given how hard it is to find developers now, so I tried a number of experiments. Some worked well enough that I wanted to share the results with the public.

Making the job description

The job description is the only thing most potential candidates will see. Given that, its a mystery to me why so many of them are terrible. That worked to my advantage, though; being obviously better wasnt much more work. Some of the things we did:

Making the job description

The job description is the only thing most potential candidates will see. Given that, its a mystery to me why so many of them are terrible. That worked to my advantage, though; being obviously better wasnt much more work. Some of the things we did:

You can see what we ended up with here:

Raising a ruckus

Theres enormous competition for the attention of qualified engineers right now. We did our best to get the word out, including:

Responding to applicants

In talking with people about their job hunts, their number one frustration was lack of response. That seemed fair to me. They put in time to apply; shouldnt we put in time to read it? But what most applicants dont see is the tidal wave of applications that are basically resume spam. Generic resume. Generic cover letter. No indication of interest in the actual position. No indication of putting any time in. How to reconcile those two things? My approach:

First-round interview

Most tech interviews are frankly awful. The two most common activities are solving puzzles and writing code on a whiteboard. Ive been on both sides of the standard interview and Ive decided its a giant waste of time. Why? Its nothing like the actual work. Normal interviews are tuned to make interviewers feel smart and powerful, not to find great colleagues. My solution is to make the interviews more like day-to-day job activities. The first round was about the ability to code and their technical knowledge. I started with a 90-minute pair programming interview. Pair programming, for those who havent tried it, is where two developers sit down with one computer and collaborate on solving a problem. Its my favorite interview technique. Things that made this work well:

After we were done with the pair programming section, wed turn to a whiteboard. Id sketch a real-world technical scenario and wed talk about how it worked in practice. My goal again here was to get an understanding of their strengths. Id start broad, so that everybody had something sensible to say. Then Id drill down on particular things, probing for technical depth. One of my goals while doing this is to find something that they know that I dont. I want them to feel challenged, but never humiliated. One interesting mistake I made here was in picking the Mars Rover kata. It seemed like a reasonable choice to me and others on the team, but it introduced a bias. Some people, typically those with science-ish backgrounds or long coding experience, took naturally to the problem. But for others, the notion of a Cartesian grid was novel. That caused anxiety and delay as they struggled with what I had wanted to be the easy part. I gave extra time to compensate, but next time Id just pick a sample problem that is either more related to the project domain or more generally appealing.

Blind review

Once we had a reasonable number of interviews completed, the question was who to bring back for the next round. Keenly aware of how easy it is for bias to creep in, we tried blind reviews of the code. To do that, I checked each interviewees code into a private GitHub repository, with each directory named for a hash code of the interviewees name. (The real name was also checked in, but encoded so that it wasnt easily visible.) The developers on the team reviewed the code, sat down together, and ranked each applicant on four axes: completion, low-level code quality (that is, how it looked line by line), high-level code quality (taking it as a whole), and test quality. We ended up with a whiteboard like this:

Once we had ranked the code samples, I pulled out my notes from the pairing sessions and we talked a little about impressions, especially how good they were at collaborating, and how they did on the technical discussion. That led us to pick four people to bring back for second-round interviews.

Second Round

Running again with the theory that interviews should be pleasant and similar to a normal day at work, we booked candidates for a 2-hour session with the team. The first hour was a relatively relaxed joint discussion. We all talked about our backgrounds, discussed the work and the industry, and got to know each other a bit. We tried to keep the tone casual and the mood friendly. Too many interviews feel like inquisitions, and that would give the wrong impression about Code for America, a collegial place. In the second hour, the non-developers left; the rest of us had a focused discussion about a feature we planned to add. Here the goal was to see how the candidate thought, both from a technical and a product perspective. Could they see which features were key and which should be left for later? Were their implementation choices practical? Could they adjust their architectural notions if the use case changed? Were they good at collaborating, being neither too controlling nor too obedient?

Making offers

Ranking, surprisingly, was pretty easy. After each second-round interview, we spent 10 minutes or so discussing the candidate, and then sorted them by rank. There was no serious disagreement, and by the time we had completed all four second-round interviews, we were ready to make offers. I had intended to send offer letters out immediately, but didnt realize that there was a few days lead time. Next time Id start work with HR to prepare blank offer letters when we started the second-round interviews so that we could respond more quickly. The other change Id try to make was to find ways to have hiring be less batch-oriented. In my previous startup experience, recruiting was an ongoing effort; when we found somebody good, wed hire them. But here we were trying to fill a single position, so it made sense to see a bunch of people and pick the best. It made sense from the hiring side, anyhow, but for most candidates it resulted in a fair bit of lag time between initial contact and decision. They were understanding and I tried to keep them updated, but it still would have been much better for everybody if we could have given them faster answers.

Conclusion: go do it!

My main conclusion from this was that making hiring easier and fairer wasnt that hard, and it was certainly worth the effort given the quality of the candidates we got. You may not have the time to try everything I did here right away, but dont let that stop you from tweaking one thing and seeing how it works. Good luck, and feel free to contact me with questions or feedback via Twitter.

Continue reading on