### BLOG

#### The Technical Interview

Simon Woo

on November 07, 2015 at 11:06 AM

At SimonComputing, we perform coding interviews for people who are applying for coding jobs. This is an opportunity to see how you handle problem solving situations. It is an opportunity to have a conversation around a particular problem. We won't be asking you esoteric or trick questions.

Coding interviews are not a perfect tool for evaluating candidates. They can be intimidating and not everyone will do well. There is a chance that good candidates are rejected. Writing code on a white board in front of one or more interviewers is a completely different situation from being at your desk with your computer. But for most companies, it is the best way to assess coding ability within the time and limitations of an interview process.

Practice can dramatically improve your ability to show the interviewers what your capable of.

Practice doesn't mean just cracking open an algorithm book and working it through your computer. It means standing up to a white board and solving the problems without the help of the computer and preferably with the help of a friend that acts as the interviewer. For the practice to have real value, you've got to simulate the circumstance as closely as you can so that the situation stops being novel. Once that happens, you are more likely to get into the flow of solving the problem quickly in the interview.

There are many web sites with practice problems. Most interviews will not get into things like implement a quick sort. It will be more about solving problems you haven't seen before, and simple enough that it could be solved in 15-30 minutes.

## Listen to the Problem Statement

When the interviewer gives you a problem, listen and take notes on the problem that is being stated. Often they will give you specific details that they anticipate you'll need on the problem. They'll give you assumptions like "the input array is guaranteed to have at least one value". The structure of the input data will also be clues to how you might optimize the solution such as recieving the data in a hashtable or sorted list. These may be clues to potential optimizations you could perform.

## Confirm the Problem Statement

Make sure you understand the problem being stated by reciting it back to the interview. This is very important because you don't want to be 20 minutes into your code only to have both you and the interviewer realize you've been solving the wrong problem. Doing this also shows that you make an effort to understand what was said and likely give you points for communication skills.

Ask for any clarifications that you need to solve the problem.

## Think Through the Problem

Before jumping into the code, draw the problem on the board, and do it at enough detail that you can cover both happy paths and edge case paths through the problem. This is very important because seeing the problem on the board will give you a way to visualize and solve the problem. Instead of focusing on how you would code it, think about how you would solve the problem without a computer.

Talk through the problem as you go so the interviewer has insight into your strategy. If you're headed the wrong way or have a misunderstanding, they may give you some tips to put you on the right path.

Translate the steps you would do into code. If your solution can't be translated to code, your probably using something inherently sophisticated like pattern recognition in the process. You'll need to think of alternative solutions.

## Solve It First

This point cannot be emphasized enough:

Solve the problem in the simplest most direct way first and **just get it done**, even if it is inefficient. It shows that you understand the simple and obvious solution.

Often that is good enough in real life. It is easy to read and further optimization may only result in a few milliseconds. Your brain power is better used on solving bigger problems.

## Then Optimize

In a real life scenario, you only want to optimize if it gives you significant advantage for the effort it takes. For the technical interview, you should move on to consider how you can optimize your code. The exercise of your first attempt may already have inspired some ideas to improve the code. It may be helpful to ask whether they want you to optimize for space or time efficiency. You should also look for opportunities to improve readability of your code.

Unfortunately, there are too many different potential scenarios to give you a single answer for optimization. This will be up to you and the practice you put into it.

## A Note on Recursion

A common response to all of our problems has been an immediate jump to "The Recursive Solution". It doesn't seem to matter what the problem is, there is a large percentage of people that jump to the conclusion that we are giving them a recursion problem.

Recursion to a coder is like a gun to a police man. It's an important tool to have mastery of, but you rarely want to pull it out as the first way to solve a problem! Recursion has it's place where it can solve certain problems very efficiently and elegantly. But it can also be overly complex, slow and susceptable to stack overflows when applied to the wrong problem. Use it judiciously.

## Parting Notes

There are many resources on the internet to practice problems in preparation for your interview. One that we like is exercism.io. It let's you work through problems in the language of your choice and will allow you to see multiple solutions from other users. This can be fun to see what clever ways people have used to solve the problems you've worked on. This feature can accelerate your ability to come up with elegant solutions. The practice time is time well spent as it will help you work better after the interview as well.

In the end, it's just a series of puzzles to solve. Make it fun.