effective recruiting
summary
Recruiting is hard because it’s difficult to break through safe and canned answers to determine if a candidate will really contribute or possibly detract from the existing team and culture. I have found that a series of interviews with the entire team and a small coding project usually provide the means to properly evaluate candidates, but only after determining exactly what is needed from the new position—like junior vs senior, generalist vs specialist, and figuring out what personality attributes are important to the team. This enables figuring out appropriate probing questions.
issue
Recruiting is hard. It’s hard to determine how a candidate is really going to mesh with your existing team with just a few hours of interviews. The best you can do is develop a set of questions and exercises that you believe will prevent the candidate from totally responding with safe, “canned” answers that don’t tell you a thing. With this in mind, if possible I involve the entire development team in the interview process. By having multiple interview teams of 3-4 people and giving them topics or areas to cover, we feel we have a better chance of figuring out the true culture and technical “fit” of potential candidates.
“I am convinced that nothing we do is more important than hiring and developing people. At the end of the day you bet on people, not on strategies.”
what do you really need?
Most times the skillset of the new position is obvious or known. But, the amount of experience (e.g. junior vs senior)or the need for something like leadership qualities might be unknown or debatable. Hiring a generalist vs a specialist might also be discussed. Imho, besides DBA, DevOps, and front-end skills, I always prefer to hire generalists, especially for smaller teams where you need their versatility and flexibility across various projects.
To get a better idea of how a developer might perform or act on a team, over the years I’ve developed a somewhat visual way to view developer profiles. I call the three profiles: Trailblazers, Path Builders, and Road Pavers. They’re all necessary and important, in fact, I believe you get the best team and outcomes when you have a mix and not just one type. Please see below to see some of the “traits” of these profiles.
“Hire character. Train skill.”
I find most developers pick Path Builders when asked to self-profile themselves, although, if a developer views themselves as an engineer and/or a craftsman, they might tell you they’re Road Pavers. Why does this matter? If you’re going to launching new products you probably need to have at least one Trailblazer. If you’re mostly in maintenance mode, then having a Trailblazer is a waste of their talents and energy. Oh, and btw, a Trailblazer makes a horrible Road Paver and vice versa! While I haven’t ever started a search with one of these profiles in mind, they have definitely influenced who we’ve eventually hired when considering upcoming products and projects.
what experience level?
Teams need a strong nucleus of experienced, proven software developers. If that’s missing, then teams need to hire Sr Software Developers. However, if a team already has that nucleus, then it might make sense to bring in junior (entry) or mid-level software developers that the seniors can mentor and teach. This creates a great dynamic on the team! For specialists, I almost always look for seniors just because they’re likely to be on their own and need that experience to immediately contribute.
what individual attributes help a team?
Similar to leaders (see the Learning on Identifying Leaders), there are definitely certain attributes that I believe better ensure a new hire will be a great teammate.
“If you think it’s expensive to hire a professional, wait until you hire an amateur.”
Passionate - infusing energy, contributing, and willing to fight for something believed in.
Open-minded - able to look at the best lessons of the past while being open to the new ideas of their teammates.
Humility - basically the opposite of arrogance—a willingness to take a modest view of their own importance and to accept help from others.
Honesty / Integrity - giving proper credit for work done by others, acknowledging their own mistakes, and making amends if necessary.
Accountable - delivering on promises and being forthcoming with status along the way.
Problem Solver - able to assess challenges, find possible solutions and consequences, then make a recommendation on the best solution.
Perspective - see the big picture instead of becoming lost in the details—always able see the end goal in sight.
Candidates that show these attributes through through the interview process will undoubtedly be great additions to the team!
interviewing process
With all that in mind, here’s a suggested interview process that I’ve seen work quite well. The leadership team (e.g. myself, architect, dev manager, dev lead) reviews incoming resumes and selects the top ones to be phone screened. The leadership team also conducts the phone screens, keeping them to 1 hour maximum, shorter if it’s clearly not a fit. At the end of the phone screen, the leadership team votes on whether to go to the next step—I want this vote to be unanimous, but we’ll continue as long as there’s a majority. The coding exercise is meant to be straightforward, but to give a good idea of how a person reads requirements, codes, and presents what they’ve done. Finally the on-site interview gives everyone a chance to make sure they really want this person working on their team!
The entire team votes on hires and I believe the vote needs to be unanimous. When it wasn’t, we either invited the person to come back to address concerns or we moved on.
Measuring success
The ultimate measure of success is retention—however, retention of talented team members that are a pleasure to manage and be around! Another good sign of success is looking at how long it takes for a new hire to come up to speed. Great hires seem to do it much faster than those who aren’t—probably because they have no problem asking questions and accepting help!