Programmer Interviews Do’s And Don’ts – Part One

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.

A New Home

I've migrated my blog from zebrabox.spaces.live.com to here

Back To Basics

I spend a lot of time interviewing programmers. This has caused me to reflect on the changing nature of the programmers’ basic skill set.

Once upon a time, it was easy, I interviewed games coders; if they knew C/C++, basic 3D maths, were keen and not too socially objectionable then they got the job.

These days it’s much more complicated. I’ve seen CVs from people with 6+ years development experience and yet when I ask them a basic programming question they seem to get stumped.

It’s a puzzle to me. It seems that nowadays a lot of people learn some basic use of a language (c++/c#/java), some APIs then get comfortable and stop there. This is a major problem in my industry, and I would propose in any industry.

Recruitment takes a lot of time and effort so I’ve started to look at ways of quickly filtering out candidates who can’t do the basics. One of these is the ‘fizzbang’ question.

A ‘fizzbang’ question is a very simple problem solving question that requires you to write some basic code; no reliance on APIs, no language subtleties, just Plain Old Coding.

I got the idea from looking at Facebook’s job puzzles. In particular Hoppity Hop.

So, I knocked up a few of my own – here’s a simple one ( not one I use I might add!)

For all numbers between 1 and 101 (inclusive ) at each integer in that range, output the following to standard output:

• If the number is even then print ‘even’
• If the number is odd then print ‘odd’

Simple right?

I like it because it tests some basic skills that all coders need to have

1. Can you read and analyse a requirement
2. Can you solve a basic problem
3. Can you write some code without resort to refactoring tools, help docs, google or intellisense

You’d be amazed how many people can’t do any or all of the above :(

If any of you want to try the question then feel free and if you have any other suggestions for good fizzbangs then mail me

Behind The Times

OK, so here goes.

I finally decided to start writing a blog. Perhaps a foolish, ill-fated and short-lived attempt, we’ll see…

I’ve always been a little slow on the up-take with technology trends which is quite ironic for someone who works in software development. I don’t have an iPhone, a Facebook account, an XBox or an iPod but hey there you go. I probably spend too much time in old-fashioned pursuits like drinking and swearing.

Anyway, let’s hope there’s something of value in here for someone out there and not all of it boring geek-talk about python and why coders nowadays have never had it so good and frequent posts along the lines of -

‘In my day we used to code with coal and had to stick the bits into the registers one by one then hope the chip didn’t blow up and we’d end up with transistors stuck in our face not like the web-pampered youth of today’

Etc, etc

Right enough blogmanure for now. More later