How to Win the Coding Interview
I’ve designed and conducted dozens of coding interviews. Now, I’m going to show you how to beat me every single time.
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 I look for in a coding interview and by the end, you should have a pretty good idea of how to succeed.
You can get it here.
Before I start, 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.
Part 1 — Whiteboard Coding
Who on Earth writes code on a whiteboard? Like, seriously. But I’m still going to ask you to do it. Don’t worry, I haven’t lost my mind. I get that Google is a thing and that whiteboards suck at autocomplete. I don’t care. I’m not actually testing how well you write code on a whiteboard. I’m 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 we are banging our heads against a problem and there is a deadline looming and we’re tired and people are pissed at us and money and jobs and reputations are all on the line. When that time comes, we’re going to have to get into a boardroom, hop on a whiteboard, and figure things out. Fast.
“I’m not actually testing how well you write code on a whiteboard.”
While I don’t need a developer who can write code on a whiteboard, I do need a developer who can think on her feet, under pressure, in a room with others. The problem is, if you don’t understand what I am 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 me 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.
I want to get some insights into your thought process. Knowing that you understand how to reason about a problem is far more valuable to me 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 me. Do you have any idea how fantastically expensive it is to hire someone who refuses to ask for help when they are stuck? I have no time for a developer who fails to deliver because they pretended they had everything under control while being completely lost and floundering.
4. Represent your skills and experience honestly.
Having said all of the above, I also don’t want to mislead you. There is a threshold for questions and commentary. If you are asking me 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 we get to the whiteboard coding, make sure you’ve been honest in representing your skills and experience to me.
Part 2 — Coding on a Computer
Unlike the whiteboard, if I give you a computer and ask you to write code, I am testing how well you can code. More specifically, I am 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 my 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 I offer a challenge like this in an interview, the first thing I’m looking for is whether or not you ask me any questions. As I 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” (I would always say “yes”) then you have a HUGE advantage.
Good questions for this particular challenge would be:
- “For the purposes of this exercise, should an empty string be considered valid input?”
- “Do I need to handle unicode characters?”
The next thing I’m looking for is how well you can follow instructions. For example, I specified a string input parameter and a Boolean output parameter. Is that what you delivered?
After that, I 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).
Next, I 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:
- Runs fast.
- Doesn’t take up more memory than it needs to.
- Is stable and easy to maintain.
You should understand that #3 sometimes means small sacrifices to #1 and #2.
On this particular challenge, I am 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, I 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. I 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.
I use this test on all levels of developers, but my criteria is stricter the more senior I 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, I expect that I’ll be able to train you up.
For an intermediate dev, I want to see some comments in there and good coding style. I want to see an efficient solution and hopefully a test case.
Obviously, there are other ways to write a passing answer, but that should give you an idea.
If I give you a challenge to take home, my expectations are even higher. If you get a week to code something with full access to Google, etc… There’s no excuse for giving me 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. Personally, I think that’s just a giant waste of time. It’s far more important to me that you 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 I give you, there are things you can do to stay in the running for the job.
1. Don’t give up too easily
Make sure I see that 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, I 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 I 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 for me 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 me you’d ask for help, tell me who you would ask (the role) and what you would ask them (the specific question, if possible). If you tell me you’d search online, tell me exactly what search strings you would use. In this scenario, you really need to go out of your way to conivince me that you could solve the problem if you were actually working for me.
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.
You can get it here.