So for what it’s worth, I thought I’d share some of my thoughts on technical recruitment. I’m going to focus on what works and more importantly, what doesn’t work from both sides i.e interviewer and interviewee.
In this post, I’m going to focus on the interviewer.
Before I start, the first question to answer is why? There are lots of books and articles that tell you about best practice, interview approaches, etc but on reading them, I always get the impression that the authors have never interviewed anyone, ever. So consider this the view from the trenches – my attempt to make sense of ten years of good, bad and indifferent interviews.
First point to remember is that interviewing for technical positions is hard. Anyone who tells you it’s not is either lying or doesn’t do interviews. It’s hard because you are dealing with people and people are complex, shy, nervous, silly, stupid, clever and often all of those things at the same time. Picking your way through that and working out if you want to let the person sat in front of you loose on your code base, your project and your team is tough.
Second point is to remember that people are not resources that you can stick into boxes. If you have a mental idea in your head of the ‘ideal’ candidate then unless you’re very lucky, you’ll spend most of your time being disappointed. Candidates are not job specs, they are people.
Lastly, remember that interviewing is not an exact science. You will make mistakes or forget to ask the things you really wanted to or very occasionally regret hiring someone – It happens. Remember what worked and what didn’t and keep reviewing.
OK so here’s my list of Do’s and Don’ts
1) Do interview the candidate not the job spec.
Have a minimum set of ‘Essential's’ in your spec that you won’t compromise on, after that look at the candidate and see what other skills they bring to the position – they might even bring skills you didn’t know you needed
2) Do test candidates
A test could be a couple of verbal questions, a written test, etc. It doesn’t really matter but you definitely need to get a feel of what the candidate knows and what they don’t know.
3) Do make candidates write code
You’ll learn more about someone by how they approached a problem, how they implemented it and more importantly how they explained what they did to you than anything else. Remember, this is what you’re hiring them to do, this is what they will spend the majority of their day doing
4) Don’t ask lots of ‘memory questions’
Asking someone to remember the exact format of stl::algorithm or all the methods in System.Xml.XmlDocument serves no purpose. People use docs and Intellisense – get over it.
5) Do ask open-ended questions
Ask a few questions that don’t have a ‘right’ or ‘wrong’ answer – this way you are giving the candidate a chance to offer their opinion and you’re having a conversation rather than a glorified ‘tick list’. Two way conversation helps because it allows the candidate to relax and as important, it allows you to relax. Having a discussion can tell you a lot about a candidate i.e do they listen to your opinion, how do they respond to counter-arguments
6) Do see if they’ve done their research
Always ask a candidate if they’ve heard of your product/team/game/company. If they can’t tell you just the tinniest bit about the company they are applying to then chances are you don’t want them at your company. It takes 30 seconds to type into Google after all so be brutal about this one. Trust me.
7) Don’t interview on your own
You may be super clever, you may know what you want, you may think you can read people but software development is primarily a collaborative effort so get in a couple of people and don’t just get in another manager or a senior coder – bring in your team and listen to their opinions. Importantly, catch up afterwards and discuss the candidate whilst it’s still fresh in your mind.
8) Don’t rush the interview
The time to allot for interviews depends a lot on the type of position you’re interviewing for i.e junior, experienced, senior however always give yourself an extra half hour on top of how long you think you need. This gives you room to breathe and if you’re done early then fine. Go to second interviews if needed. I frequently do two interviews – the first is technical and the second is more focused on personality and team.
You might not feel it’s appropriate or you don’t have time, however don’t discount it. If you feel that you didn’t get enough out of the candidate first time and there’s still potential then get them back in. If they want to work at your company/team then they’ll come back.
9) Do ask for evidence
If a candidate says ‘contributed significantly to the development of …..’ then ask them what they did, in detail, what they learned from the experience and what they would do again. If they can’t give you evidence and detail then chances are they didn’t ‘contribute significantly’. Beware candidates who use ‘we did’ all the time. Sure, development is done in teams but they must be able to say what they contributed as well as describing the team effort.
10) Do be prepared to be honest and forthright.
Most candidates slightly over-sell themselves. This is fine, their CV is what gets them the interview. However, if you think a candidate is not being entirely up front about their experience then say so. Make sure you explore strengths and weaknesses. Too many interviews end up being an elongated sales exchange. Yep it’s great that the candidate knows the ins and outs of UDP but does he/she know when they’ve made a bad decision and how do they deal with that? Ask them the last time they were wrong or the last bad decision they made. Be careful not to be too heavy handed or judgemental though -Making mistakes is perfectly natural and most of us do it all the time, it’s how we deal with it that’s important.
11) Don’t get taken in by confidence.
There’s a fine line between knowing your stuff and thinking you’re better than everyone else. In a knowledge based profession like programming this is always a temptation for us all. I agree with Jeff Atwood on this one. A good programmer knows that coding is hard and that they make mistakes and a lot of the time their code sucks. Bad programmers don’t – they think everyone else’s code sucks. Caveat Emptor.
Anyway that’s it for part one. All feedback gratefully received – good or bad.
Posts
