How to Hire Developers I
Excellent software teams are naturally motivated to protect the quality and value of team membership. All you need to do is leave them to it.
This is the first part of a small three-part series of articles outlining a process for hiring developers. Part one begins with the governing philosophy behind the process, part two goes into some tips and guidelines for the interviewers, and part three looks into the ideas behind the technical tests that are given when hiring.
This is basically a brain dump of many experiences I’ve had over the years, things I liked, things I didn’t like, why some things worked, and what to watch for that doesn’t work. There’s no perfect approach to hiring, but in a world that mostly gets it wrong, doing it even a little better makes you stand out. Enjoy!
Everyone on the team interviews
If you only take one thing away from this series, let it be this: everyone in the team takes part in the interview process. It is the key to successful hiring and all the techniques and tips that follow stem from this one idea. Even in the progressive climate of software development today, it’s a fairly uncommon approach because it involves distributing the responsibility away from ‘management’ and into the team itself. The major barrier, as always, is trust. Taking the ‘leap of faith’ early on, during the team’s initial creation makes this trust-barrier smaller because it’s much easier to trust that a small B-Team with the right attitude can grow into an A-Team than it is to trust a large B-Team with issues to do the same.
Interviewing is a duty, not a privilege
Each member of a motivated and effective team should be involved in the recruitment process, even working students. Conducting interviews is not some privilege reserved for managers, it is an important part of everyone’s career development. It’s a duty, like voting, that each member of a functioning team should not shirk.
This does not mean that every team member has to be involved with every candidate. Quite the opposite. Once a team member has been accepted into the tribe, they must be given the right to speak for the tribe. Acceptance into the tribe is not, however, handed out willy-nilly, making it that much more valuable, protected and therefore desirable. Acceptance doesn’t come until the newcomer really understands the team, and once they are accepted, it gives them a strong sense of belonging, a sense of responsibility and an incredible feeling of self-worth if they are then given the privilege of making decisions for the team.
Interviewing requires communication skills
Interviewing is still a skill and people are quick to remind you that “developers are notorious for their poor social skills”.
Rubbish.
Modern developers can’t afford this old fashioned stigma. Socially inept people don’t belong in teams because teams are, by definition, social. That’s not to say you can’t be quirky, carry a 12 sided dice, have a weird comb-over or be a gym junkie. Feel free to be as abnormal as possible, but not at the cost of your ability to communicate.
Just to give some examples of other communication skills that are a part of every great developer’s toolkit: reviewing pull requests, giving and taking criticism, pair programming, interpersonal conflict resolution, feeding back info on bug reports, clarifying requirements, mentoring, brainstorming, estimation... and now, interviewing.
You can learn to interview
Like any new skill, you will need some training and mentoring, this will be available and provided both when you start at the company, and whenever you request it by your mentor and tribe members (see part two).
Does it scale?
Yes. But scaling… such a trendy word in hiring these days… as if your company is so popular and you have a million applications flooding in and a million positions available because you’re growing so quickly. Calm down. If you have a million applications, this is a luxury problem, lower the advertised salary (or raise it), filter by resume, hire a recruiter, delegate to HR or just pick them at random and cry me a river. If you have a million positions open, you’re growing too quickly. Slow down and go for quality, not quantity.
Keywords aside, the following process will help in more valuable ways than scaling, the ability to ‘scale’ is just a nice byproduct.
A typical application cycle looks like:
Each new job application will land on the team lead’s desk, and he will assign the application to a member of the team on a round robin roster. When it’s your turn, you are responsible for that applicant’s journey through recruitment — this of your role like a ‘minder’ or ‘buddy’: arranging meetings with different members of the relevant teams, giving them assignments/tests/homework, answering their emails, debriefing the team after the decision is made… everything.
There are, of course, guidelines and limits to what you can do, but the leash is long and you will ultimately decide if the applicant is hired or not. That’s right, you have the power. Use it wisely and ask your team leader for guidance when you are unsure.
The benefits of everyone interviewing
This strategy serves a few purposes:
- it distributes the workload of recruitment away from the team lead, whose job is to coordinate, not actually perform, all the work.
- it scales (smirk)
- it puts the decision making in the place where it truly belongs: with the team itself. This, in turn, ensures the FNG has a smooth transition into the team because he has already been accepted by the team or one of its empowered representatives.
- it demonstrates that the people upstairs (management) trust them to make such decisions. This kind of trust is a powerful motivator.
- it provides the team members with a sense of belonging and identity, they each have a voice in their tribe and are equally responsible for membership and therefore the very definition of their tribe. Another powerful motivator.
- it encourages creativity in the hiring process, team members will strive to do something new, different, progressive. They will compare processes and talk about the pros and cons of different techniques. They will optimise because, after all, it’s what dev’s do best.
- it keeps the recruitment process unpredictable, so applicants can’t be primed by Glassdoor or sneaky recruiters.
But that’s not a fair test
The last point above is one of famous contention, especially amongst engineers and scientists because: how can you compare one applicant with the next? It’s not a fair test! No, it’s not. But it never is. There are many factors that will contribute to a persons success or failure: weather, the mood of interviewer and interviewee, time of application/interview, lost emails, a friend in the company. No two interviews are ever the same. Yay or nay almost always comes down to a ‘feeling’.
It’s a ‘pass or fail’ process. It’s not like you are given a score at the end, that’s just not how it works. We just want to see if it’s a good idea to hire someone or not. And that is a decision that each member of a cohesive team should, at the very least, be able to facilitate, if not, decide by themselves. And if the consistency of the interview process suffers as a result of this, so be it.
Summary
Empowering the team to choose their own members is something that seems so obvious, but in reality, managers are very hesitant to hand this responsibility over to the team. In some cases: they are simply protecting their jobs, in other cases, they are perhaps justified in their angst: legal repercussions for mishandling the recruitment process; the team‘s motivation levels are rock bottom or; there is no team. However, the idea behind each team member taking part should always be in the back of your mind. Strive for it, take the first step yourself and hold their hands until they understand.
I mentioned above that developers can and will get training or mentorship should they require or ask for it. This will be the next article so stay tuned!
