For a while now I’ve been leading software teams, and part of that is recruiting developers when there are vacancies within the team. Talking to other developers, especially juniors, it seems like there’s still a fair amount of mystery about what is generally expected in the hiring process, so I thought I’d write about some of the things I look for when “on the other side”. I’ll split this into a few parts, for the different phases that may be in a typical recruitment process. Needless to say, this is all just my opinion from my experiences; by no means a definitive guide.
When I get developer CVs, it’s still true to say that a lot of them look the same, and not particularly inspiring. There’s normally some kind of employment timeline, which are often little more than a list of where the person has been working, where somewhat unsurprisingly their job title was some variation on “Developer”. This is sometimes minimally augmented by a brief job description, which normally involves writing code, and a list of technologies. I guess it’s true that developers as a stereotype aren’t always the most vibrant or creative, but the good news in this is it’s quite easy to stand out from the crowd.
The number one trait I look for when hiring is character. There are a lot of people out there who are technically competent enough, but if I’m going to spend 8+ hours a day working with someone, I’m going to cherry pick people who have the right attitude and approach. An interesting thing here is that it’s really subjective, but very powerful. A lot of people approach recruitment as a one-way thing, where all the power is in the hands of the recruiter, and try too hard to please, trying to come across as something they think the recruiter wants rather than being themselves. For me, this is a big red flag; I’d rather people be themselves, which sometimes isn’t a good fit, and that’s fine, I hire someone else who is a better fit for me and my team, and the candidate gets another chance to find a team where they will fit in more naturally and be happier for it.
It’s really important for both sides to treat recruitment as a two-way deal. It’s possible to score points off the other party, but that’s normally a negative sum game. Nobody likes to feel like they’ve been tricked, and if a working relationship starts like that the odds are it won’t last long or be as profitable for both parties as it could be. I’ve seen all sorts of weird and dishonest behavior when applying as a candidate myself, and it’s definitely true to say that not all companies, managers, recruitment agents or candidates will play fairly. It’s obviously a business world, and everyone’s trying to make a profit, but I don’t want to work with people who can’t be trusted. As a candidate, be wary of anything suspicious like this, and make sure you are never tempted to behave in the same way. It’s a small world, and reputations do go around!
The skills I value most highly when recruiting are normally the higher-level skills rather than specific technical knowledge. I’m looking for people who are enthusiastic, who are willing and able to learn. In any project it’s impossible to know absolutely everything, and I want people who’ll not be daunted by this. It’s a fast-moving industry, and technologies come and go, so the ability to learn independently and a desire to do so are worth a lot. The other skill that arguably ranks even higher is the ability to communicate effectively, which is surprisingly rare. I’d go so far as to say that effective software development is more about communication than anything else, whether that’s communicating with stakeholders, with the business to understand requirements, or communicating intent with peers in code. It’s really easy to grind out code that doesn’t do what the stakeholder actually wanted, or that no-one else can read, and that’s no good. An effective recruitment process includes examples of written (CV, technical test) and spoken communication (phone and/or face-to-face interviews).
When recruiting, I think it’s important to feel positive about someone to hire them. If someone’s “OK” or “not bad”, that’s not really compelling enough for me. Employment law makes it relatively difficult to change people once they are under contract, so bad hires are hard mistakes to fix. Even for contractors, there’s a notice period and red tape involved, and the damage that can be done to a team through having the wrong person can be very costly. I’d rather have a small number of good people than many more average ones, as the difference in output from the best people is disproportionately more, and small teams can run more efficiently with less overhead.
I’ll go into more detail in the next few parts about some of the specific phases of a typical recruitment process.
Trackbacks/Pingbacks