I've found myself giving a bunch of advise on technical interviews lately and thought it'd make for a good blog post. While most of us acknowledge that technical interviews have a lot of false negatives, the industry as a whole hasn't come up with a better alternative. Here's my guide to surviving interviews.

Practice

This one seems obvious, but I need to say it up front. Practice, practice, practice. Proper planning prevents poor performance. I've personally done almost every problem in Cracking The Coding Interview and I can't recommend that book enough. It helps you get into the mindset of interviewing.

A big failure mode with this book though is how it's organized. The problems are all neatly organized by what tool you need to solve them. For example theres a chapter with array problems and a chapter with tree problems. Real interviews won't be like this. You'll have to identify what tools to use on the problem when it's given to you.

The advanced chapters in the back are really helpful here because they don't provide any context, they're just problems to solve.

Turn Your Inner Monologue Inside Out

This is so important. As an interviewer I need to get a sense of how you solve the problem. If you silently struggle, I can't give you the hint you need to succeed. Talk to yourself as you work through the practice problems. It may feel silly at first, but you need to practice saying out loud what's going through your head. Really say out loud everything going through your head.

Even say out loud the bad ideas and why they won't work. During the interview, I'm looking for signal, either positive or negative that we should hire you. If you mention something that won't work and why, that's really positive signal. It shows me that you can think through multiple solutions and know their tradeoffs.

It's also important to state your assumptions. Sometimes it might seem like you intuitively figured out a key part of the problem, but I need to verify that. Often if a candidate seems to just know something I'll ask some followup questions that seem really simple, just to confirm we're on the same page.

If You're Stuck, Make a Magic Function

This one took me years to learn. When you're stuck on part of a problem, for example you don't know how to sort something, or organize a data structure, just pretend you have a function that does it for you. You will need to implement that magic function later, but this will help you get unstuck for the time being.

In fact, this is really positive signal for me. It shows me you can break down the problem into multiple steps, and that you can write clean code. It's often difficult to parse giant single-function solutions.

Take a Deep Breath

During some interview somewhere, you'll probably get stuck and flustered. Don't go into panic mode. Getting stuck on a small part of the problem is totally okay, and expected. Take a deep breath and go back to the basics to wrap your head around it.

For on-sites, you'll often do several interviews back to back. Remember that each interview has no bearing on the next one. You can fail one interview, pass the rest, and that interview becomes an outlier. When you finish an interview put it in the past, and move onto the next one.

I'm Taking Notes

This is important. I take notes throughout the whole interview to make sure I'm giving a fair evaluation. Here's what they might look like.

5:06 PM Explained question
5:08 PM Candidate asked if they can assume a type of input, I say yes.
5:10 PM Candidate started writing error checking, i told them to assume it's valid input.
5:13 PM Candidate has the first part of the implementation.
5:14 PM Asked candidate to walk me through at a high level.
5:14 PM Candidates solution works like this ____________________
5:16 PM I asked what their data structure looks like.
5:18 PM They showed me they know what it looks like, now I can give them a sample input.
5:19 PM They're very caught up on this section. I'm asking them what would happen if they had a magic function to do it for them.
5:24 PM I asked what the code looks like for this simpler case.
5:29 PM Algo works for simple case, I told them I see a bug.
5:31 PM I told them "I would wager they could make this function work for the advanced case"
5:31 PM They figured out the advanced case.
5:35 PM There's a bug on line 33.
5:36 PM They found the bug on line 33 on their own.
5:40 PM I suggest a big scary edge case.
5:43 PM Candidate has a high level solution for edge case.
5:48 PM Candidate has implemented psuedocode around this.
5:53 PM We hit a good stopping point for questions.

These are intentionally vague, but it's encapsulates the things I need to remember:

1. How long did each part of the problem take the candidate?
2. When did they get stuck?
3. Were they able to figure it out the bugs on their own?

After doing the same question dozens (or sometimes hundreds) of times, I have a pretty good sense of how the interview should go, what types of solutions a candidate may have, and when they're likely to get stuck.

Be Honest

It's very likely at some point you'll be asked a question you've seen before. There are only so many interview questions out there. When this happens, tell the interviewer! I can usually tell if a candidate knows the question in advance and it feels like I'm being lied to. When this happens, I have to flag this suspicion and recommend we reinterview them.

It's a Numbers Game

Interviewing is it's own skill you need to hone; it can take years of practice. When I was going from my first to my second job I talked to 50 tech companies (and failed a lot of interviews). The more interviews you do, the better you'll get at it.

If you're just ramping up on a job search, consider scheduling the companies you're less excited about earlier. This will help you practice with less pressure. You'll feel more ready when you get to the interview you really care about.