As the CTO of TrackAbout, one of my jobs is to hire and retain awesome developers. We used to be horrible at this, and today I’m happy to say we don’t suck. This post looks back at the evolution of our approach to recruiting.
We’re growing, and while that’s very exciting for us, it also means a lot of recruiting. All of our developers work from home, which means we get to hire people anywhere in the country. It also means that we can get buried with applicants.
Years ago, when we hired our very first developers, our process was terrible. We’d broadcast a job to the typical job boards (free ones, whenever possible), then sift through a deluge of emailed resumes. We were looking for clones of ourselves, and if someone used the exact same technologies we were using, we’d invite them to interview. One interview, maybe two tops. Sometimes we’d fly a candidate in, sometimes we wouldn’t. The interview questions were hastily compiled, often disregarded, and we’d make calls using our gut. Predictably, the results were awful.
TrackAbout is a company that, at its core, believes in continuous improvement. We are passionate about getting better and leaner in every facet. Compared to 10 years ago, our recruiting process has progressed by leaps and bounds.
I’m in a unique and fortunate position in that my wife, Shari, happens to be a human resources professional with a focus in Organizational Development, and who has done a lot of tech recruiting. We’ve relied on her sage advice at many stages along our journey.
When we realized we weren’t asking the right questions in our interviews, we studied behavioral-based interviewing techniques like Targeted Selection and Top Grading. Now we feel like we have the tools to get at what’s really important in the limited time available in an interview.
In November 2009, we got the entire development team involved in the recruiting process. They deserved a say in who they got to work with. We devised a series of technical interviews that require candidates to discuss specific programming practices and patterns, look for code smells, and actually code right there in the interview. These interviews are conducted via Skype and screen sharing. Today, a candidate has to pass through two levels of technical interviews involving four different developers before moving on.
Around that time, we also stopped flying in candidates for interviews. Our developers work from home 100% of the time. It seemed silly and wasteful to require someone to fly across the country and take an entire day to prove to us in person that they would be successful working from home. I won’t deny that there’s value in talking to someone face-to-face, reading their body language, and giving them an opportunity to meet people in the office. But in the end, we decided we were getting what we needed through our other methods, so we nixed the in-office visit unless the candidate was Pittsburgh-local.
Using email to manage job candidates causes loss of appetite, dry tongue and general malaise. In March 2010, our CFO Tom Patton introduced us to a local Pittsburgh startup he’d helped advise called Jazz (formerly The Resumator). In short, it’s awesome and we’ve been using it ever since to manage the flow of incoming applicants, the pre-screening process, and much of the communications with candidates. It’s made our lives much easier.
We were frustrated trying to pick the best place to post among sites like Monster, Dice and CareerBuilder. We had devolved to round robin, paying gobs of money to one, then the other, then the next, trying to figure out which was yielding the best candidates. We lamented what it must be like to be on the other end, as a job-seeker having to make the rounds to all these sites, trying not to miss the right opportunity.
Careers 2.0 launched in in February 2011. We had tremendous respect for what Joel Spolsky and Jeff Atwood had already achieved with Stack Overflow. We knew that the best programmers (heck, all the programmers) go to Stack Overflow to ask and answer questions, and we wanted to get in front of them. So we decided to post our job openings to Careers before all other sites.
What we’ve found is that the quality of the applicants from Careers is consistently higher than those we get from other sources. I’m not saying we don’t get any good applicants from other sources or bad ones from Careers, we do. But by the numbers, Careers is ahead. We’ve also found the Careers people to be awesome to work with, and they’ve bent over backwards to help us get our job postings right (thanks Nick!).
Trello was released in September 2011, and we took to it like flies on rice (yes) for all manner of tasks. The Storyboard model is a natural for us, as we already use a Kanban board to manage our development flow as part of our agile methodology. Our candidate-tracking Trello board allows the entire company to visualize the pipeline. Each card is a candidate, the lists are the steps in the workflow. In a card, we embed the candidate’s resume, contact info, links to their web sites, blogs, LinkedIn, twitter feed, etc. Our developers can volunteer to interview a candidate with a click. Within a card, we can discuss what we’re learning along the way. It cuts down on communication overhead and allows us to focus on the candidate, not the process. We could have used Resumator for this, but Trello is free and visual.
Scheduling interviews is a huge time suck. In November 2011, I became aware of a scheduling service called tungle.me. It integrated with Google Apps calendar and would let people outside the company schedule a meeting whenever I had free time. I can’t emphasize how awesome it is to be able to send a candidate a link and have him or her choose a few time slots, which I can accept or decline. tungle.me was bought by RIM (you already know where this is going) and they recently announced they are sun-setting the service. So I signed up with a similar provider, ScheduleOnce. My developers started to use Doodle instead, because it allowed them to more easily coordinate three people for a tech interview.
Did I mention I’ve been doing a lot of recruiting lately? Since posting our most recent developer opening about eight weeks ago, I’ve personally phone screened 50 candidates. I’ve paid a recruiter hourly in the past to do phone screens and it went ok, I may do it again. During a phone screen, I focus on fit, passion, attitude, communication skills and resonance with our core values. Being a programmer myself, I probe at the candidate’s knowledge of various programming principles and patterns.
One thing I have neglected to focus on in my past phone screens is whether candidates can actually code.
2 + 2 = 5?
Jeff Atwood of Coding Horror and Stack Overflow fame has written a handful of great blog posts [1, 2, 3] on hiring programmers. Earlier this week, I reviewed these posts after conducting five exhausting back-to-back phone screens. In my weakened state, Jeff’s advice took on a particular resonance, and inspired me to go sign up for Codility. Two of my developers had recommended Codility recently. So starting yesterday, we’re using Codility to weed out those “programmers” who can’t actually program. This also allowed me to clear 7 hours of phone screen appointments off my calendar this week alone.
One of the common fears of putting something like Codility first in your process is that it might be off-putting or intimidating. I think Codility addresses that quite effectively in its FAQ (edited for brevity):
Q: I am hiring a senior software engineer, don’t you think that top-shelf candidates will get offended if I ask them to solve a simple programming test?
A: Codility tests are fundamental, not necessarily simple. People who get offended too easily are probably those who you don’t want to hire (emphasis mine). …[S]erious candidates like to be treated seriously … good engineers enjoy interesting problems and are excited to discuss them.
If a developer is going to be intimidated or is too proud to prove that he or she can, in fact, code, then I don’t think that person is going to be a very good fit for TrackAbout.
The final step before the offer stage is checking references, which I do myself for lack of anyone better to pawn it off on. We all know that candidates only provide references who will say glowing things about them, right? You’d be surprised. I’ve had references tell me not to hire someone. Lots of people who agree to be a reference may do so begrudgingly out of some sense of obligation, or perhaps are just uncomfortable saying “no”. When speaking to a reference, I listen for the things they aren’t saying about a candidate. I probe for specific examples where a candidate exceeded expectations, or didn’t, put in full effort, or didn’t. During the initial phone screen process with a candidate, I ask them to tell me what their references would say if I were to ask them. In this stage, I get to hear it from the horse’s mouth.
Even though we’ve come a long way, it’s still challenging to hire great developers fast enough. I’m sure we’re not yet done tweaking this process. After all, there’s always room for improvement.