Larry Davis is a computer scientist from Adobe and an instructor at Hack Reactor, a San Francisco coding academy.
Tech interviews aren’t easy. If you walk in unprepared, an interview can feel like a battery of convoluted questions and obscure puzzles designed to blindside you. It’s tough, but the guy asking the questions did well enough to get hired, and there’s no reason why you can’t do better. Here’s how.
You wouldn’t walk into battle unarmed, so you shouldn’t walk into an interview without doing a little intelligence gathering.
Become a spy
When I interviewed at Amazon for a front-end role on the Cloud Player team, I was able to get an edge by signing up for the service and examining the source code. I saw they were using the revealing module pattern, solving an infinite scrolling problem using a clever technique. I was even able to get insight into their variable naming conventions. When it came time to whiteboard, I was asked about the infinite scrolling problem, and the code I wrote on the board used the same design patterns and naming conventions as their production code. It was déjà vu for the interviewer, and you bet I got the offer.
Take advantage of openness
Take a look at the company’s Github page. If they’ve released any open-source software, familiarize yourself with the problems it solves, as well as the design patterns, conventions, and coding styles it uses.
If you’re feeling really ambitious, fork the repository, fix some issues, and submit a pull request. When you sit down for the interview, you’ll already be part of the team.
Note the authors of recent commits — there’s a possibility they’ll be the ones interviewing you. View their profiles, find out about their other projects, and note any clever code they wrote that might be brought up during the interview.
Study the usual suspects
Even if you’re interviewing for a front-end role, at least one interviewer is going to ask you to implement merge sort, reverse an array in place, and write a recursive binary search algorithm. If you can’t quickly bang out the usual suspects, you’ll likely end up with a few “no hire” votes from members of the team that are disciplined in computer science. These are easy problems to master, so spend some time running through them before you go in.
You should spend an hour a day for at least a week practicing these kinds of toy problems. When you walk in on the day of the interview, you’ll have increased confidence and will be in the right state of mind to solve data structure and algorithm-oriented problems.
It’s time. You’ve put on your Sunday best, and you’re ready to run the gauntlet. Take a deep breath and open your ears — those hours of preparation won’t pay off unless you listen carefully.
The answer lies within the question
Read into the interviewer’s question. Chances are, it has been revised many times to be as unambiguous as possible. In the process, the wording of the question practically contains the answer. Ask them to repeat it, then write it down in short form and ponder it.
When you get stuck, let the exact wording of the question echo in your head. The answer may become obvious.
It’s never as simple or complex as you think it is
You listened to the question and immediately came up with a super simple answer. But it’s too simple, and now you’re wasting brain cycles second-guessing yourself before speaking. Instead, you should say your simple answer out loud, but preface it with “the first solution that comes to mind is” and follow it with an analysis of potential shortcomings. Through that process, you’ll either nail it in record time or find your simple solution misses half of the problem.
Work within the constraints
You need to think about the constraints put forth, the language you’re coding in, and the properties of the data structures and algorithms involved.
If the interviewer says “stack,” you need to think about what you know about stacks:
- Push and pop
- First in, last out
Then think about how you can exploit those properties to solve the problem at hand.
Draw a diagram
We’re visual and physical creatures; we solve problems better when we have something that we can look at and touch. Drawing a diagram can help you find a solution faster by using your entire brain.
Draw the data structure and step through the algorithm, modifying your diagram and talking out loud about what is happening. Through this, your answer can become self-evident.
Be the parser & think out loud
Read each line after you write it. Parse it. Dereference the variables you use. Evaluate the expressions. Through this process, you’ll catch simple mistakes before the interviewer does.
When you finish a section, explain what it does. This helps the interviewer follow your thought process and can serve to evoke subtle hints if you’re going the wrong direction.
When your solution is complete, execute the code in your head. Step through it with a sample data set and explain how it works as you go. Point at your diagram, talk out loud, and make it clear that you know exactly how everything works. This shows you can both write code and talk about it, an invaluable skill when you it comes time to onboard future team members.
Putting it all together
I often ask the following question:
How would you implement a stack with push(), pop(), and a fast min() method?
You can implement push(), pop(), and min() however you like, but all three must be fast.
Analysis of constraints
The question puts forth a few constraints, and from those, you can draw a couple of conclusions right off the bat.
- It’s a stack
- Values will be added and removed in first-in, last-out order
- push() and pop() can be implemented “however you like”
- You’ll need to do something clever inside of them
- min() has to be fast
- You shouldn’t check every element in the stack when min() is called
- push() and pop() have to be fast
- You shouldn’t do anything complex inside of them
The first thing that comes to mind
Given you can do whatever you want inside of push(), the first thing that comes to mind is to store a variable, min, and with each push to the stack, compare the pushed value to the min value, updating min if it’s smaller.
This works perfectly until you call pop() and the popped value is the min, at which point you no longer know what the min is.
A diagram to the rescue
The data structure will be stack-like, so draw one. Start putting numbers in it, and call out what the min is at every step. Again, it’s a stack, so pop a few numbers off as well and note the min. Through this exercise, you might notice a pattern in the numbers that you call out as the minimum value.
Circle back to the constraints
The pattern you find respects the properties of a stack. It turns out you’ll need to keep track of the every minimum value in the order it was added to the stack. A data structure that works great for keeping track of things added in stack-order is, well, another stack.
With that in mind, the solution then falls easily into place. You’ll have no problem problem explaining it to the interviewer by pointing at your diagrams as you step through it.
After you’ve nailed the questions, the interview isn’t over. The last few minutes are your chance to impress the interviewer with insightful questions and show them your passion and excitement for the role.
Ask about the technology stack they’re using. Show you’re savvy by asking why they chose one component over it’s competitor, or better yet, use your knowledge of the company to put forth your own hypothesis.
If you found a common interest with the interviewer, take this opportunity to chat about it. Maybe you’re both avid mountain bikers, make you both worked for IBM previously — whatever it is, use it to create a connection with your future teammate.
Finally, close like you’re a salesman. Reiterate why you’re interested in the role and how your background fits it perfectly. Show your interest in the problems the company solves and that you’re exited about addressing them in your role.
Shake hands and walk out the door with confidence; you nailed it. And don’t forget your jacket.