I spent the day yesterday interviewing programmers for a new start-up near Bristol. It’s a job I love. I’m always intrigued to hear about peoples careers and how the approach the challenges we present. For me recruiting a programmer has to start with code. I don’t really care about the CV and the application process for this job involved a quick coding problem. Passionate programmers are able to communicate their ability far more easily through code than by describing their experiences.
Traditionally interviews usually start with a discussion about the role and the candidate’s past experience. It’s often an uncomfortable conversation, everyone is a bit nervous and out of their comfort zone and I rarely get anything useful from it. I’ve learn’t that if you start with code, sitting side by side, sharing thoughts on the pre-interview problem, good candidates quickly relax. Then is the time to asking questions that go beyond programming. For me these questions focus on how they like to collaborate with others. I’ve noticed the answers I get after we’ve looked at code are very different. Some trust and mutual respect has been established and people tend to share more openly how they really feel.
How do you handle people that have a obvious test anxiety?
Or you can also asked these weed out questions to see if candidate is worth of your time or not.
Hi Tom,
Do you have any examples of problems you look at in an interview?
Cheers,
Kelvin
Many years ago, I wrote (very rapidly, under time pressure) a tiny, “trivial” code sample (perhaps 10 lines of Java) to be used (on paper) as a discussion point in interviews; I wasn’t very happy with it at the time, and intended to come back later and write something bigger, more elaborate and more challenging. However, a senior colleague told me recently that she’s still using it, and it is remarkably effective at both separating those who can program from those who just claim to be able to; and also as a jumping-off point for all sorts of technical discussions about correctness, memory, performance, mathematics, etc.
So even if your organisation doesn’t want to get candidates to do real coding in an interview, or use pre-interview problem – almost any code is better than no code!