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
- Andrew Munn: How to Land an Internship at a Top Tier Software Company
- Steve Yegge: Get that job at Google
- Palantir: Getting Hired
- Joel Spolsky: Guerrilla Guide to Interviewing
- Neil Roseman: The Anatomy of the Perfect Technical Interview
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!
