How to not suck at a coding interview, musings of a Development Manager..

All Credit due:

Bill Sourour

Entrepreneur, consultant, and teacher.

Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it. But it’s not going to change any time soon. So, if you’re serious about getting a job, you need to understand how to succeed at these interviews. I’m here to help. We’re going to go over what Development managers look for in a coding interview and by the end, you should have a pretty good idea of how to succeed.

Before I start though, I have to say, if a company is going to hire a developer based solely and entirely on a piece of code the developer wrote in an interview, you probably don’t want to work there.

You’re more than just a coding machine.

Part 1 — Whiteboard Coding

Who on Earth writes code on a whiteboard? Like, seriously. But they are still going to ask you to do it. Don’t worry, they haven’t lost their minds. They get that Google is a thing and that whiteboards suck at autocomplete. They don’t care. They are not actually testing how well you write code on a whiteboard. They are looking for something else.

When you get the job you will never have to code on a whiteboard, but I guarantee you this, there will come a time when you are banging your heads against a problem and there is a deadline looming and you are tired and people are pissed at you and money and jobs and reputations are all on the line. When that time comes, you are going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast.

“They are not actually testing how well you write code on a whiteboard.”

While they don’t need a developer who can write code on a whiteboard, they do need a developer who can think on her / his feet, under pressure, in a room with others. The problem is, if you don’t understand what they are actually testing, you’re going to approach this task all wrong. You’re going to try to prove that you are a whiteboard coding ninja. This is dumb. No one needs a whiteboard coding ninja. Here’s how to win them over:

1. Verbalize your assumptions and seek to confirm them.

The best developers know that, fundamentally, every bug is the result of an invalid assumption. So, before you jump in and start coding, think about what assumptions you might be making, and ask me about them.

2. Think out loud.

They want to get some insights into your thought process. Knowing that you understand how to reason about a problem is far more valuable to them, than knowing that you’ve memorized the name of some built-in function. So, think out loud. Say what’s on your mind.

3. Don’t be afraid to ask for help.

If you’re stuck or don’t know something, ask ! Do you have any idea how fantastically expensive it is to hire someone who refuses to ask for help when he is stuck? They have no time for a developer who fails to deliver because he pretended he had everything under control while being completely lost and floundering.

4. Represent your skills and experience honestly.

Having said all of the above, they also don’t want to mislead you. There is a threshold for questions and commentary. If you are asking them about things that should be obvious to someone who presents with the skills and experience listed on your resume, that’s going to be a red flag. So, before you get to the whiteboard coding, make sure you’ve been honest in representing your skills and experience to them.

Part 2 — Coding on a Computer

Unlike the whiteboard, if you are given a computer and asked to write code, they ARE testing how well you can code. More specifically, they are testing how well you can code to spec.

The best way to understand what to do here is to look at a real world example. One of the favorite questions goes like this:

A palindrome is a word, phrase, number, or other sequence of characters which reads the same backward or forward. Allowances may be made for adjustments to capital letters, punctuation, and word dividers. Examples in English include “A man, a plan, a canal, Panama!”, “Amor, Roma”, “race car”, “stack cats”, “step on no pets”, “taco cat”, “put it up”, “Was it a car or a cat I saw?” and “No ‘x’ in Nixon”.

Write the most efficient function you can that determines whether a given string is a palindrome.

Your function should accept a string as a parameter and return a boolean (true if the string is a palindrome, false if it is not).

Assume that this code will be put into a real production system and write accordingly.

When offered a challenge like this in an interview, the first thing they are looking for is whether or not you asked any questions. As said before, the best coders understand that assumptions are what kill you in this business. My advice to anyone who is handed instructions and asked to code something is to take a moment and consider what assumptions they will have to make in order to complete the task (there are always assumptions) and then find a way to confirm or clarify those assumptions. I understand that in an interview situation, people go into “test mode” and feel like they’re not allowed to speak. What I suggest is that you start by asking the interviewer “Am I allowed to ask you 1 or 2 questions just to clarify some assumptions?”. If the interviewer says “no”, then just do your best. If they say “yes” then you have a HUGE advantage.

Good questions for this particular challenge would be:

·        “Is this client side or server side JavaScript?”

·        “For the purposes of this exercise, should an empty string be considered valid input?”

·        “Do I need to handle unicode characters?”

The next thing they are looking for is how well you can follow instructions. The example above, specified a string input parameter and a Boolean output parameter. Is that what you delivered?

After that, they want to see how you interpret the phrase “Assume that this code will be put into a real production system and write accordingly”. If you have built real software before, you should take that phrase to mean a few things:

·        Your code should be commented.

·        You should have error handling or at least logging.

·        Your code should avoid breaking at all costs.

·        You should have a test harness.

·        Your code should be easy-to-read and self-explanatory (clear variable names, good formatting, ideally “lint free” code).

If you have only ever seen code in tutorials and books, you won’t know that any of the above is expected. My advice to you is to go look at the code for popular open source projects. Especially projects that have been around a long time and are stable. For JavaScript, the jQuery codebase on GitHub is a pretty good example.

Next, they want to see what you make of the word “efficient” when combined with “production system”. If you’re experienced, you should know that “efficient” in production code means three things:

1.   Runs fast.

2.   Doesn’t take up more memory than it needs to.

3.   Is stable and easy to maintain.

You should understand that #3 sometimes means small sacrifices to #1 and #2.

On this particular challenge, they are expecting many will use RegEx as a part of the solution. The regex needed for this is some of the most basic regex out there, and regex is universal to many languages, it’s fast and extremely handy(edit: RegEx is not necessarily always fast, thanks AlexDenisov). It’s not unreasonable to expect that you know the basics of RegEx, but you could still write an answer without it.

For tests, they want to see that you included multiple tests, but that each test is testing a truly different scenario. Testing “mom”, “dad”, and “racecar” is redundant, they are all the same test. They also want to see that you included breaking tests; test for something that is not a palindrome. Consider edge cases, test for null or a number. Test for an empty string, or a bunch of special characters.

The criteria becomes more stricter the more senior they expect you to be.

For junior devs, if you can produce a working solution that’s reasonably straightforward and the rest of the interview goes well, they expect that they will be able to train you up.

For an intermediate dev, they want to see some comments in there and good coding style. They want to see an efficient solution and hopefully a test case.

For senior devs, they want an optimal solution, clean, maintainable code, error handling, comments, a full suite of tests. And for bonus points they want you to flag any of your assumptions in the comments. For example, if you use console.log() in client-side JavaScript add a comment that tells me you know there should be server-side logging in production.

Here are is an example of a good answer written in JavaScript.

https://gist.github.com/anonymous/e8553707cd6162040e7d12b2a1a0fa67

Obviously, there are other ways to write a passing answer, but that should give you an idea.

If given a challenge to take home, the expectations are even higher. If you get a week to code something with full access to Google, etc… There’s no excuse for giving a solution that is anything less than top-notch.

Part 3 — Algorithms

Some interviewers will ask you to code an implementation of a particular algorithm. Some think that’s just a giant waste of time. It’s far more important to understand which algorithm to apply to which problem. You can always Google the implementation.

Nevertheless, because interviewers will ask, you should brush up on the biggies ahead of time. Khan Academy has a great free course.

Part 4 — Passing Without Solving the Problem

If you are unable to solve the problem given to you, there are things you can do to stay in the running for the job.

You can do it!!!

1. Don’t give up too easily

Make sure that they see you’ve put in a real effort. If you’re the type who’s going to give up as soon as the going gets tough, they will have no time for you.

2. Pseudo-code it

If you’re having trouble because you don’t recall a certain function name or some other syntactic rule, use comments to explain what you were trying to do in pseudo-code. If they feel like you’re just a quick Google search away from solving the problem, it will go a long way toward your cause. Especially if you have an excellent interview otherwise.

3. List Your Known Unknowns

As an absolute “Hail Mary” if you are totally stumped, you can list all the things that you know you don’t know and describe how, in a real-world scenario, you would go about figuring those things out. Be as specific as possible. If you tell them you’d ask for help, tell them who you would ask (the role) and what you would ask them (the specific question, if possible). If you tell them you’d search online, tell them exactly what search strings you would use. In this scenario, you really need to go out of your way to convince them that you could solve the problem if you were actually working for them.

Part 5 — Practice, Practice, Practice

Arguably, the most important thing in passing a coding interview is to be well prepared. The best way to do that is to practice common interview coding questions over and over and over again until you know them cold. If you practice enough, and really work at it, you’ll even be able to handle a question you’ve never seen before. You’ll have confidence and you’ll be able to relate it to something else you’ve probably tried.

---