Tales of the Interview

Recruiting is not only for colleagues: we recruit everybody. It is the world's biggest problem: getting the right people into the right jobs, eliminating the waste and drag of unproductivity engendered by poorly matched people and positions. We recruit babysitters, bankers, plumbers, spouses, presidents, even if the recruitment process is completely different in each case. The only people we can't recruit are our blood relations.

This post was triggered by two recruitment-horror-story posts from the world's best blog: A Problem at the Personal Level, and The Receptionist Test. They're worth a read.

It scares me how some software organisations hire coders on the basis of nothing more than their CV, a handshake, and a smile. If you do nothing else in a programming interview, please do this: sit in front of a computer with your candidate, and ask her, or him, to write some code. This alone is the best filtering tool you have, it's so powerful you won't want to look at CVs ever again.

Tips for programming interviews:

• Take time at the beginning of the interview to help your candidate relax so they can put on their best performance. If you've done this, and they're still nervous and stressed, you need to think about having a nervous and stressed person on your team. If you haven't done this, and they perform poorly due to stress, you might have missed your best candidate.
• The more developers from the team are involved, the better (perhaps a rotating three-person interviewing team for example).
• Over time, build up a collection of programming exercises. You will need a string of performances in order to be able to judge comparatively, but you will also need a variety of exercises so that you can choose, for a given candidate, the exercise that allows their strengths to shine.
• Don't waste time on candidates that you haven't pre-screened with some basic technology questions first. (Really basic. Eg, What's the difference between a Set and a List?)
• There are many kinds of programming exercise.
  • Pattern-oriented: because you (probably) need these in your project: you can find or design an exercise that requires Command, or Strategy or example
  • For someone claiming to be a java "expert", design an exercise that shows a mastery of exception handling and inner-class use.
  • Find (or write) some particularly nasty code that your candidate can refactor and write tests for.
  • Best of all: don't interrupt your work, turn your current project task into an exercise. No interview exercise can be more relevant than this!
  • Avoid algorithm-oriented problems, (sorting, searching, packing, etc) - because libraries exist for this kind of thing so these exercises don't test real-world experience so well.
  • Avoid framework-specific problems (eg Swing, Hibernate): an exercise requires too much setup and context, and ordinary spoken Q&A are best for evaluating technology-specific knowledge.
• Incorporate test-automation. A solid candidate will grasp testing concepts even if they are not familiar with the frameworks you use.
• It's not just about coding and technical skills. This is your chance to sit next to your candidates, to work with them, as if they were already on your team. Do they have a sense of humour? The right kind of humour for your team? Are they comfortable, relaxed, confident? Do they listen, take the time to understand you, and verify that they understood you, before launching into the problem? Do you really want to work with this person?
• You're not a born interviewer. You will make mistakes. I did. Get over it. Interview more.

Gladwell argues in Blink that although we make snap judgements all the time, whether we can trust these judgements is a matter of experience. With a few years of interview practice, your snap judgements will gradually become more and more accurate. And maybe, at that point, a firm handshake and a quick, friendly, confident smile will be enough?

Now if there was a way to do this for presidents, and plumbers ... the world might be a different place ...