My recent experiences hiring software engineers

We’ve all heard it said over and over again that hiring is hard. But why is it hard? What about it is hard? You post an open position. You accept resumes. You pick the best one (after looking at the Githubs) and hire that person. That doesn’t sound like a hard process. But it's really like herding cats. Below are some of my experiences and the lessons I’ve learned along the way.

As a Director of Engineering at Recurly, and as the lead software engineer at Kenna, I've been a central figure in an organization's approach to hiring for over 5 years now. Hiring is hard for multiple reasons. The first of which is supply. I’m specifically talking engineering talent. Programmers and architects. Men and women that really understand how an application is built. The worker bees of the hive. But let’s move past supply, that isn’t going to change any time soon.

Attracting talent is the first step. I’ve experienced posting open positions myself. I’ve gone through recruiters. I’ve tapped networks. No single strategy resulted in a higher quality of candidates. Kenna didn’t have an internal person whose sole responsibility was managing hiring like it was a product. I wish it had. Recurly does and it is amazing! It's a luxury I greatly appreciate. Hiring is a product that needs to be managed. Your organization depends on it. The lesson here is that hiring takes a lot of time and requires dedicated effort and attention. It isn't just something you do in your spare minutes. Make sure a person is identified, who will have the time to adequately manage hiring. It will ultimately take more time than you expect it to. If you don't have a dedicated recruiter on staff, at least understand and recognize that someone needs to be made ultimately responsible for managing the process. Sharing the responsibility as a committee is like running a sports team without a coach. Disorganization can really bring people down.

At Kenna, we didn’t exactly weed people out, so my interview was more of a screen than an actual interview since I went first. This is a huge waste of time. Some candidates just won’t be good fits. You should be able to tell on paper. The person responsible for hiring should be able to devote enough time to screen candidates. This saves everyone’s time, including the candidates, but especially your worker bees that you are leaning on for continuing to build the hive rather than waste 30 minutes on the phone with a candidate whose skills aren't what you are looking for. The lesson here is have someone dedicated to leading the hiring process to lessen the impact on the rest of the team.

I have conducted A LOT of interviews. I have averaged 2 or more a week. I’ve searched to fill positions ranging from a VP of Engineering to Junior Engineer and everything in between. I was even involved in interviewing CEO candidates. I believe I have interviewed for almost every type of role a software organization needs. None are easy. None are protected from unqualified candidates applying anyway. It takes time to filter through the noise. It can be absolutely exhausting honestly. I fondly remember participated in a round of interviewing ops candidates. All were great candidates. It was a very exciting experience. But sadly, that was the exception, not the rule. The lesson here is patience. No matter what the role, it's going to take some time to filter candidates so plan accordingly.

I didn’t have an interview strategy when I first started. I had interviewed people in the past, but it was infrequent and didn’t require having a control to establish clear differences in candidates. I quickly learned I needed one. I’ve established a set of questions now that I set as the “agenda” in the calendar invite for every interview. It’s important to know what you are going to discuss before you start. Don’t just wing it. And this might sound like a given, but take notes. Remembering what you thought of someone even a day after the interview is difficult when you get around to doing a debrief with your team. The lesson here is give some thought to what you want to learn about the candidate and be prepared with a plan beforehand. I've unfortunately not been disciplined and prepared at times and really regretted it. It ended up being a waste of my time and the organization's.

Ask questions that are meaningful, remember you are going to be working with this person for hopefully the long term. I don’t ask brain teasers or real complex questions. I also don’t try to gage a candidates knowledge of standard language syntax. Google and dictionaries and man exist for a reason. If the candidate needs to look up what Array#initialize_copy does in Ruby because he or she can’t remember off the top of their head, so be it. If the candidate is available to spend time pairing or just shadowing an engineer, take advantage of that. Passion and knowledge get exposed a lot of the time in those situations. I don’t always have the luxury of pairing or actual coding time, so my questions are higher level. I want to gage experience and general application building knowledge. I want to know if the candidate can see the forest through the trees. Can they grok the bigger picture? I don’t care that they really really know Ruby. It’s great that they have every Array method memorized, but we’re not building an application that just uses Arrays in a certain language. Most applications utilize more than just one language. And ask questions that allow candidate's to explain their experiences. You never know, they may be more experienced than you are. Gasp! The lesson here is ask meaningful questions about comprehension rather than questioning whether a candidate can regurgitate something that can be looked up in two seconds.

I strongly believe that the interview process is just as much for the candidate as it is the organization. It wastes everyone's time and money should a candidate accept an offer and decide they are unhappy or not a good fit and leave after two weeks or two months. It's important to provide candidates with adequate time to ask questions and gage whether the organization is a good fit for what they are looking for. The lesson here is allow candidates to ask as many questions as they want so you can prevent them finding out it's not a match after you've hired them.

Take home exercises can give a good sense of ability, but not always. It’s easy to be academic when asked to build something small and focused. They don't tell you how the person thinks about the big picture, nor how they work with other engineers' code. If a candidate's Github is virtually empty, then I can understand wanting to see a code sample, but keep in mind it's not really going to display how the candidate's work is going to fit in with others' work. It's been my experience that take homes just aren't the best reflection of candidates. Instead I recommend doing a code challenge in person. You'll see first hand how the candidate works. You'll notice if the candidate immediately reaches for tests, or just impulsively tries to solve the problem. You'll have a chance to see if they use established patterns, etc... The lesson here is that take homes are like open book tests in high school, they give you a sense of a candidate's ability to look things up, rather than their level of comprehension.

Some organizations may just need more people fluent in a particular language or technology. Maybe they have a big backlog that needs to be processed. If that is the case, and you're mostly interviewing for performance in a certain area, defining a set of consistent questions is key. Have a set that allows you to really compare one candidate against another. Be precise. Be prepared. Have a plan. The lesson here has already been stated and is being repeated, have a plan.

One of the most important things I’ve learned is that timing is very important. These days candidates will probably have multiple offers. If you drag your feet, you lose out. Or maybe think of it like poker. Don’t sandbag on betting if you have a good hand. If you do, you leave the door open for others to have a chance on the turn or river card. Hiring and candidates time can easily take a back seat to the priorities of the day. Don't let it. Set a schedule for each candidate and stick to it. Don't leave candidates sit for a week with no correspondence. Or at the very least, set the expectations with the candidate on when they will next hear from you or a next step will be scheduled. The lesson here is be reasonable about timing and set proper expectations with candidates.

Establish collecting timely feedback a priority. Collect team input and make a decision on next steps as quickly after interviewing as possible. This allows you to act if you think the candidate is a good fit and eliminate others. If at all possible, debrief in the next 24 hours after speaking with a candidate. And if a candidate is not being considered, let them know so they can continue on with their search. The lesson here is don't be lazy, collect feedback and act on it quickly.

It takes time to find good candidates. Be prepared for it to take a couple of months when everything is said and done. Recruiters take time to really understand what you are looking for. Candidates take their time and explore many options. Start looking a couple of months before you really need someone. And don’t make impulsive hires just because hiring is hard right now. Hiring the wrong person just means you have two problems. Getting rid of the wrong and starting your search over again. You have to move fast once you have found the right person, but make sure they are the right person first. The lesson here is don't be impulsive. Move quickly with purpose and be mindful. Adding someone to a team is serious.

If you've read this far, I owe you the biggest lesson. It's one my father taught me. He was in a situation where he was losing engineers to a large car maker in Detroit. They were targeting his team and offering them 10% more than they were currently making. 10% is a significant increase. So my father went to management and asked to match the offer and keep the engineers and all their institutional knowledge. Management said no, they didn't have a budget for it. To make a long story short, one or more engineers left. The 10% management folded on was spent advertising and recruiting for replacements. But replacements don't have the institutional knowledge. So the first year or so they were on the job learning, was wasted money. In the end, the 10% should have been a no brainer. The lesson here is once you have good engineers learn how to retain them so you don't have to spend more money hiring replacements that you then have to train.

Bottomline, hiring can be frustrating. It can be time consuming. Be prepared. Have a plan for evaluating candidates. Have someone managing hiring. And hiring doesn’t stop once an offer has been signed. After that you get to do the second part of hiring–on boarding.

Once you hire someone the real work begins. My father has told me multiple times, developing talent is harder than finding talent. I'll discuss developing talent in a future post.