An Interview Icebreaker
Kicking off an interview can be hard. We all know what it’s like to be on the other end of the phone line or the other side of the desk waiting to be fed questions that might be designed to trip us up or check out how much we know about the esoteric and dark corners of our technology stack. Being in fear of this is not a good way to get a candidate to be comfortable and therefore to stand a good chance of performing somewhat near how they would on the job.
Telephone interviews are a common early screening technique and in my experience it’s an all too common scenario where interviewers cut-to-the-chase and launch into a series of gnarly questions which often do little to either prepare you for the job in question, or they hope to filter you out as quickly as possible so they can get back to their day job.
This kind of approach has always bugged me and so over the last few years I have been trying to find better ways to ease potential candidates into the interview process so that hopefully they’re more comfortable and eager to chat about what makes them tick. One such icebreaker that I’ve developed has turned out to be quite useful, not least because what started out purely as a bit of fun has on occasion provided some interesting insights that became useful with candidates later in the overall process.
The basic premise of the icebreaker is to present the candidate with a number of somewhat silly and seemingly pointless comparisons and ask them to (arbitrarily) choose one. Even in just a few minutes it’s quite easy to rattle through a couple of dozen, which, if chosen reasonably well should bring a smile to candidate’s face and maybe even a “knowing glance” or a slightly quizzical “hmmm”.
The outcome is largely intended to get the candidate talking comfortably and therefore I usually take a fair bit of effort to convince them that this is all just a bit of harmless fun, and that the answers are by-and-large utterly meaningless. Some candidates are a little more suspicious than others and so I always make sure I start with the more trivial questions to make sure they quickly get the hang of it and realise I’m not going to suddenly ask them to estimate the number of lampposts in Liverpool or the inner workings of a modern garbage collector. (I also steer clear of the obvious choices such as whitespace characters or text editors.)
Hence my opening few questions generally go like this:
As you can see there is clearly no right or wrong answer, they are purely a matter of opinion (unless it involves Internet Explorer or Visual SourceSafe). Some candidates might initially try to give you some justification, e.g. why Bing is so much better these days, and therefore you may have to remind them that it’s really just a bit of fun. Consequently I have a number of very silly comparisons that I like to throw in if I feel something even more light-hearted would help with the defrosting process, for example:
· Daily stand-up or daily sit-down?
· No SQL or no transactions?
· Jira or Post-It notes?
· BDD or TDD?
My original intention was to throw some less random, but perhaps also still apparently arbitrary choices in just to see what the reaction was. I was a little concerned that if I picked a specific technology or process that was in use on the actual project then candidates might feel obliged to answer with that choice or they might feel I’m trying to catch them out in some way. Hence these were some of the slightly less arbitrary choices that I initially began to mix in:
· Whiteboard or pen & paper?
· Scrum or Kanban?
· NUnit or MSTest?
· Mock or stub?
· SOAP or REST?
While this was still mostly a bit of fun I wanted to see if I could come up with some more coding specific choices that I could weave in later on that might give a suitable candidate something a little more meaty to chew on. I realised that this was potentially moving away from my original goal but given the way candidates had been responding to the exercise it felt like it was worth a punt. These were some of the choices I began to add (mostly for C# senior developer roles):
These were all pretty well received although naturally some candidates had to be reassured occasionally that the answer to every single question was really “it depends”.
I always liked to finish off with a couple of silly ones just to make sure we ended the exercise on the right note. I would also check their “temperature” by asking them if they enjoyed the exercise and whether they felt “warmed-up” and ready for something a little more “deep”. (The rest of the telephone interviews were longer questions aimed at exploring how they solved particular kinds of problems, e.g. parallel data loads, cache construction, monitoring, etc.)
When I started out this was intended to just be an icebreaker, I never for a moment believed that anyone’s preference for Bing over Google, or watching tutorial videos instead of reading books was going to be an indication of a programmer who would be unsuitable for a role. And I still don’t. However, perhaps unsurprisingly, as the set of questions grew some minor tell-tale signs did appear, which, by themselves, were not something you’d make a hiring decision on but maybe did indicate areas that you might want to focus on in the rest of the interview if there were no other pressing concerns.
For example, terminology was one aspect that came up a few times. While someone starting out their career in programming might not have been introduced to terms like “tuples” (however you choose to pronounce it) or “feature toggles” I am more surprised when a senior-level programmer is unaware of them. And, while they should be able to pick up new concepts relatively quickly, if it forms a significant part of the role then that is something I’d like to double-check sooner rather than later. On the plus side having a candidate admit up-front they don’t know something is a good sign which should be appreciated. Hence, in response to this I started throwing in the “lambda or closure?” near the end just to see what the response was.
Some of the more subtle clues I managed to pick-up on were around the combination of choices. In a number of cases the follow-up interview was a programming exercise – just a simple kata. Solving the kata in the short interview timeframe was never really the goal, but seeing how they approached it and responded to questions about their approach, was. For example in one case a candidate who had chosen “abstract base class” over “interface” and “inheritance” over “composition” showed the hallmarks of a C# programmer still thinking like a 90’s C++ programmer, in the sense that the design was classic Gang of Four rather than more idiomatic C#. After that discovery I made a note to try out biasing my follow-up questions slightly to explore class design in preference to other topics. (This was not the only characteristic which made that particular candidate unsuitable for that specific role but it did highlight how important writing code can be in an interview process.)
On a similar note I began to use a candidate’s preference for ToList(), the object initializer syntax, etc. as a cue to discuss mutability concerns. In the intervening years I’ve started to throw in a few other classic trade-offs such as returns codes and exceptions, null references and options, and primitive types versus domain types partly for variety but also to see what reactions it provokes or smells it might give off.
Since I started using this icebreaker a few years ago I’ve never dismissed a candidate purely because I didn’t like the choices they made. On the contrary I’m well aware that “one size never fits all” and diversity is to be embraced and therefore it’s only been used as a line of conversation to explore the forces that drive their choice and, more importantly, to see whether they are conscious ones or not.
It’s almost certainly an unconventional technique, at least by normal enterprise recruiting standards, and therefore it has the potential to have the opposite effect and make some candidates more nervous, not less. Not everyone is happy in an interview to just say the first thing that comes into their head and so I have been careful to gauge their opening responses to see if it’s working against me. Apart from one candidate that proceeded to launch into a lengthy explanation on the very first question to justify their choice, I’m not aware of anyone else that’s not got the hang of it pretty quickly.
Feedback from candidates appears to be favourable, mostly from the novelty angle. The fact that recruitment agents have mentioned it seems to back that up. The reason I find that feedback pleasing is that we have to remember interviews are a two-way street – the candidate is interviewing us as much as we are interviewing them. Asking the same boilerplate questions does little to help sell your position to them, whereas putting a little more effort into the process might help compensate for a less stellar job spec. In my experience working with interesting people rates pretty highly on the job satisfaction scorecard and so I’ll try whatever tricks I can to try and lure those candidates in. I wouldn’t want them to turn the job down prematurely because the interview process was uninspiring.
Interviewing for a new job is always a daunting prospect, especially when you’re a bit rusty. Acknowledging that and factoring it into your interview process should help you make the most of those precious few minutes you get with each candidate. This icebreaker is intended to inject a little light-hearted humour into a traditionally stale process and, maybe, at the same also provide a rapid-fire technique for triangulating on further points of discussion. If nothing else you’ll have a bit of fun coming up with a list of amusing choices.
Chris Oldwood
06 December 2018
Chris is a freelance programmer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros. These days it's enterprise grade technology in plush corporate offices. He also commentates on the Godmanchester duck race and can be easily distracted via gort@cix.co.uk or @chrisoldwood.