I’m currently building a team for my new secret project and far more of my time than I’d like is spent with the recruitment process. However, every minute of that time is essential and we’re at a point where none of it can be handed off to an agency even if I wanted to1. So getting the recruitment process right is essential.
One of the basic principles of management in any industry is that if you set metrics for your team, they will adapt to maximise those results: set a minimum number of bugs to be resolved and you’ll find the easy ones get picked off, set an average number of features and you’ll find everything held together with string, set too many metrics to cover all bases and you’ll end up with none of them hit and a demoralised (or non-existent) team2. The same is true of recruitment – you will end up hiring people who pass whatever recruitment tasks you set, not necessarily the type of person the company needs. While this may appear obvious, think back to the last interview you were at, either as the interviewer or interviewee – how much relation did the process really have to the role?
When I started recruiting for my new team, I knew I had neither the time nor resources to make mistakes. I had to get this right first time.
I’ve been in roles where I’ve been an interviewer more years than I’d care to admit, both for large companies where the process was fixed and for smaller companies where I could use my own discrection, and there isn’t one set way of interviewing – it depends on what you need. However, there are some key things to consider.
Firstly, what exactly are you looking for? I’ve seen so many roles advertised where the company wants experience in everything – this is liable to attract liars and put off individuals who are very skilled in a few areas. Key skills should fill the gap in the team and complement others. Everything else is just a nice to have.
Unless you are in a very limited subset of companies, nobody codes in isolation. IDEs, StackOverflow and related tools and sites mean that you do not have to have perfect recall for how to code any more. Giving someone a technical test asking about operator precedence or picking the correct class from a list are redundant these days. It is a far better skillset to understand how to solve a problem, where to get the right information quickly, and be aware of new advances in the industry. I’ve seen many an engineer who could code perfectly if told exactly what to solve in their primary language, but really struggled when given something creative to do. This might be what your team needs, but it’s never what I’m looking for. The technical tests I set are either problem solving discussions face to face or time limited challenges where you can use the resources you would have to hand if you were working for me. Both of these give me an opportunity to test you on far more levels than whether or not you’ve memorised a first year CS degree text3.
You also need to be technically better than me – I want to be excited by working with you and feel I will learn something. Without this then I may as well produce a detailed design of what I need coding and pass it to an offshoring company rather than employing you.
Team fit is one of those things that’s often given a bad rep, but it is essential if you look at it objectively rather than as an excuse to perpetuate poor culture within a company4. You spend 40 hours (or more) a week with your colleagues – if you (and they) are going to enjoy working then it needs to be a pleasant environment. The best teams are those where everyone trusts each other to do their jobs and provides constructive challenges and ideas – you don’t get this sort of team dynamic by hiring the first person that can solve a problem, you need to ensure that the candidate will enhance the team. I’m not talking about fitting into classical “Team Role” definitions5 that have their own problems, but rather will this individual feel like they’ve always been part of the team and confident that they can challenge and be challenged. This isn’t something that you can get easily from a single conversation, so multiple interviews are essential, ideally with some of the team involved. I’m very picky about who I speak to and even more discerning about whether I speak to the same person a second time. You won’t get a good understanding of a person with facile questions about strengths and weaknesses or their long term plans and there’s no set script for getting to know someone, you just need to be genuinely interested and most importantly listen and adjust the conversation.
So, if you’re coming to one of my interviews be prepared – you’ll need to be better than me and just as good as whoever I have from the team helping me. If you enjoy the whole process then that’s probably a good sign 😉
(Header image credit http://xkcd.com/1545/ )
- Which I don’t – agencies are great if you have routine requirements and are happy to pay 20% commission for someone to do the basic checks, but in a start up you just don’t have the spare cash and the sort of people I’m looking for aren’t on agency books. ↩
- We’ve probably all been in that sort of environment at some point in our careers and if you haven’t then you’re lucky. ↩
- It would be unfair of me to go into detail about the attributes I’m looking for here as that would give new candidates an unfair advantage and allow them to spoof that they have the qualities I’m looking for ↩
- Which a lot of companies do: like hiring like and ensuring that nothing ever improves whether that’s in terms of skills, challenging ideas or even unacceptable behaviour ↩
- e.g. Belbin or Myers-Briggs ↩