The coding interview

Don't rule yourself out

The code interview

The interviews I want to write about are specifically face-to-face code interviews. I have interviewed quite a few people over the years and too many of them seem to be going out of their way to fail. So these are my tips on how not to rule yourself out.

First off, the elephant in the room …

… Code interviews are bad

There is a school of thought that coding interviews are fundamentally flawed. Maybe that is true but they are still used and you may want to work for a company that happens to do them, this is for you. If, as is your right, you opt out of working for any organisation that has this kind of filter then do just that, opt out.

“We'd like to ask you in for an interview”

First step is to ask some basic questions;

  • Is there a coding part to the interview?
  • What language?
  • Will I need to bring a laptop?

Ask any question that will help you. Then …

Prepare …

You owe it to yourself to prepare for the interview. Beyond the basics of refreshing your memory on what you have been up to recently, knowing who you are meeting, where, when and how you will get there there are a few more things to do.

… your machine

Is you laptop up to scratch? Is your old 4kg i3 with a flaky HDD something you want to rely on to get a job? If not then ask to borrow one from a friend or ask the company about borrowing a laptop but bear in-mind that it won't be set up the way you like it even down to the OS. Maybe this is the excuse you've been looking for to refresh your own kit.

Make sure you have installed any and all system updates that are worth installing. Ensure you have a working IDE (or what ever it is you use). I had a candidate turn up with a laptop with nothing useful installed except a web browser, I improvised and used Java on http://glot.io, it was not great but it was all I could think of at the time. Don't let this be you

An aside on trackpads, I see very few people use them well, maybe this a personal bias but if you prefer a mouse over a track pad then take one with you and use it.

… your tools

If your language/platform will take several minutes to get itself setup then create a basic empty project (command line, library/package, web, or what ever works for you). At the beginning of the interview ask if it is ok to pick one of these skeletons you have prepared if it makes sense.

Are the interviewers likely to want TDD/BDD/Mocking? If so make sure you have all the libraries/packages/modules you may need cached locally. Even in 2016 WiFi will fail to work when you need it. You can certainly expect working WiFi but don't depend upon it. Be in charge of your own destiny.

Turn off your social media and other notification apps, you probably don't want your friend's request to go for a coffee/beer/milkshake to pop up in the middle of the session.

… yourself

You have made the decision to look for a new job then start practicing for interviews.

Many coding interviews involve some common coding kata, or a derivation of one of these. Doing these tests in you own time will be a reminder just how little you can achieve during a typical interview period (typically an hour or so).

Try several different styles of problem. The Guardian have a list, Cyber Dojo has some too. Project Euler may be of interest though has a mathematical bias.

Whilst tackling these exercises talk yourself through your solution, out loud. What trade-offs are you making and why? Are you taking a short-cut because there is little time?.Are you going for a simple but less performant solution, if so explain it to yourself.

Take the role of ‘product owner’ for the kata. Don't write code without requirements, as soon as you ask a question that has no answer, make one up and write it down.

The Interview

Turn up on time, with your laptop if required. You've obviously got a list of questions you want answering and you know why you want the job and why they want you.

The coding section

Once you've been given the problem take a moment to think about it. Re-state the problem to the interviewer for clarity and ask questions as appropriate. Occasionally you will be asked to solve a problem that could be done with an existing library or package. By all means say that you would use such a thing under normal circumstances but it is unlikely that this is the way to pass the interview.

As an interviewer it is easier to appreciate a candidate if they can narrate their thinking. This is why it is worth practicing. You can express your assumptions and reasoning more quickly and richly verbally than just by typing. Remember though, the bits the interviewer can't see is what's in your head and that's the bit you need to make visible, not “I'm creating a project”, “I'm writing a function”.

When I observe a coding interview, I'm interested in the conversation around the solution as it grows. If you have to make trade-offs due to the time constraints of the interview then talk about them;

  • can you use a const instead of a config file
  • will a map do instead of a database
  • can all the code go in fewer project/package/file

Talk briefly about what good looks like in production vs what you might be doing in the interview and justify why you are making that choice.

Some interviewers are looking for a demonstration of SOLID principals, or patterns or some other structure. Don't fall into the trap of trying to shoehorn every technique you've ever learned into solving a simple problem, it probably won't help.

Trick questions

There are no trick questions.

The days of interviews being about trick questions are, thankfully, long gone. Try and take the question in context; interviews are artificial, the coding question is artificial, the limited time is artificial, the whole thing is design to allow candidate and interviewer to decide if there is a mutual suitability for future employment in a limited time-frame. The objective of a coding test is to see how you think about and write software not lateral thinking puzzles.

Testing

If you're the kinds of developer that doesn't like testing then I will assume you are interviewing at a company that does not want tests. If you think testing is a good idea then say so and write the tests. You should already know how hard line you are going to be about coverage, style, test first or after. But explaining your thoughts and reasoning will go a long way to help the interviewer.

I'd recommend testing though, you can't go wrong.

Participate

So far this has all been about the candidate demonstrating their skills and experience to the potential new employer, that's only half of it. You, the candidate, are interviewing them too. At some point during the interview you are responsible for deciding if this is the kind of place you want to work. Ask about how they work day to day, but you probably don't want to spend too much time with chat during the coding.

You don't need good luck, you need practice and preparation.

External Links

Edits