Our CEO recently wrote a blog post entitled Hire Above Yourself where he charges us with the goal of building a team of people who can bring something to the table that we can't. As I reflected on his comments, I decided I would write down the questions I ask myself following the interview process when deciding whether or not to hire an individual. These criteria aren't a complete list, but for me they are a basic checklist against which I evaluate each candidate in order to ensure that I'm building the best possible team.
- What can this candidate teach me? I love being in the role of a teacher; educating a new associate about how our applications work and how our code is structured, but I also love receiving educated outside perspectives from folks new to our code base. I want to hire someone who can bring not only a fresh set of eyes, but also a different set of background knowledge to positively influence our technical direction. Sometimes what they bring to the table can be a set of technologies or an engineering practice that I'm unfamiliar with, though often it amounts to an overall set of experiences outside my own that lend the candidate the ability to attack problems from another angle and force me to question my assumptions.
- Can I feel accountable for this candidate? When asked to give a personal recommendation for someone seeking a job, you draw on all your previous experiences with them in order to decide whether or not to give that recommendation. Why shouldn't your decision to hire an individual feel just as heavy? Your experience with them, though limited, should make you feel confident that having your name associated with them won't be a bad thing. It's always tough to be sure that you've adequately evaluated a candidate's technical skill level in the limited time of interviews, but you should have a good level of confidence that they know their stuff.
- Where are they now, and where do I see them in five years? This question is always one of the most important for me. Too often I feel the focus in interviews is on what the candidate knows right now. With an engineer that's eager and willing to learn, I can teach them any necessary technologies; what I focus on is how far can they progress with that knowledge, and how can they improve our product and company. I'll always prefer the candidate that's eager to learn over the one that believes they have all the answers.
- Can I rely on this candidate to deliver what they say they will deliver? I need a team I can rely on to understand the task assigned, to provide good estimates for the time required to complete the task, and to complete the task as close to that estimate as possible, while still maintaining a high level of quality. With candidates, I ask about their previous large projects and their strategies for ensuring they deliver on time. Their responses are of course one sided and focused on what they were able to deliver, but I also want to know what they had to scale back, or what they found they under-estimated and had to think creatively to solve in time.
- How will the candidate fit in with my existing team? Though you might not know it, engineers can be a fickle bunch, and as so often happens when smart people interact (Newton and Leibniz are a great example), disagreements occur. I love the dynamic on my teams, and I don't want to spoil it, so any new additions should mesh well with our dynamic of learning, sharing and making mistakes