On Recruitment

I recently observed the elaborate processes that some friends went through as they attempted to join a new company. In the last year I have also participated in some of these processes as well and I have wondered — why do they feel less like an interview and more like a trial or initiation ceremony? Importantly, what are the benefits and side-effects? I'm especially curious about the cultural benefits and I also believe there are some undesirable side-effects.

The cost of hiring is expensive. It involves many hours — to meet, to conduct modelling sessions, to pair, to review coding exercises, and ultimately to select the right candidate. Designing a process to increase retention rates is sensible. But how expansive and intensive should these processes be? If your company does have a long and drawn out process, is it ultimately worth it?

Your processes serve to document and maintain a culture. Formed over time, and often with the best intentions. The goals might be to ensure that the most capable people, with the highest potential are selected. I think there are misconceptions about the culture being formed. I think that recruitment in this way becomes ceremonial, builds a tribal culture among developers and enforces a ritualistic right of passage. This ultimately promotes exclusivity and stifles diversity. Your team is not building the skills and techniques to include people different to them or mentor candidates like them, but less skilled.

Additionally an elaborate recruitment processes serves to reinforce the exclusivity of the members already within the team. Candidates who successfully negotiate a ritualistic recruitment process will stand proudly with their new tribe. It would take a courageous new member to then suggest that the ritual they have been through be softened, made easier or more inclusive.

A difficult and constrained recruitment process may not necessarily speak to the capability or possibility of a candidate and the potential they may bring to the team. It reinforces an expected standard, an operational boundary for all employees, new and old.

I was employed early at Cogent. I met with both the directors, which at the time formed two-thirds of the company. There was no code review or technical interview, I was a junior developer and I had to do more to explain the potential of my capabilities. I worked hard and grew to become a capable developer. Years later, I would say on many occasions that I would not expect to have been hired given the elaborate technical and cultural recruitment process that later became established there. Over time though, Cogent really struggled with diversity. As a group of decent people there was a strong desire to build a team made up of men and women from various cultures, unfortunately though we were best at hiring folks more or less just like us.

I have also been employed by a company with a fairly weak hiring process. This company doesn't have a strong software development practice, nor does it have a high level of technical discipline, or strong delivery capability. What it did have though surprised me: diversity. Unfortunately, it lacked a culture that encouraged mentoring and teaching. As a result, a poor standard of software development practice has persisted and staff retention is low.

The people best suited to recruit software developers will always be other software developers. Importantly they should be people who have worked with lots of people and have great people skills. This is the hard bit. It takes empathy and humility to listen and appreciate what candidates say about their experiences.

Recruiting for skill alone is not enough, you have to recruit for potential: how will a candidate grow, what are their interests, will their journey compliment the needs and growth of the company? The best people to determine this are men and women who's careers have been a journey with highs and lows. These are the kinds of recruiters who have a sense of how careers are built over time, through opportunity and perseverance.

Coding exercises are worth while too, even well known ones. There is a lot to learn from seeing how an individual approaches a well defined problem. Not to mention the things you can learn about that person if they didn't actually do the coding exercise! Experienced recruiters can gauge the depth and potential of a hire by the kinds of design choices and techniques they use to solve particular problems. Even with well known and well documented coding exercises, they form the starting point for a conversation about techniques and practice.

As for cultural fit — I think this is the most belaboured and overblown aspect of recruitment.

Coffee, conversations, informal chats and team lunches are extended screening sessions. Not being upfront about the purpose of those meetings with your candidate is deceptive. If you have a role and want to determine fit, say so. If you don't have a role right now, but want to encourage that person to keep in touch, say so. Give your candidate the opportunities to show their best selves. Ploughing them with lattes, or worse, beer to find out if they're compatible with your team is just another ritual. This doesn't contribute to diversity either, you're building a monoculture.

You're hiring someone to do a job. Software development is a job. Your business is not a cult. Your organisation should have well defined goals, your team should have goals and you should have a goal for your candidate. If, during an interview, you did not state those goals and ensured that the candidate understood them and is willing to fulfil them, you have failed to conduct an effective interview.