New Hires Who Hit the Ground Running
By Scott Barnwell
How would you feel if your new hire arrived on Day One ready to work and you had complete confidence in their ability to deliver? That was our goal when the City of Asheville’s Business and Public Technology Team tried a hiring experiment based on our increased use of GitHub in our daily work.
Rather than relying exclusively on the traditional resume-application-reference checks-interview approach, we opted for a more collaborative approach that allowed our top candidates to see how our team works and to allow us to see how they work. Knowing that much of our work involves team-based projects, we wanted to see just how well we might work together. We also threw out the veil of secrecy surrounding the hiring process, allowing – even encouraging – competing candidates to interact. The goal was to make our hiring process a lot more like the way we actually work as a team.
In our first collaborative hiring experiment in 2014, we presented our top candidates with a real issue facing the City of Asheville at the time – the need to track graffiti throughout the city and to communicate cleanup efforts to the public. Using GitHub, our team defined the parameters for developing a Graffiti Dashboard. While not required, we encouraged candidates to use GitHub Issues to ask questions and to use GitHub pages to submit their final product to our team.
The goals of this collaborative hiring experiment included: 1) Validating the technical skills of each candidate; 2) assessing their analysis and communication skills; 3) tackling a real problem that we needed to work on anyhow; and 4) doing it all in a “real” work environment… one that encourages collaboration, creativity, borrowing code from others, etc. In the end, we wanted to hire the best talent possible as well as someone that would work well with our team.
At the outset, we had no idea if our approach would work or if any of the candidates would be willing to participate. After all, we were asking them to invest significant time into the process. In that first experiment we had five applicants, four of whom took us up on the graffiti dashboard skills assessment challenge. In the end, we had one clear standout who ultimately joined our team. Perhaps the best part of all was that he hit the ground running, developing the production version of the Graffiti Dashboard during his first two weeks on the job! The candidate, Cameron Carlyle, put it this way, “Since the skills assessment was rooted in the an actual problem facing the City, it gave me a realistic glimpse of the type of work I would be doing on the job. I literally hit the ground running, and was meeting with folks involved in the Graffiti Project by 10 a.m. on my first day on the job.”
The skills assessment has been very useful for a variety of reasons. Although we cannot know for certain, we suspect that some candidates decline to participate because they lack the required technical skills. This helps us avoid bad hires. The assessment also helps us differentiate candidates who bring primarily a technical approach from those who can identify and understand the issues underlying a larger problem. Further, the exercise becomes fodder for richer discussions during the interview, which typically revolve around the candidate’s analysis of the problem and their chosen solution, We are able to explore alternative approaches and how they would continue the project if given more time.
We had grown increasingly confident, having made a couple of additional hires using this approach, when we ran into a snag. As part of another hiring decision, we presented our candidates with a skills assessment, also via GitHub, that relied on a static sample data set. Unlike the graffiti dashboard, this assessment was not based on a real problem that we needed to solve. In retrospect, this process was poorly defined, confusing, and bound to fail. Not only were the candidates struggling with the contrived exercise, but our team was not able to interact with the candidates in a meaningful way as we could with a real problem.
In the end, we had to abandon that particular hiring process altogether and start over. With a newly defined skills assessment – an analysis and presentation of the city’s purchasing patterns with live data available from our open data portal – we again identified an excellent candidate who went on to join our team. This experience taught us the importance of making the skills assessment mirror the way that we work in the real world and not to merely fabricate an exercise.
Most recently, we hired the founder of this blog, Eric Jackson, to be our Digital Services Architect. During the hiring process, we tasked him with building a dashboard to analyze and display Asheville’s building permit data. Having learned that real work leads to good work, this permitting dashboard had previously been requested by city staff and by members of the public. Two candidates accepted the challenge. As a hiring team, we enjoyed interacting with both candidates through GitHub Issues. From the candidate’s perspective, Eric recalls “I thought it was actually a lot of fun. Other than when the API went down over the weekend and all the IT folks were in the mountains and off the grid – I’m still not sure if that was a fluke or part of the test :). What’s great about this hiring process is that it allows you to test what you really care about – how people think about problems, how they collaborate, how willing they are to ask questions, how well they listen – and to do that over more than the hour or two an interview allows.”
Three years in, the collaborative hiring experiment continues to reap dividends. In every case, our new hires came in eager to work and we had total confidence that they would hit the ground running. The resume, cover letter, and professional references all have value. But we have found that the open and collaborative skills assessment process is the most efficient way to attract top talent and avoid bad hires… like usability testing for human resources.
Originally published December 9, 2016.