It takes me about three months to hire a new software developer, from the time we decide we’re looking to hire till I put out an offer to a candidate. I’ve been told that this process is too slow, or that my standards are too high, or even that I am too hard to please. I agree that it’s a slow process, but I have had some great results with it, and I hope that years of my wasted time coming up with this will help save some of yours.
IT people don’t work well with others”
This is a phrase I have heard uttered by business leaders at just about every organization I have been a part of. And there’s some damning evidence to support it. Technical work, especially in an organization where its primary product or service is not technology, sometimes breeds cowboys who don’t work well in teams.
In my younger (and more egotistical) days, I had the reputation of someone who didn’t work well with others, but I made up for that by delivering projects ahead of schedule and under cost. Of course, I did this by working twice as hard as I needed to, just so I could prove that I could do it alone. I also found the idea of taking partially baked ideas and building them into full fledged solutions exhilarating. It also didn’t hurt when people marveled at how I managed to get it all done… alone. I often found myself saying things like, “this isn’t like digging a ditch where two ditch diggers will work twice as fast as one,” to push back on business leaders asking to add more developers to a project.
Attitudes like these are not only accepted in software development, but sometimes expected. I have seen my fair share of companies that are held hostage by a “mad genius” that built everything, but now refuses to share knowledge. On several occasions, I have been hired to help the company mitigate their risks by having me find where the bodies are buried, so to speak. This gets them out of the ditch for a little while, but without a shift in attitude from the leadership, they end up in the same ditch again. I once lead an effort that ended with me being the next trigger man, and made it a professional goal never to create a situation like that again.
I have put together IT teams at several companies now, and hiring software developers that work well with others has always been harder than other IT professionals. It may just be that my approach with developers was lacking because being a programmer myself I had higher requirements from developers than from “hardware people”. Even if that were the case, though, anyone who has hired developers will tell you it’s easy to make mistakes. After over a decade of trial and error, I think I have found a strategy that works, and I will outline it for you here.
More Time on the Job Description
I start by writing a job description that describes the actual work, in English, so that anyone reading could understand it even if they aren’t technical. Rather than just listing the technologies we use, I talk about what we actually do with them. I tend to be verbose, so I will get others from my team to edit my work and make it more concise. Don’t use two words where one will do, don’t list things unless they are relevant, and so on. There’s a fine line between making it enticing enough for the applicant to actually read it, and not so long that they just skip to the end. I do the lambada on that line. Below is a breakdown of one of our job listings.
No Technical Interviews in Person
Hire technical people with asking them technical questions? Seriously?
Yup. Here’s the thing: an interview isn’t a normal situation. Will the candidate ever have to write code on a white board in front of an audience after they are hired? Will they have to take quizzes about archaic functionality of a programming language? If not, why ask them to do it during the interview?
More Testing, Less Talking
I test candidates on things that matter. An aptitude test that determines skills in math, verbal acuity and spatial reasoning. A personality test that rates twelve different areas of personality that would determine what working with this person would be like. And a project for the candidate to demonstrate their coding and problem solving abilities. I give them some code that compiles and runs, and includes unit tests that fail, because a method is incomplete. A document explains what they have to do to complete the project, and if they do it well, the included tests will pass. Someone that can code could complete it within 2-4 hours. The project is written in a way that even someone not as familiar with C# could work it out, if they know how some other object oriented language. It’s a problem that has several different solutions, and their code gives me an insight into how they think and how they work. Did they fully read the whole spec, or just enough to pass the included tests? Did they consider edge cases not covered in the spec? Was their approach similar to how the rest of our team works? Do they have strengths where we have weaknesses?
Data > Gut Feeling
Bringing a person on our team has a lot to do with gut feeling. But this is the same gut that told me eating yogurt two weeks past its expiration date was a good idea. Do I really want to make a decision that could cost our company tens of thousands of dollars based on that fickle jackass? But if I could get some data on aptitude and personality, now I can compare apples to apples. Competitive, excitable and impatient? No thanks, the position of annoying talking animal is already taken. By me.
Will They Like The Work We Do?
Next, I pick a task off our actual backlog that’s representative of the work we do and can be done in roughly 6-8 hours. I modify it so someone without knowledge of our codebase can still work on it, and have the candidate work on it as a paid assignment. Same as before, I give them a software solution that is mostly built, so they can focus on only the meat of the problem. This tells them what kind of work they’ll do when they join our team. If they don’t like it, we go our separate ways, but they’re still compensated for their time.
Will The Rest of The Team Like Them?
The last step is the actual interview.
Many candidates that make it this far come from other parts of the country, so I fly them in and have them spend some time in our office. If possible I have them attend one of our team meetings, so they can see our dynamic. I also take them out to lunch with other team members, so they can interact in a low pressure environment. The goal is to get them to see who we are, and for us to see who they are–not just who they are presenting themselves as at an interview.
And then I ask my team how they would feel about working with this person. They will spend a lot more time with this person than I will, it’s only fair that they get a say in the decision. And if their response isn’t an enthusiastic “yes”, I take it as a “no” and pass.
They May Be Right For Us, But Are We Right For Them?
Interviewers spend a whole lot of time trying to determine if a candidate is right for the position. They may stop to check if there are any questions, but more often than not they don’t go out of their way to make sure this place will be a right fit for them. The attitude is, well, I’m the one doing the hiring so you need to impress me! If someone starts working here and then realizes that this isn’t a good fit for them, at best we’ll have an unmotivated employee, and that’s not going to work out well for anyone involved.
It’s Worked Wonderfully For Me
So there’s my blueprint to hiring talented developers that like coming to work. It’s helped me hire people that not only know how to do what we want them to do, but actually want to do it. People that I interview, even the ones that don’t end up getting hired, routinely tell me how much they enjoyed the whole process. Many have told me they would use this process when they get in a position of hiring. It may not work everywhere, but the team we built with this approach has accomplished some amazing things at Energy Ogre.
Did I Mention The Process Is Slow?
I lose about a third of candidates on the aptitude/personality testing phase. Of the ones that remain, more than half drop out during the first coding project. Another fourth or so drop out during the paid project phase. But once someone has made it through those steps, I feel pretty confident that they are technically capable, and when we meet in person the only thing we need to focus on is how well they will fit in to our team.
I have gone through over 2,000 resumes and had hundreds of interviews, and ended up with a team of 10 developers, all of whom were hired through some variation of these methods. Just about all software used by our employees and members is built in-house by this team, and together the tools we created have had a market impact of over $100 million within the past three years, and helped many tens of thousands of people in the process. Every developer that came on full time has stayed with the company since. Not all of them had programming degrees or had worked as programmers before, but they all proved that they could learn, and are now able to perform. There is so much mutual respect between them that disagreeing and arguing competing points has never lead to issues. We’re more aware of each others’ personalities, about what kind of work each of us prefers to work on, and how we prefer to do it. This makes us work much better as a team, and as their manager I am far more aware of what is likely to motivate each of them to do their best work.
TL; DR; If you spend a lot more time up front before you hire a developer, you will save exponentially more time later, produce far superior results, and have more fun managing your team.