Different types of technical interview, and how to handle them

First of all, be careful with your criticisms of the code! When I used to run these, I’d make sure I was showing job seekers code I’d written many years before, and wasn’t particularly proud of, but you never know when someone’s presenting their masterpiece. Much as if you were code-reviewing a colleagues code, be sensitive — mix in praise liberally with things you think could be improved.

Chances are though that your interviewer knows there are things wrong with the code, or at least aspects that invite discussion. Are there methods or constructs you’ve previously seen issues with? The code I used to use for this used goto, which was always an interesting way to get the conversation going.

What are the failure modes in the code? Does it live and die gracefully? What assumptions does it makes about its environment? Are there situations in which those might not hold? How does it handle unexpected inputs? Is it performant? Is it making obvious trade-offs between readability, memory use, CPU use, or something else? Are tests included? Integration tests, unit tests, something else? Does the documentation clarify, confuse, or simply not exist?

Generally I’d steer clear of purely stylistic concerns — an interview is probably not the time to criticize indentation style. That said, if the code is inconsistently formatted then a discussion of linting tools can often lead to interesting places.

Remember that you’re being evaluated not just on your ability to identify strengths and weaknesses of the code under review, but also your ability to interact with other developers. Suggest things rather than being dogmatic, and while you should stand behind your opinions, avoid being too inflexible.

Implement an algorithm, solve a problem

One of the most popular tests with interviewers, and least popular with interviewees, is white-boarding algorithmic questions.

You’re (usually) not expected to simply know the answer, but rather to be able to tackle and reason about something unfamiliar. If you don’t know the answer straight away, be upfront with it. Ask for help on bits you don’t understand, and talk about what you’re thinking rather than expecting the interviewer to be psychic.

Generally the interviewer is trying to work out how you think, and how good you are with coming up with questions about the task at hand; what tools do you have in your toolbox, and how do you apply them?

Some companies have a real reputation for asking these kinds of questions. If you have time to prepare, making sure you have a good grasp of Big O Notation and doing some practice runs at home is probably a good idea.

Above all: show your working. That link just there was a whole article about specifically how to do it, and you’d be well served by familiarizing yourself with it.

Under no circumstances get defensive. However smart or capable you are, a developer who starts to attack the question and questioners is not demonstrating their ability to be normal for a few hours!

I pick on this particular tweet all time:

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

— Max Howell (@mxcl) June 10, 2015

Spoiler: he didn’t get the job he wanted, and on seeing that tweet, I suspect the interviewers didn’t feel they’d made the wrong choice.

Take-home technical test

My favourite test as an interviewee is the take-home technical test. You’re given a programming challenge or set of instructions, and you’re meant to complete it on your own machine, in your own time, at home.

Many companies use these as a prelude to an in-person interview, and you shouldn’t be surprised to see your code printed out at the interview ready for discussion.

Generally there’s a suggested time constraint, although I’ve never seen a developer penalized for spending longer on the problem to bring it up to what they consider their best effort. That said, some tests aren’t meant to be finished all the way — the questions get more and more time consuming. Try and bite off only what you think you’ll be able to complete to the best of your ability.

If you’re working with a programming language that has linting or static analysis tools, make use of them: you’ll catch silly mistakes, and it’ll probably guide you towards best practices.

Important: make sure you can explain every line of code you’ve included. [Calvin and Hobbes comic] It’s tempting to copy and paste code snippets from the documentation of framework from StackOverflow, but it’s also obvious that you’ve done so if you can’t explain how or why something work. If you start your JavaScript files with `”use strict”` I’ll expect you to know exactly what it’s doing and why it’s good practice.

Idiotic programming trivia

Every so often you come across a developer running an interview who’s learned something new recently and wants to show off their knowledge. Questions about Monads in any language other than Haskell, exotic data structures, and so on. I had someone ask me in an interview — in all seriousness — to explain what this does:

sub { return
 ((1 x shift) !~ /^1?$|^(11+?)\1+$/)
 }

(it’s a regex that finds prime numbers)

The wrong answer is: “Could you explain what this has to do with the job?” That you have a smart-ass developer interviewing you is probably not indicative of some deeper truth about the company, or even about your future colleagues — someone is having some (inappropriate) fun.

Unless you already hate the company at this point in the interview, it’s probably not a good idea to launch in to a heated take-down of their interview, parentage, etc. Instead, grin and bear it, and look impressed when they come to the big reveal and tell you what’s going on.

Parting thoughts

When it comes to running interviews, nobody knows what they’re doing, and all the processes are a bit broken.

However odd the process seems to you, remember what’s in your control:

• Appearing normal and likeable for a few hours
• Providing some basic evidence of your ability to work with the technology
• Not getting unduly upset about questions you don’t like

And, for the final time, show your working and be technically interesting.