How to do better in a technical interview? Part 2: problem solving

6 tips to get better results solving problems for a technical interview

Why solve a problem?

In this previous post, I have described the interview where you are asked to talk about a past project and discuss your role in it. This interview is very good at revealing your ambitions and attitude at work. However, your prospective employer would also like to know if you know your stuff, i.e. can solve a problem through code. This is sometimes refer to as the coding interview, to be distinguished from the system design interview which is more about drawing boxes and hand-wavy discussions about scale and performance.

We tend to ask candidates solve simple problems for the coding interview. There are two different flavors of them, each focused on a different concern, but they are pretty much the same in nature. They are less like CS-heavy problems you would get in a typical Google interview, instead, problems you would find in your day-to-day job. We typically give you the problem statement and let you implement it in your own language and in your own IDE.

A hypothetical example

As a hypothetical example, we would perhaps want you to implement an analytics API that takes a certain input and stores it somewhere, allowing you to provide a few different reports out of the data you have stored.

We expect you to be able to write code for solving these problems in a 60-minute interview (actually about 50 minutes, if you deduct the beginning intro and time for questions at the end), and this is the key here. We would expect to see a working solution, no matter how rudimentary, have a discussion about possible alternatives, take it to the next level with new requirements, and change the solution to adapt. It’s not the final solution that we are after, it has never been the point. This is all about seeing you clarify the problem, challenge the requirements, discuss alternatives, work with us for the solution, and respond to change. We need to make sure not only you solve the right problem, but you also solve it right with the given requirements and constraints.

Here is the thing: If you want all of that to take place, you would need to spend only half the time you have, roughly, getting the very first version of your solution to run. It is not very hard, if you have a reasonable approach and avoid some common mistakes along the way.

The 6 tips

Here are ways to avoid some of the most common ones I have seen:

• Pick your tools wisely: Do yourself a favor and pick a language you are most comfortable with. This is not the time to show off the cool language you recently picked up. We really mean it if we say pick any language you want. There is no point given or taken based on that. We hate to see you get stuck on some stupid language-specific issue. Time fighting the cool programming language is the time not spent on valuable conversations.
• Ask questions: Clarify the problem you are solving, and why it is important. The problem statement is usually vague, and something is certainly lost in translation. What you think you are solving is most likely not the thing that the interviewer has in mind.
• Communicate your thoughts: Don’t just go into your cave for minutes, coming back with a solution. Communicate with your interviewer and present them with options. Ask them questions about constraints and goals that will help you chose the right solution. Everything being equal, use the simplest approach. In the example given here, it is important to know how much data we are dealing with, which fields will be used to query the data, etc. You should decide whether to (can you even) store the raw data, or aggregate data as you go.
• Don’t over-engineer: Avoid over-engineering like the plague. Don’t write anything that won’t be used during the interview, just don’t. Once the interview is over, your code is in the bin. Don’t invest in its flexibility and future extensibility (unless explicitly asked). As a rule of thumb, if you are writing a class that has these words in it, you are probably over-engineering it: manager, facade, factory, config, you get the idea. As another rule of thumb, if your code doesn’t fit nicely in a single screen, you probably have too much boilerplate.
• Start simple and iterate: Start dead simple and get a running code as fast as you can. How else you can get the first version of a working code out in 20 or so minutes? In the example given here, start by storing data in an in-memory data structure. If you are thinking about bringing in a cache or a DB layer, you are probably solving the wrong problem. You can always add that later, if asked.
• Test effectively: Think about testing your code, and test it as you go. As you change your approach and incorporate new requirements, it is important for you to have a way to quickly test your code to make sure it works as expected. Don’t spend a lot of time writing an extensive test suite. A main method is most likely enough, as long as you can very quickly add a new test case. Also, don’t destroy old test cases when adding new ones.

These tips won’t make you win if you don’t know your stuff, but I hope they help you get the most out of the interview time to better communicate your skills and experience. Good luck!