Part 1: The Anatomy of a Technical Interview

Mar 16, 2014

Over the past few years, I have interviewed at tech companies such as Google, Facebook, Palantir, Dropbox, and Zynga. This has given me a reasonable perspective on what to expect during the interview process. If you’re someone who wants to understand how technical interviews in software engineering work, read on.

This article covers how to approach a technical question and is the first installment in a three-part series. I’ve also written targeted articles for how to approach phone interviews and on-site interviews, which form parts 2 and 3, respectively.

How the challenge is presented

The interviewer will give you one to three questions (enough to fill 30-60 minutes), each of which usually falls into one of three categories:

Coding. This type of challenge tests your ability to write clean, readable, and correct code (usually in a programming language of your choice) to answer the questions. Additionally, you will often need to devise an algorithm (usually based around well-known algorithms and data structures) to solve the problem before coding it.
Decomposition. This type of challenge tests your ability to break down a large problem into smaller sub-problems which are easier to solve.
Non-technical explanation. This type of challenge tests your communication skills and ability to explain a technical concept to someone with no relevant background.

What to do a week before the interview

Review computer science fundamentals.

Have a solid grasp on common interview topics, which are generally in the realm of data structures and algorithms. However, in my experience, these topics appear more often than others:

Object-oriented programming: classes, interfaces, constructors, methods, inheritance, polymorphism
Algorithmic thinking: brute force, greedy, divide and conquer, recursion and recurrence relations, dynamic programming
Sorting: bubble, selection, insertion, merge, quick, heap, bucket, counting, radix
Computational complexity (time and space) and Big O notation
Hash tables: hash functions, advantages of hashing, collisions
Trees/graphs: binary search, breadth-first search, depth-first search, in/pre/post-order traversal
Stacks and queues: implementation, LIFO vs FIFO
Linked lists: implementation, applications
String manipulation: regular expressions, reversing a string, obtaining a substring
Bit manipulation: AND, NOT, OR, XOR, shifting

Know one or two languages well.

You’re often given the choice to interview in the language of your choice. For near-complete coverage, know languages specializing in:

Object-oriented programming (e.g., Java, C++)
Scripting (e.g., Python, Perl)
Functional programming (e.g., Haskell, Scala)

Practice interview questions.

Ideally, grab a friend who can ask you some questions, and work through the code/problem together. More practically, see the “Additional Resources” section at the bottom for places to find interview questions.

What to do a few days before the interview

Research the company.

Find out their mission and engineering culture. You will demonstrate that you’re not just doing the interview because they offered it to you. This will also give you a good sense of whether the company aligns with your values.

Find 1-2 interesting projects in the company.

If the interviewer asks you why you want to work there, you have some solid examples to back your case.

Have questions ready for the interviewer.

Use the wrap-up and Q&A to your advantage to learn more about the company! You can use your conversation during the interview as a springboard if something interesting pops out to you. Some questions I keep in reserve are:

Why did you decide to join X?
What’s the best thing about working at X?
What’s the worst thing about working at X?
What team do you work on at X?
What makes working at X unique?
What do you think of the culture at X?

What to do 20 minutes before the interview

Relax.

Get comfortable, take a deep breath, smile, and maintain good posture. These will shine through in your voice during the interview!

What to do during the interview

Maintain a friendly tone.

Stay confident and upbeat throughout, and establish a comfortable rapport with your interviewer. An awkward interview is probably a bad interview.

Know that interviewing is a two-way street.

Even though they’re asking you questions, if anything is unclear or you want more information, you should ask. In many cases, something will be revealed which can make the problem easier to solve.

Talk through your approach while you’re implementing.

The solution is not as important as the process. You don’t want to just spit out the code like a machine. The crucial part of an interview is demonstrating your problem-solving ability through this particular challenge.

If you’re stuck, don’t shut up.

Keep talking and say what you’re thinking. If you’ve really run into a wall, you can ask for help/clarification or even try different approaches. Note that this is different from continuously talking for no reason. Taking a moment to compose your thoughts will be valued by the interpreter; idle silence will not.

If you’ve seen a question before, tell them immediately.

Nothing strange here, it’s just the honest thing to do.

If you have no idea what the question is asking, tell them immediately.

Your interviewer may be most comfortable in an area which you have no knowledge. That’s all right; make that known, and they can give you a more targeted question.

Additional Resources

Here are some resources I found invaluable in understanding the interview process, end-to-end. This list is by no means exhaustive, but rather a good place to start. Within each section, I’ve ranked the links in order of how vital they were to me when I was interviewing.

Process and Approach to Interviews

Questions and Concepts

Special thanks to Waseem Ahmad, Nathan Alison, Satej Soman, and Toshi Noguchi for feedback on early versions of this series.

Have any thoughts on how to approach software engineering technical questions? Tell me!