Interviewing as a software engineer in a hyper competitive environment like Silicon Valley can be stressful or even terrifying. Many technology companies follow a similar format that includes technical interviews over the phone and on the Internet before more thorough onsite sessions. While non-technical skills are essential, the core competencies of software engineers at most levels are assessed through various types of problem solving in technical interviews. This article focuses on preparing for the most common technical interviews where software engineers solve problems by writing code.

In order to become more comfortable interviewing, first understand the purpose. It can be incredibly liberating to embrace your role in the hiring process.

From the perspective of a potential employer, the obvious goal of the interview is to select the right people to join their company. Hiring practices and how to define the right people vary widely between companies and are constantly evolving. Silicon Valley is home to countless startups and emerging companies, and not all interviewing processes are equal or even effective. Moreover, successful hiring practices often prioritize ensuring that the wrong people are not hired over not turning away any of the right people. Accept that hiring is a complex problem and companies choose not to extend offers for a variety of reasons. Most people will not receive offers most of the time but any understanding a company forms of you during an interview is incomplete and not a reflection of you or your abilities.

Considering the perspective of a company is important, but do not neglect your responsibilities as a candidate. Whether you’re exploring new possibilities casually, or extremely motivated to find your next role, your objective should not be to convince a company interviewing you to hire you. A company can’t hire you unless you also decide to move forward and it’s imperative you do your part in keeping that decision mutual. If you aren’t sure what to do to determine if a company is a good fit for you, look online or ask someone you respect for feedback. Does the company align with your core values? Will they be able to provide you with what you need at this point in your life and career? Learn about the company, job and people you would work with instead of just letting the interview happen to you. Above all, be yourself. If the company and role aren’t a good fit, you won’t be set up for success and that leads to unhappiness.

Whiteboard Etiquette

There is plenty of material available online that insists various aspects of technical interviewing are useless or a waste of time. I understand that any tool used ineffectively can seem useless but I believe strongly that there are clear ways to derive value from interviewing tools like the whiteboard. All arguments related to the relevance of technical interviews are out of scope of this document and anyone seeking a job as a software engineer can do little to avoid an interview situation where coding on a whiteboard is expected.

The most common venue for writing code during onsite technical interviews is the whiteboard. A whiteboard can be any erasable, upright surface where you write. During your work as a software engineer you may draw designs on a whiteboard, but it’s unlikely that you will ever use one to write code. During an interview, however, the whiteboard is an invaluable tool that allows a good interviewer to focus the interview quickly on the elements of the coding process that are most valuable. An Integrated Development Environment (IDE) will autocomplete, autoindent, provide boilerplate code, check for syntax, offer documentation and do numerous other things that a whiteboard does not. In an interview, time is scarce and it’s rarely worth writing out things already provided in practice. During an interview the interviewer might establish assumptions that are similar to what an IDE could provide. An interviewer could offer you an imaginary function that solves your current dilemma and lets you focus on your solution instead of spending time trying to remember something you could look up on Stack Overflow. You should not refuse if asked to write out a list of imports but it’s ok to ask if it’s necessary and explain that you use an IDE which does that for you automatically.

When writing code on a whiteboard, remember that in an interview someone is there trying to follow your code. Begin writing your code as close to the uppermost left corner of the whiteboard as you can reach and write large enough so that it can be read from anywhere the interviewer might be in the room. Do not obscure code you’re actively writing. Verbalize then explain anything you deliberately skip or omit. One drawback of coding on the whiteboard is that it’s not as easy to insert a line and shift code down, so leave enough space to write between the lines of your initial code. It’s natural to run out of space or make changes to your solution during an interview. Try not to rewrite things you’ve already written and never erase something from the whiteboard without checking with your interviewer first. Use your best judgement and communicate with your interviewer to ensure you meet their expectations.

Onsite Preparation

There are many methods to prepare for interviews. This approach emphasizes exercising your critical thinking to make you a more innovative problem solver and engineer. Preparing this way may not improve your interview performance at some companies but it will make you more marketable as an engineer and targets sophisticated technical interviews in top-tier engineering organizations like WePay, Facebook, Google and LinkedIn.

First, ensure you have something you can use as a whiteboard and something erasable to write with. A typical whiteboard is 4 feet tall by at least 3 feet wide and most suggested alternatives won’t provide a sufficient experience. If you don’t already have access to a glass door, mirror or other comparable upright surface, you can find an inexpensive whiteboard in most office supply stores or online. You will also need access to coding problems. There are great collections complete with solutions in Cracking the Coding Interview by Gayle Laakmann McDowell and the Elements of Programming Interviews series by Adnan Aziz, Tsung-Hsien Lee and Amit Prakash which comes in C++, Java and Python. Internet sites like LeetCode and Coderbyte provide comprehensive problem banks. Questions asked by specific companies can often be found on Glassdoor or with a cursory online search. When choosing problems stay away from puzzle problems or questions that require you to know and implement specific algorithms. Your goal is not memorization but to improve your ability to solve an unfamiliar problem during an interview.

The problem solving part of interview preparation is simple, iterative and very time consuming. Go over your notes from previous interview practice, read the next problem then verbalize it in your own words. Set a time limit of 45 minutes for coding on your whiteboard but don’t feel pressure to stop exactly at 45 minutes if you’re close to completing your solution. Remember to describe everything you’re doing and why out loud, just as you’d be expected to do in a real interview. If the problem is simple, don’t complicate it. If the problem is difficult, break it down into smaller components. Preparing with a fellow engineer can help keep you honest but resist the temptation to have your friends or family interview you. Having an unskilled interviewer or non-engineer interview you isn’t always helpful and is often counterproductive.

When you’re finished on the whiteboard, evaluate your interview performance. Were you able to break the problem down and plan a solution? Did you consider edge cases? How close was your eventual solution to your planned solution? Did you explain aloud the reasoning for changes that deviated from the originally planned approach? Did you verbalize your assumptions? How well did you test your solution? Measure your work against suggested solutions from your question bank and any additional solutions you find on the Internet. Take note of anything you could have done better or should not have done. Was there a better data structure, superfluous loop condition or completely different, better approach?

After you’re done critiquing yourself, take note of anything you think you did particularly well, and transfer all your feedback to a master list. If you keep track of your progress, and review areas where you need work before attempting each new problem, you should notice your problem areas slowly disappear or become strengths. Evaluating yourself may be difficult, and take lots of time initially, but as you progress the evaluation becomes quick, easy and gratifying. If you’re tempted to redo a problem once you’ve finished evaluating yourself, force yourself to move onto the next question. You’re exercising your problem solving skills so writing the problem you just researched back onto the whiteboard while it’s fresh in your mind will not help you.

Technical Phone Interviews

Technical phone interviews usually happen before onsite interviews and involve online code pairing. They are a low cost way for a company to establish alignment in key areas of interest. The method described above can be used to prepare for technical phone interviews. The most notable difference between preparation for phone and onsite interviews is that problem solving occurs on a computer instead of a whiteboard.

As with onsite interviewing, make sure you have the right tools to prepare for technical phone interviews. Apart from the need for a computer and access to the Internet, ensure you’re able to code comfortably while talking on the phone. Using the speakerphone on your cell phone can be problematic so I recommend investing in a headset. If applicable, wear your hands free device of choice while practicing to get used to it and as a reminder to verbalize your coding process. Avoid problem solving methods an interviewer can’t see, like planning your solution on a piece of paper. If you’re inclined to use a piece of paper, practice the same process in the editor where an interviewer can follow.

Go Interview!

While you’re preparing for technical interviews, the best thing you can do is go out and interview with real companies. Stay engaged and remember your responsibilities as the candidate. Each experience you have will make you a stronger interviewer and the right preparation will make you a better engineer. Following this process will not only lead to more success in interviews, but will help you obtain positions you find rewarding.