How to Hack a Coding Interview

In general, tech interviews in many top software companies have their specific format and one needs to prepare for it. Even if you are technically strong, you may need a bit of getting used to the form. In many cases, you need to write code on a whiteboard. Time is limited, like 30–40 minutes to solve and code a problem. It may be even less sometimes.

Here are some practical tips to hack that coding interview:

1.Practice using the same medium (e.g., paper and pencil) and time limits (e.g., 30 minutes) as the real interview.

Google and Microsoft both use whiteboard coding questions, yet often candidates practice by coding alone at home on a computer with a compiler. During the actual interview, they stand at the whiteboard and forget how to initialize an array, without their trusty syntax highlighter. Or they are so nervous having another person watch them that they panic and can’t think straight.

In real life, if you plan to swim the English Channel, would you limit your practice to laps at the local swimming pool? No, you would go test out the ocean waves, the salt water. Do the same here.

Ask your recruiter the format of the interview and any coding questions. If the company gives the candidates an hour alone in a room with an editor and no compiler, practice that at home. If the company does whiteboard questions with an interviewer watching you, ask an engineer friend to be your mock interviewer. It’s okay if the friend is a less experienced engineer than you — they’ll still bring out your nervousness about making mistakes in front of others so you can practice getting used to that.

2. During the interview, don’t obsess over little mistakes that happen.

On more than one occasion, when a star candidate got a coding question, he zeroed in on the most optimally performant solution, identified the boundary cases, and began writing well-designed code. Midway through the problem, he makes a little error — getting the order of operations wrong on the first try, or having an off-by-1 mistake, or forgetting to declare a variable.

When the mistake is pointed out, the candidate responds with horror and then becomes so nervous that it impacts his performance during the rest of the interview.

The fear is unfounded. An excellent candidate making a little error is like a concert violinist playing a challenging Brahms concerto and hitting two wrong notes. Sure, the audience could tell that he made mistakes, but they don’t get confused as to whether he’s actually at Twinkle-Twinkle-Little-Star level.

Even if you ultimately bomb one question, many interviewers ask you multiple questions and will forgive a single mishap. Even bombing an entire interview is recoverable if the other interviews go well.

A former Google colleague once interviewed a candidate and was very curt because he found the candidate’s communication style irritating. The candidate proved himself during the interview, and the tech lead ended up being the most influential proponent of this candidate. He advocated harder for that candidate than he has for anyone else in a year.

When things don’t go well, just keep at it and don’t give up hope.

3. Don’t hijack the interview.

Don’t be that type of candidate who came into the interview with the mindset that they MUST tell all about their recent project Zoolander. It’s like you start the meeting and you break in with, “I want to tell you about Zoolander. 10 years ago, this project started as a side feature…” and then go on for 5 minutes without taking a breath.

Sometimes they decide that they must tell every interviewer about Zoolander, repeating the same description over and over during the day.

Your interviewer has specific questions that they need to get through. If you hijack the interview, they may not have enough data from their own questions to be able to endorse your hiring. They may also think that you would be challenging to work with.

If you really want to talk about a project, ask your interviewer, “I think project Zoolander really shows off my abilities. Can you or another interviewer fit in 10 minutes for me to explain it?” The interviewer can then refit their plan for the interview, instead of suddenly having their schedule be shanghaied.

4. When answering questions expecting a specific answer, give a high-level summary first.

Sometimes you will be expected for a short answer, “How many people worked with you on project Zoolander?” The candidate then gives an audiobook, “Well, there was Jimmy — he did the UI, and I had to mentor him quite a bit on it. Then there was Mary who ran the backend servers. She worked remotely from Pennsylvania. Two years later, we got another backend person David…”

Three minutes later, the candidate is still talking, and you even don’t know the answer to how many people worked on the project.

Give an answer first, and then expand. “There were 3 when I joined, and 12 when I left. First, there was Jimmy …”

5. Techniques for technical questions:

• The first hurdle is that you should NOT jump the gun and begin coding until: (1) you are confident that the route you are planning to take will solve all or most of the problem and not just the first few lines of it; and (2) you have resolved any apparent ambiguities needed to solve the problem. If you start coding before completing this first step, it will come off as a red flag to the interviewer.
• If you know of a prominent brute force solution and only have a hazy idea about a possibly better solution, start with the brute force solution and explain to the interviewer that you’re starting with a simple brute force approach and will see if you can improve it after you have something working. Something is better than nothing, and incrementally improving your code will suggest you have a transparent, algorithmic thought process.
• You must speak clearly and calmly and keep talking to let the interviewer know what you’re thinking, where you’re going, and what problems you’re encountering.
• Always listen to an interviewer’s hints.
• If you’re unsure about a specific function or feature of the language you’re using that isn’t common knowledge, ask the interviewer if you can assume that a particular functionality exists and behaves in a certain way. Often the interviewer will allow you to make that assumption (even if it doesn’t exist) with little or no penalty.
• If you get stuck, tell the interviewer you are stuck and explain why.
• When you are done, DO NOT worry about taking too long to test your code for correctness unless the interviewer CLEARLY indicates your solution is correct. The interviewer will usually only give you one chance to check for accuracy.