Interviewing Tips

There is a lot of information on how to do well in tech interviews out there. Some of it is good and some of it is bad. Here are a few of the interviewing tips I’ve picked up over the years.

Act like you are having fun

This is first because it is the hardest. Most people don’t enjoy interviews. There are many reasons to hate interviewing (from both sides). Simplistically interviews are a high stakes blind date set up by someone who doesn’t know you and where rejection is a likely outcome. Ugh. It is no wonder that folks don’t do their best thinking in this setting.

Try to make the experience less painful by having fun. Find something about the experience that you can think about positively. Maybe you’ll get a good lunch. Maybe you’ll meet some interesting people. Maybe you’ll get to do a new brainteaser. Maybe you’ll get to talk about a cool conference you attended recently. Maybe the person interviewing you has a hilarious sticker on their laptop. Whatever it is, find some reason to have fun. Companies want employees who want to work for them. By having fun, smiling, or just not dreading the experience you communicate that you want to be there.

So what if you are sick or just can’t find a way to make it fun? Fake it. When I interview, my smiles and jokes are often forced initially. I’m usually too nervous to actually relax and be social until I’ve been there an hour or two. So I fake it. I smile. I chuckle. I act attentive even when I’m fretting inside. I don’t think there is anything wrong with faking it until you find something to enjoy about the process.

Repeat the question

Some folks struggle with coding questions. The most common mistake I see isn’t technical; it is simply answering the wrong question. It happens for a lot of reasons. Sometimes the question is bad or the interviewer explains it poorly. Sometimes the candidate mishears the question or assumes it is like another question they’ve been asked. A good interviewer will quickly notice that someone is headed down the wrong path and politely redirect but you shouldn’t count on it.

The easiest way to avoid answering the wrong question is repeating or rephrasing the question before starting. When I interview, I often make a notes on the whiteboard as I rephrase the question. If I get confused later, I refer back to my notes. If you feel silly just repeating the question you can achieve the same thing by writing down a couple example input/output pairs and having the interviewer verify they are correct. This technique also has the benefit of being the whiteboard coding equivalent of TDD.

Finally, repeating the question buys you a chance to breathe and think before diving into whiteboard code. When I’ve stumbled on questions it usually happens because I dive right in without thinking first. Taking 30 - 90 seconds to get your head around the problem before you start writing helps a lot.

Ask for clarification

When I ask a coding question I often give a simple but incomplete specification. I do this for a few reasons. First, discussing all the edge cases up front is confusing. Second, we often run out of time before we get to the edge cases. Most importantly though, an incomplete specification is reality in software and I want to see how the candidate handles ambiguity. Someone who can recognize common edge cases and failure points is a more valuable team member than someone who always implements exactly to spec.

For example, I might say, “Please write a function that increments a string. ‘aaa’ should become ‘aab’.” I expect most candidates will eventually ask about handling ‘z’. Many will also ask about capital vs lowercase letters. Some will ask about string lengths and handling the empty string. The people who ask these types of questions are the people I want as teammates.

If you get asked a coding question that seems under specified it probably is. It is okay (and expected) to ask clarifying questions. If it helps, treat the interviewer like a PM or customer and try to collaborate with them on the problem. Trust me, this is what a good interviewer expects you to do.

Admit weakness and embrace humility

No one expects you to be perfect. (If they do you probably don’t want the job.) If you get asked a question that you can’t answer, the correct response is “I don’t know, but here is how I’d find out…”. Another variation is “I’m not sure but here’s what I remember…” I hate recommending canned answers but there aren’t many good ways to handle this situation. Making something up is bad and “I don’t know” alone is conversationally awkward. “I don’t know” followed by a few relevant sentences seems to work best.

Another part of not being perfect is knowing your strengths and weaknesses. “What is your biggest weakness?” is a trite question but you’ll probably be asked it at least once in your career. A good answer is one that doesn’t sound arrogant and also isn’t a humble brag. The pattern of “I struggle with X and I’m doing Y to improve” is a great place to start.

Finally, if you aren’t perfect and your interviewers aren’t perfect it is possible (or likely) that one of you will make a mistake. If this happens don’t argue with your interviewer. This is a “right vs effective” moment. In this situation it is more effective to politely accept correction (or politely disagree) and move on as quickly as possible. You are there to show off your technical skills and winning attitude. A focus on being right just gets in the way.

Don’t memorize

The last tip I give folks is to not memorize tons of questions/algorithms/etc. Most companies have stopped using the old standard questions with answers that are easy to find online. Memorizing these is a waste of time. Spend the time you would have spent memorizing learning how to do big O analysis and writing code. Focus on learning your languages’ numeric, string, and collections libraries well since most interview questions will use at least one of these.

But what if a company does use a question from an interviewing site or book? Even then the interviewer will learn more by watching you work through the problem in real time. Listening as you discuss your solution and asking questions about design decisions helps an interviewer learn how you communicate, which is vital information. Remember, the interviewer is trying to answer two questions: “Can this person do the job?” and “Am I willing to work with this person?”. Reciting memorized answers makes it harder for the interviewer to answer those two questions well.

Closing thoughts

If you don’t remember anything else from this post remember that interviewers and companies want you to do well. Interviewing is expensive for a company. It takes time and randomizes employees. If you have an on-site interview it is safe to assume the company would like to say, “here is your offer letter”. They want you to succeed so they can stop interviewing and get back to making cool things. For me, at least, coming into an interview knowing that everyone wants me to do well is usually enough for me to actually do well. Hopefully the same is true for you.