Don't Stress Out, Geek Out: How to Pass a Technical Interview

For developers on the job market, the technical interview is often a dreaded boogeyman. As someone who has been on both sides of the table, I can tell you that you can learn how to pass a technical interview by going from stressing out to geeking out. As the great Bill Walsh, head coach of the San Francisco 49-ers, once said—

When you prepare for everything, you’re ready for anything.

[bctt tweet="Don't Stress Out, Geek Out: How to Pass a Technical Interview, by @JohnnyC115" username="StartupInst"]

How to Pass a Technical Interview:

It’s about the Journey, Not the Destination

It’s important to remember during a coding interview that the answer is secondary to the process. We interviewers are looking to see how you approach problems.

First and foremost, we’re judging your ability to listen carefully and pull out the pertinent details. On the job you’ll get feature requests or bug reports and you’ll be expected to turn those into code. The best way to exhibit your ability in this area is to walk the interviewer through the problem in your own words and ask clarifying questions. This also turns the interview into a conversation, which can take some of the stress out of the situation.

It’s important during this walk-through that you also check all your assumptions and explain why you made them. This shows a solid understanding of the problem and any possible edge cases. Additionally, asking questions such as “Can I assume every character is a letter or might there be numeric ones?” can really shrink the scope of the solution you need to implement.

[bctt tweet="In a #TechnicalInterview, the answer is secondary to the process, says @JohnnyC115 #softwarejobs" username="StartupInst"]

Keep it Simple

Once you understand the problem you're trying to solve, always begin with an example. This will help you code up your solution as well as talk your interviewer through your logic. If you’re asked to write a method that determines if a string is a palindrome, step one is to write “tacocat” on the board as your example. Have a little fun with your examples; remember that while I’m testing to see if you're a competent developer, I also have to like you before I recommend you for my team.

Once you have your example, brute force a solution. This solution can be dirty and inefficient, no one writes perfect code the first time. Start by getting something working for your example. Once you’ve completed that, you can go back and refactor for edge cases and performance. This is what real-world coding looks like, so why should an interview be any different?

The most important thing to remember during this part of the process is to not get into your head. All your thinking should be out loud. This is the interviewing equivalent of the middle school “show your work” rule. Remember, I can’t read your mind so you only get credit for the things you say out loud.

[bctt tweet="No one can read your mind. Think out loud in your #codinginterview, says @JohnnyC115" username="StartupInst"]

The Devil is in the Details

Once you have a working example, it's good practice to step back and look at it critically. There are always opportunities to make the code more efficient, more readable or to handle a funky edge case. As developers, we are constantly looking at existing code critically for improvement. Taking the opportunity to improve your code in the interview shows me that you understand the difference between a working solution and an elegant one.

As the interviewer, I’m also going to review your code and ask leading questions about the decisions you made and any areas for improvement. It's important to relax during this portion of the interview. It's easy to get nervous and potentially defensive. Remember, this isn’t about your answer being right or wrong, I’m testing your ability to take feedback. Use this as an opportunity to learn from another developer. A developer who is able to talk through their solution with me, take feedback and come up with improvements is going to score major points.

[bctt tweet="In a #codinginterview, probing questions test your ability to take feedback— @JohnnyC115" username="StartupInst"]

It’s a Trap

As long as you're writing real code and not pseudo-code, most interviewers won't care which language you choose to implement your solution in.  While they aren’t likely to ding you for a missing semi-colon or other small syntactic errors (you are on a whiteboard after all), your language choice can actually hurt you.

By choosing a language in a technical interview, you're proclaiming that this is the language you're most familiar with. If that is the case, I would expect you to know the ins and outs of that language. For example, if you choose Python during your interview but use a loop instead of a list comprehension, I’m going to make assumptions about your level of technical depth. You should practice with the language you will use in interviews. Take time to learn what separates it from other languages.

If you're asked to use a specific language in an interview (they may need a Ruby engineer and want to make sure you are proficient), be upfront about your skill level with the language.

[bctt tweet="Learn the ins and outs of the language you'll use in the #codinginterview —@JohnnyC115" username="StartupInst"]

We’re Talking About Practice

Doing well in technical interviews requires practice. Don Hutson, one of the greatest receivers in NFL history, said it best—

For every pass I caught in a game, I caught a thousand in practice.

Spending time thinking about and solving the types of problems presented in technical interviews will not only improve your problem-solving ability, it'll also give you the confidence to nail them under pressure.

The book Cracking the Coding Interview by Gayle Laakmann McDowell is a great resource for this. The book is packed with practice problems of all types. Try working through some of them; can you create an example and brute force a solution?

The other resource I recommend is Glassdoor. Look up the types of companies you want to work for and read the reviews left by people who interviewed. They will often discuss the types of questions they were asked which will give you some insights to help you prepare.

Let Your Inner Geek Shine

There is No One Alive Who is You-er than You

—Dr. Seuss

My final piece of advice is to be you. It's easy to feel the pressure that comes with the scrutiny of an interview and clam up. Don’t forget that your interviewer is trying to determine if they can interact with you five days a week as well as whether you can do the job. Culture fit is important, especially in startups, and the technical interview mimics on-the-job interactions. Geek out a little and have fun.[bctt tweet="Let your inner geek shine in your #technicalinterview. #Culturefit matters, says @JohnnyC115" username="StartupInst"]

Photo credit: Alessandro Valli