7 tips to ace a programming interview

1) Take a few minutes.

Speaking as an interview coach, this is one misstep that I see all the time during mock interviews. The canonical tip that everyone gives is, “talk more!”. What most of those well-meaning advice-givers overlook, however, is that talking and thinking at the same time is extremely hard. Nervous interviewees will jump straight into talking, passing up a great opportunity for concentrated thought.

Don’t waste precious minutes trying to fill the silence by saying everything you’re thinking, while simultaneously trying to solve the problem in your head.

Instead, wait until the interviewer is done explaining the problem. Ask any clarifying questions, and then tell your interviewer:

“Okay, got it. If it’s okay with you, I’m just going to take a minute or two here and think about the problem, and then I’ll start talking.”

Shut your eyes, stare at the ceiling, scribble on the whiteboard — whatever it takes. Think through the basics of the problem, and decide on an approach. Then re-engage the interviewer, and let him know what you’ve concluded. Don’t forget to provide your reasoning!

2) Write down the steps of the solution.

Even after you have an idea of how to attack the problem, don’t start writing code down. Write down the general steps of how you will solve it on one side of the whiteboard, where it’s visible but won’t get in the way. You don’t need to be verbose, just get the steps in order and somewhat readable.

Write pseudocode first.

Time to write code? Nope. Take a “dry run” at writing the code by writing some pseudocode. Often we run into problems halfway through writing the code, and there’s no point wasting time over syntax when you might have to throw the code away. Instead, write some half-baked code-looking stuff that lays out the structure of how your code will work. Do it over on the side of the whiteboard, so you have space left to work.

4) Don’t sweat the small stuff.

Programming interviews are not about how well you’ve remembered your semicolons, nor are they about being able to remember all of the flags on a TCP packet. They’re about demonstrating depth and breadth of knowledge, personality strengths, and problem-solving abilities. If you make a mistake, it’s okay. Brush it off and move on.

If you can’t remember something like this, it’s often acceptable to say that you’d look it up.

“…and here, I’d use whatever the list.contains() equivalent is in JavaScript. I know it’s not contains, but I can’t remember the method name right now, so we’ll call it contains() for now and I’d look it up right now if I were coding this.”

Let’s be honest, half of being a programmer is knowing how to Google stuff and how to interpret search results. We use the internet as a giant cache for all the information that we “almost” remember but don’t bother to, since we can just look it up at any time. It’d be hard to fault an answer like the one above. So don’t waste time memorizing keywords in your interview prep. Focus on the big picture.

5) Sit down. Be humble.

A programming interview isn’t just a written exam. It’s an assessment of your programming abilities, and there are plenty of things that fall into that category beyond mere coding prowess. For example:

• Are you able to express your ideas and solutions clearly and effectively?
• Do you treat the interviewer with respect?
• How do you accept criticism (technical, constructive or otherwise)?
• Are you able to collaborate with others to come up with solutions?
• Do you communicate in a way that demonstrates empathy?
• Are you honest (especially about yourself)?

6) Come prepared.

When it comes to programming interviews, there is no substitute for HOBIS (which stands for Hours of Butt-In-Seat). If you want to be ready, you have to put in the time. It’s important in order to maximize your chances of acing the interview, but it’s also important for your peace of mind during the interview and afterwards. In the interview, knowing that you’ve done all you can to prepare helps you stay calm and cool, and increases your chances of success. And afterwards, regardless of the outcome, knowing that you could not have reasonably done more to prepare helps you feel proud of your work and start moving towards your next goal.

7) Review your work.

You won’t always finish questions in the time permitted, but occasionally you’ll have extra time after coming up with a solution. If this happens, it’s tempting to say “Well, I’m done!”. Interviews are stressful and we want them to be over as fast as possible. This is reasonable, but:

Think about how silly you look if your solution is not right.

Instead, if you have the time, review your code as you would in a peer review. Show the interviewer that you are committed to producing accurate, high-quality work, and that they can trust you to do so without being prompted.