Here Is The Main Reason Why You Suck At Interviews

I’ve talked about interviews from one perspective or another on several occasions, you might even say it is a pet subject of mine. It’s fascinating because most people are no good at interviews and when it comes to developer interviews – well; let’s just say there is a whole new dimension for us to suck at with coding questions, whiteboards and whatnot.

Of course, the other side of the equation is not pristine here, the interviewer can be just as much to blame for a terrible interview, either through lack of training, empathy, preparation or a host of other reasons, but that’s a whole separate discussion. So, why are we so bad at interviews? You can probably think of quite a few reasons straight away:

• it is a high pressure situation, you were nervous
• you just didn’t “click” with the interviewer
• you were asked all the “wrong” questions
• sometimes you just have a bad day

Infact, you can often work yourself into a self-righteous frenzy after a bad interview, thinking how every circumstance seemed to conspire against you, it was beyond your control, there was nothing you could do – hell, you didn’t even want to work for that stupid company anyway! But, deep down, we all know that those excuses are just so much bullshit. The truth is there were many things we could have done, but by the time the interview started it was much too late. I’ll use a story to demonstrate.

The least stressful exam I’ve ever had was a computing theory exam in the second year of my computer science degree. I never really got “into it” during the semester, but a few weeks before exam time – for some inexplicable reason – I suddenly found the subject fascinating. I spent hours reading and hours more playing with grammars and automata. Long story short, when exam time rolled around I knew the material backwards – I groked it. There was some anxiety (you can’t eliminate it fully), but I went into the exam reasonably confident I’d blitz it (which I did). Practice and preparation made all the difference. Of course, this is hardly a revelation, everyone knows that if you study and practice you’ll do well (your parents wouldn’t shut up about it for years :)). Interviews are no different from any other skill/subject in this respect, preparation and practice are key.

Can You Wing It?

The one difference with interviews is that they are an occasional skill, almost meaningless most of the time, but of paramount importance once in a long while. It just doesn’t seem like it’s worth the effort to get good at them, especially if you happen to already have a job at the time (who knows, you may not need those skills for years). There are plenty of other subjects clamouring for your attention and anyway every interview is different, you can never predict what’s gonna happen so it would be stupid to waste your time trying. No – good communication skills and decent software development knowledge will see you through, right? Except, they don’t and it won’t. Sure, you might be able to stave off total disaster, but without preparation and practice, you’re mostly relying on luck. Things “click“; you get asked the “right” questions and are able to think of decent answers just in time. This is how most people get hired. As soon as the process gets a little more rigorous/scientific, so many candidates get weeded out that companies like Google, Facebook, Twitter etc. find themselves trying to steal people from each other since they know that those that have passed the rigorous interview processes of their competitors must be alright. The interesting thing is that the rejected candidates are not necessarily worse; they are often simply a lot less prepared and a little less lucky.

Over the last few years presentation skills have seen quite a lot of press. Many a blog post and much literature has come out (e.g. Presentation Zen and Confessions of a Public Speaker are both great books). Many people have decent knowledge of their subject area and have good communication skills, they think they are excellent presenters – they are wrong.

They put together some slides in a few hours and think their innate abilities will carry them through, but inevitably their presentations end up disjointed, mistargeted, boring or amateurish. Sometimes they sail through on luck, circumstances conspire and the presentation works, but these situations are not common. Malcolm Gladwell is a master presenter, he is one of the most highly sought after and highly paid speakers in the world (and has written a bunch of awesome books to boot) – this is not by chance. Without doubt he knows his stuff and has better communication skills than the majority of speakers out there and yet all his talks are rigorously prepared for and practiced. To my mind, the situation with interviews is similar to that of presentations, except the deluge of literature about interviews goes almost unnoticed since they are old-hat. The digital world hasn’t changed the interview process too significantly (unlike the public speaking process), except the internet age brings all the old advice together in one place for us and all of that advice is still surprisingly relevant.

The Old-School Advice

Everyone (and I mean everyone) always says that you should research the company you’ll be interviewing with beforehand. You would think people would have this one down by now, especially developers cause we’re smart, right? Nope, no such luck, just about everyone who rocks up for an interview knows next to nothing about the company they are trying to get a job at, unless the company is famous, in which case people are just full of hearsay. But hearsay is no substitute for a bit of research and it is so easy, I am reminded of an article Shoemoney wrote about getting press (well worth a read by the way, if you’re trying to promote a product/service) – there is a tremendous amount of info you can find out about a person by trawling the web for a bit and it is just as easy to learn something about a company. I mean, we do work in software, so any company you may want to work for should have a web presence and a half.

And even if web info is sparse there is your social network or picking up the phone and seeing if someone will trade a coffee for some info. Yeah, you go to a bit of trouble but the fact that you did will be apparent in an interview, I mean, there is a reason why I work where I work and I’d prefer to work with other people who give a shit (everyone would) – you savvy? Of course if you do go to the trouble to find out what skills/tech/knowledge/processes a company is looking for/values you may be able to anticipate where an interview might head, the value there should be self-evident.
Which leads me to interview questions. When it comes to developers, there are three types of questions we struggle with/despise:

• the behavioural/culture fit
• the coding question
• the Mount Fuji question

With a bit of practice you can blitz all of these. The Fujis are the hardest, but even they can be prepared for, but I’ll get back to those shortly.

Behavioural Questions

The behavioural questions seem annoyingly difficult but are actually the easiest. You know the ones “Give me an example of a time when you demonstrated leadership/communication skills/problem solving/conflict resolution“. It is always the same question, with a different attribute of yours that you have to spruik. Being in essence the same question you can address all of them with what amounts to the same answer, once again substituting a different attribute. These are actually difficult to handle on the spot, but if you have something prepared it is a breeze. Example:

“There was a time, when Bill the developer was being an obstinate bastard and wouldn’t buy in to the awesome that the rest of us were peddling, but I took charge of the situation and was able to convince Bill blah, blah ….” – leadership

“Bill the contrary developer just wouldn’t agree with the way we were dishing out the awesome, but I took Bill out for coffee and we hashed it out one on one blah, blah …” – communication

“There was insufficient awesome to go around and Bill and Joe just couldn’t share it and were coming to blows, but I stepped in and took them both to a whiteboard, we had a long chat blah, blah …” – conflict resolution

As long as you think up a situation beforehand you can adapt it to answer any behavioural question, the situation can even be a fictitious, but you do need to think through it carefully for 10-15 minutes to be able to come up with something coherent. You will never have time to frame a coherent reply in the interview itself. Of course, it is best to have a few situations prepared just so you can change it up a bit, variety never hurt anyone. If the company you’re interviewing with is enlightened they won’t ask you these questions, but will instead focus on your dev skills, but there are many companies and few are enlightened, might as well prepare for the worst case and be pleasantly surprised if the best case happens.

Coding Questions

Talking about dev skills, the one thing that just about every company that hires developers will do, would be to ask a coding question at some stage. These usually take the form of a sandbox question or what I call a Uni question. You know the ones, “Reverse a list“, “Implement a linked list” it’s as if they are under the impression you studied computer science at some point, go figure :). People struggle here, because you just don’t come across this kind of question in your day-to-day work. If they asked you to implement a Twitter or Facebook clone, you could really show them your chops, but balancing a binary tree – who the hell remembers how to do that? And that’s the rub, you probably could dredge the information from the depths of your grey matter, but by the time you do the interview will have been long over.

Because you don’t do this kind of question daily, you brain has dumped the info you need to tape and sent it to Switzerland (cause backups should be kept off-premises). The answer is simple; you gotta practice these questions well in advance of the interview. Preparation baby, that’s the ticket. Preferably you should be doing them regularly regardless of your employment status cause those questions are fun and bite-sized and give your brain a bit of a workout – you’ll be a better developer for it. The most interesting thing though is this, you do enough of them and you won’t really encounter anything new in an interview. There are really not so many themes when it comes to these questions, it will be the same formulae you’ll just need to plug in different numbers (a simplification but not too far from reality). I really gotta follow my own advice here. If you seriously want a leg up, there are books specifically about this, I prefer Cracking the Coding Interview but there is also Programming Interviews Exposed – read them, do the questions.

Puzzles

Mount Fuji questions are the most controversial, but regardless of whether you hate them or not, even they can be practiced. Yeah, alright, maybe you’re willing to walk out if any company ever dares to ask you about manhole covers, but I’d much rather answer the questions and then walk out in self-righteous satisfaction rejecting the offers they’ll be throwing at my feet, than storm out in self-righteous anger knowing deep down that I was a wuss for doing so. And anyway, I’d like to think that I’ve already demonstrated that not all Mount Fuji questions are created equal, some are coding problems, others deal with concurrency, others still might be back-of-the-envelope questions (the story of how these originated is actually pretty interesting, I am writing it up as we speak). The subset of questions that are simply a useless puzzle are a lot smaller than you might think. Doing these kinds of questions in your spare time is just another way to build your skills with a side benefit that you become an interview-proof individual. Of course, many people also enjoy an occasional puzzle – I’m just saying.

There is still lots more to say, I haven’t even begun to talk about attitude, but this is already a tl;dr candidate, so I’ll leave that discussion for another time. Let’s sum up, if you feel that you suck at interviews, it’s because you didn’t prepare well enough and haven’t had enough practice – it is that simple. As an interviewer it is most disheartening to see an unprepared candidate, there are just so many of them, on the other hand a person who is clearly on the ball is just awesome. And I am well aware that practicing interviews is hard, there is no Toastmasters equivalent for that particular skill, but thorough preparation can significantly mitigate that issue. Even a few minutes of preparation will put you head and shoulders above most other people since the vast majority don’t bother at all.

So, take the time to practice/prepare if you have an interview on the horizon, be smart about it and it is bound to pay off, not to mention a better experience for the interviewer as well, more fun and less stress for everyone.

Reference: Here Is The Main Reason Why You Suck At Interviews from our JCG partner Alan Skorkin at the Developing in the Google Cloud blog.