The Interview - Part One

I can’t watch The Apprentice on TV any more. This week they did the ‘interviews’, where each contestant (for they surely cannot be considered job applicants given the game-show styling of this series) is questioned by a succession of Alan Sugar’s smirking self-made self-satisfied buddies. It’s not that I object to putting the remaining goofy wannabes through a bit of discomfort - I mean you have to question whether the defining profile of the ideal candidate would really include a desire to engage in a protracted assessment centre on public television - it’s that they’re clearly not interviews. The show bares no relation to any business world or recruitment process I have ever seen or heard of. And that insults my intelligence, which is why I can’t watch it. Call the show ‘Cheap Laughs At the Expense Of Some Over-Confident Ineffectual Tossers’ and I might reconsider. But The Apprentice it ain’t.

I only started watching the show (after perversely enjoying the US version with Donald Trump) because I have a sentimental regard for Alan Sugar. My first ever paid software job was an entrepreneurial foray on the Amstrad PCW512, writing a stock control system for a local plumbing firm. I got a verbal spec, borrowed the computer (no build/deploy issues when you write directly onto the production kit), taught myself CP/M and Mallard BASIC, wrote the software and ported the legacy data (which was stored in word processor documents in a highly irregular format) all in two weeks. I even added a few features that weren’t in the spec, such as a ‘total on-hand stock value’ report, which became more important than the requested ones. I got twenty pounds for doing it (and contrary to my grandmother’s favourite expression, this wasn’t in the days when twenty pounds was a lot of money..). Thus, some might say, the precedent for a the rest of my career was set. But back to those interviews..

I was a freelancer for quite some time so I’ve interviewed, and been interviewed, many times in my career. The other day I unearthed a set of interview questions from the early nineties I wrote to screen candidates on emerging web technologies. I’ve got three sets of recent questions on my desktop right now. My plan had been to summarise these into some sort of essay but the Apprentice debacle made me think to create two, hopefully more useful, posts - one on the art of running an effective interview and another on how to succeed in one.

The Technical Interview

I can’t remember where I heard this but it’s so true it’s worth repeating: if you were tasked by the CEO to deliver a massively-complex new system with such strategic importance that it would annihilate the competition, save the company from extinction and win you eternal adulation, but you only had eight weeks to do it, what would you ask for first?

Most people don’t say “the latest IDE” or even “a quiet place to work”, despite the fact that they would be potentially important considerations. What people say is “OK.. I’ll give it a shot.. but I need Fred, Jimmie, Cecile and Brian”. Deep down, even the geekiest geek knows, it ain’t what you do, or even how you do it, that gives you the best chance of success - it’s who you do it with.

And that’s what the interview process should give you. Not people like you. Not even people you like (although if you don’t like the people that make your team effective, I would suggest a holiday and some light therapy). And determining that in what amounts to no more than a couple of hours is a very tall order indeed.

The Objective

I don’t say this to make some glib “it’s all about the people” statement, but to highlight that the whole raison d’être of the interview process is to find someone to join the team who will work well with the existing members, make you look good, be relied upon when you’re away, and be on that must-have list of people for Project Suicide.

What you want is to put the candidate (initially) so much at their ease that they cannot help but be as they truly are, without art or artifice, to make a proper assessment. That’s why the apprentice interviews were so farcical, because each interviewer harried and harassed the interviewee even as they attempted to respond to their smug and largely pointless questions, achieving nothing in the process. And though thankfully not very common, I have sat opposite the odd clever clogs who seems to think it’s good practice to pose obscure technical questions, knowing you are unlikely to have the answer. I once said to one such interviewer that I would be happy to get into any level of detail he wanted, as long as I could ask him some technical questions in return. He declined.

The fact is it’s ridiculously easy to come up with a question that will embarrass the interviewee. But it tells you nothing. You may as well ask them for the name of your first pet. And I’d go so far as to say it’s bad practice to, for example, ask Java developers to describe the methods of the Java Thread class. OK, so you might do this if there was an immediate need for a certain kind of Java developer, but really.. is knowledge of a class library going to tell you whether they’ll make bad decisions for you to address when you get back from holiday? No. Of course not. But I’m not saying the interview should be some back-slapping love-in, you do need to know how someone reacts when out of their comfort zone. So let’s look at an approach that does both.

The Pre-Processing

The first step to a successful interview is who you interview. A little off topic but it’s important to cover the three prerequisites.

• Statistical Acceptance

  That old metric that a good developer is ten times as productive as an average developer applies throughout the IT department. What’s not often said is that those smart people are really rare. Really, really rare. It’s hard to put a figure on it, but I’d say if you are after the best you’re looking at less than ten percent of the market. And I apply that to management positions too, possibly moreso. So start with the acceptance that you want good, good is rare, and therefore you need an approach that kisses a lot of frogs to find the prince. And that means patience and hard work, never be tempted to take a short cut (if you need to fill a role immediately use a freelancer on a short contract, filling permanent roles too fast really is a case of hire in haste, repent at leisure).

• Filtering

  The primary defence against frogs is the filtering process. I use a three-stage filter.

  The first filter is the agencies that forward candidates. Don’t just send them a role spec - because they’ll just extract keywords and buzz-phrases and send candidates that can game the system. Get the agencies in, talk about the kind of person you need and then give them the spec. That way when they talk to candidates they’ll be thinking about more than whether they have four years of Java or not. Unless you’d rather have someone with four years of Java who will bore you silly, over someone who’s amazing but only has three of course.

  Next filter is the CV/résumé itself. I won’t bore you with things like grammar and spelling etc. because you know what you like to see, but I’ve found that the three biggest warning features are: lots of short roles (these days it’s not uncommon to change jobs every couple of years, but not every three or six months), gaps between roles (one or two maybe, but a three or more might signify that they’ve struggled in interviews elsewhere) and of course impossible brilliance (if they’ve single-handedly saved the last three companies they work for and aren’t a multi-millionaire I’d suspect a little exaggeration).

  Filter three is easy: check the last three to five years of experience only, and look for a soft-fit to your profile. If you want a Test Manager and they haven’t test managed for ten years they’re hardly going to hit the ground running. If there’s a reasonable fit then think of two easy questions about this period of their career and write them down. It’s time to hit the phones.

• Phone Interview

  Always, always, always phone interview first. Your hours are few and the frogs are many so even at this stage you will be interviewing far more than offering. Set aside an hour or two and arrange a number of 15 minute (maximum), conversations. Break the ice, take a couple of minutes to outline what you are looking for and ask your two easy questions. And listen. It’s not about what they say as much as how they say it. And be ruthless, shortlist one or two for a face-to-face (you can always go back to the others later).

The Question Areas

Naturally, questions should be pitched at a level appropriate to the position, but frankly I’m of the mindset that all jobs in and around software development, from business analyst to tester to architect to CTO, require a certain, let’s say, uncommon approach, and for this reason I tend to stick to the same question areas regardless of the role specifics.

The categories I think you need to come away with a view on are, in no particular order: knowledge, drive, aptitude, reasoning, creativity, management, organisation and vision. Some roles may require less of one area than another but rarely none at all. The areas should overlap so when asking a question around aptitude, be on the lookout for any opportunities to dig deeper into organisation, for example.

• Knowledge

  So having said that it’s a waste of time focusing on technical specifics, clearly each role requires prior knowledge of something. If you were looking to hire a web developer they have to have knowledge of web development. Hopefully the CV/résumé filtering process will have short-listed only candidates that do but there’s no harm in asking.

  However, rather than go to the trouble of researching the built-in Rails helper functions for a techno-fest of probing, just get the candidate to describe, or better still draw, how they think Amazon works, or eBay, or any other reasonably complex web site. As they answer, ask about build environments, testing, monitoring, operational concerns, and so on. It may not be how Amazon actually works but you’ll certainly find out more about their technical nous than if you’d asked them to describe the difference between form_tag and form_for (which if they don’t know now they can look up on Google if they are smart).

• Drive

  I like to know how much someone loves their work. Anyone who has a passion for what they do will tend not to see it as a nine to five thing, with ‘life’ happening elsewhere. So I like to ask where they get their information from: which web sites do they read, what books, blogs or thought-leaders they like to follow.

  To make sure they haven’t just made the list up to sound impressive, I might ask some specific questions about sites we both read or what one is like compared with another. It’s easy data to check up on.

• Aptitude & Reasoning

  You can know a lot of facts but still not be able to apply them, so it’s good to have a design test. Have a few real-world applications in mind and ask the candidate to design their version of one of them on a whiteboard.

  I’d apply this exercise even to management roles. I don’t see why the most business-focused CIO on the planet shouldn’t have a view as to how a good order-management solution should operate. I’d expect less in the way of aspects like state-management than I’d get from a developer but even CIOs buy things on the internet and have thoughts on what good customer service is.

  The point is to put the candidate under a little pressure. Unless your organisation never has a bad day, you need people who can think on their feet and not become overwhelmed or panicky. The difference between pressure and intimidation is that you aren’t distancing yourself from the candidate and saying ‘you suck’ you are saying ‘solve this’ and of course they can also ask you to clarify as they go (another useful test in itself is what kind of questions they ask to complete the task).

• Creativity

  You may come out of the aptitude test with a clear view on creativity, in which case this may not be necessary, but if the design task was a little too easy then similar questioning on unfamiliar territory will help and no need for the whiteboard unless it makes sense. Take a current issue you are dealing with right now, appropriately sanitised, and get them to come up with a creative solution (and say that you want a creative solution).

  This is likely to be fairly stressful so you’re looking for two things. An ability to think outside the box, a little impracticality is allowed given this is off the cuff thinking, and some sense of logic to the proposal.

• Management & Co-operation

  Good management is about many things and one of them is cooperation (with peer managers, inspiring it in teams) and if you think of cooperation as a kind of symmetric sharing of tasks, then it’s asymmetric cousin is delegation.

  My two favourite areas are the classic how to handle a shared task across a team when one or more members of the team disagree, and the art of delegation and performance management.

  I am always wary of anyone that answers performance management by saying that they’ve fired people because it ‘had to be done’. They’re either lying to make it sound as if they’ve managed people when they haven’t, or they have a penchant for not following process. Managers don’t fire people, HR fires people, and only ever as a very last resort. Real life dictates that you won’t ever have a ‘perfect’ team unless it’s very small and you built it from scratch. Managing is as much about getting the best out of peers and direct reports as it is about finding the stars of tomorrow.

• Organisation

  OK, so they know stuff, they are passionate about their work, they can think on their feet and play nicely with others. There’s only the book-keeping to go.

  I always try and get some sense of how they organise themselves (and potentially others) simply because all the above only really tells you that they know what to do, whereas getting things done requires all that boring stuff that project managers are meant to be good at - categorisation, prioritisation, planning, estimating, and so on. If this were a project manager interview you be mostly on this topic for the whole session.

  For this, I don’t believe you can ask vague questions about simulated problems. This is where you have to have marked out some achievements on the CV and get chapter and verse. If the CV is a true reflection of their work they should fly through this: How did you set out to deliver on Project Mayhem? How did you resolve conflict? What did the requirements look like? Describe your deliverables?

  Here, you are looking for a clear methodical mindset and above all a real sense that they did what they say they did. Look for sentences that begin “we did…” not “I did..”. You don’t care about what the whole team achieved, only what they contributed.

• Vision

  My favourite last question of the day is simply to ask what the future looks like. Depending on the role there will be all manner of research, ideas, software developments, etc that influence how things are done next year and in five year’s time. I would hope a Programme Manager four years ago was as excited about Portfolio Management as an Architect would be about EDA today. It’s hard to fake passion and excitement so the answer to this question, suitably probed, will speak volumes.

• Communication

  I’m just throwing this in because someone asked me about communication questions the other day. Well .. er .. that’s sort of the whole interview. You shouldn’t need to ask about their communication skills, because you have been sampling them. However, if the role requires a lot of stand-up presenting then of course make this an add-on session. I’d recommend dropping at least part of the other pressure tests though, because you’ll get a lot of what you need from the presentation style.

The Examples

Here’s a few to start with. As I have time I will add to this section.

• Role Questions

  What’s your definition of {this job} as it applies to this businesses?
  Contrast {this job} with {similar job}?
  How would you apply {this job} in {unusual circumstance}?

• Knowledge Questions

  If you could access the secret plans, what do you think you would see in the designs for {well known website}?

• Aptitude

  Here’s a pen, show me a first cut model of how you would solve our companies problem with {common problem}?

• Drive Questions

  Why did you chose {this job} and not {similar job}?
  What industry web sites do you regularly read and why?
  Which thought-leaders in the industry do you most admire and why?

• Management & Cooperation Questions

  Where do you draw the line between delegation and responsibility?
  What instructions would you give to me if you were to delegate a task to me?
  How would you make sure your delegated tasks were successful?

• Technology Questions

  These are some easy ones that I have found sometimes get interesting responses. I have no idea why.

  What’s your favourite high level language and what would you not use it for?
  Software Developer or Software Engineer? Which term describes the role better and why?
  For a small {favourite language} development team, describe your perfect team set-up in terms of team size, roles, IDE, source control, build, bug tracking software, etc.
  Describe what you understand by the term ‘design pattern’?
  Can you describe the {very common pattern} and explain why it’s a pattern at all?
  Can you describe what you understand by the term Dependency Injection?
  Can you describe what object-relational mapping is?

• Vision

  What are the most exciting developments today that will influence the way {this job} will be performed in 5 years?