A software engineer of average or higher skill can succeed at any technical interview.
Surely the terrifying stories of the interview gauntlets thrown down by the engineering giants (Google, Apple, Microsoft, Facebook, Electronic Arts, etc) may have discouraged many qualified developers. A large number of experienced programmers and passionate new grads with everything it takes to be great employees have fallen through the cracks of false negativity. The world's demand for software developers has grown tremendously as technology has empowered our lives and it is unfortunate that we are losing talent due to failed interviews.
I'd like to share some lessons I've learned along the way. These insights come from my experience since university both as a frequent interviewee at companies such as Electronic Arts, Google, Facebook, Twitter, Yahoo, Microsoft, Ubisoft, Mozilla, Qualcomm, and as an interviewer of maybe a dozen candidates. I've had bad interviews and good, I've interviewed candidates both strong and weak; I understand the process. The technical interview is an art and a science of its own. With the correct preparation, a competent developer can master the process, break through the interview barrier, and land her dream job.
Why do we fail?The most probable reason for a qualified programmer failing a technical interview is inadequate preparation. There are numerous ways one can shoot themselves in either foot during the preparation phase leading up to an interview:
- Not relentlessly practicing problem solving
- Not reviewing computer science fundamentals (algorithms and data structures)
- Not communicating well
- Not studying systems design
- Not practicing writing and testing code by hand on a whiteboard
- Not doing mock interviews
- Not being intimately familiar with the programming languages you claim to know
- Not knowing the benchmark to which you will be evaluated
- Not having a game plan
Knowing the benchmarkWhile it is certainly possible to play a game without a plan, it is not as easy to win one. You need to know exactly what to expect from your interview in order to prepare yourself adequately. There are great resources available, a few essential ones are:
- Cracking the Coding Interview by Gayle Laakmann McDowell
- Algorithm Design by Kleinberg and Tardos
- MIT's OpenCourseWare Introduction to Algorithms videos and other course materials
- Steve Yegge's Get that Job at Google post
- Palantir's How to Rock a Systems Design Interview post
You should partition your study time based on the priority of study topics:
- 60% whiteboard problem solving, coding, and testing
- 20% studying theory through algorithm design books, online course materials, and web resources
- 15% studying systems design and practicing solving system design problems
- 5% studying the programming languages that may be required by the interview (e.g. C, C++, C#, Java, Python)
You need to try to get the exact metrics by which you are being evaluated. When a company gives interviews, usually they have a formal process through which interviewers give feedback. Usually it consists of giving a score say from 1 to 5 for certain evaluation criteria. For example, Google might use the following:
- Analytical ability
- Understanding of computer science
- Coding skills
- Communication / personality
CommunicationCommunication is one of the most important points of evaluation for an interview. Interviewers are evaluating whether or not they want to work with you so it is critical that you behave like someone they'd enjoy working with. Explaining exactly what you are thinking when you are trying to solve a problem is very important. You are being evaluated not on your ability to solve the problem but on your thought process and your approach to problem solving. You should never stare in silence at the whiteboard, the floor, your interviewer, the clock, the door, or the window (depending on your preferred escape route). Even if you are stuck, talk through your dilemma or your brainstorming process. Be methodical and follow a logical approach to solving the problem. Not only does this make the interview more interactive, this will also give your interviewer a chance to point you in the right direction. Sometimes all it takes is a single tip from the interviewer to get you on the right path to the correct solution. However if you aren't speaking your mind, they may not have the opportunity to help you. Help them help you. After you've figured out your algorithm, talk through the coding. You may be making a mistake in the implementation and the last thing you want is to write tons of code on the board then have to erase it all because you missed a key implementation detail. You also don't want the room to go silent as you write away furiously for 10 minutes and then finally reveal your solution to the world. In your preparation, talk out loud while solving problems on the whiteboard. Treat it like you have an omnipresent interviewer. You want excellent communication to be second nature to you. It will also prepare you for the realities of 2-5 back to back interviews where you have to be talking. Your mouth will get dry --make sure you have water, and you may get tired standing and writing for so long. Be ready for it. An interviewer will notice when you communicate very well. It will make them want to work with you. It will make them more likely to stand up for you when the company decides your fate.
Mastering the whiteboard
Figure 1: Whiteboard layout
When you write code in an editor or an IDE, you have numerous tools to improve your productivity. Those same tools are your enemy when preparing for a technical interview. Besides just trying to memorize problem solutions, practicing solving problems in an IDE with syntax checking, auto-completion, a compiler, and a debugger is one of the worst things you can do. You won't have such training wheels during the interview. You need to be ready for the whiteboard. If you don't have one, go somewhere that does and practice solving problems there or head to your local office supply store and buy one for $40. The cost can easily be justified as an investment since it will help lead you to your awesome new higher paying job. Now that you have a whiteboard, make use of it. Get a large list of interview problems (Cracking the Coding Interview has 150 of them, Elements of Programming Interviews has 300), pick some and start working them out on the board. Here is a winning approach:
- Ask your interviewer questions to clarify the problem (in preparation you'll have to make assumptions)
- Write important details on the right side of the board (inputs, output, requirements, and constraints)
- Begin by drawing diagrams and writing test cases on the board while talking through the problem
- Talk through different approaches to the problem writing down any important insights you have that may help you
- Once you've figured out the algorithm, write pseudo code (make sure to state that real code will follow) to clarify your thoughts
- Discuss the time and space complexity to make sure that this solution is adequate
- Begin writing code on the top left edge of the board (always check validity of inputs and edge cases)
- Once you've completed writing code, immediately (before being prompted) start running through the code with your test cases
- When you are confident the solution works, let the interviewer know
Whiteboard space management and partitioning can be very useful. I like to divide the whiteboard in half —keeping problem details, algorithm notes, diagrams, test cases, and pseudocode on the right side (see Figure 1). The left side is reserved for code. Start at the top left corner and don't write too big or you risk running out of space. It is best to not have to worry about erasing the board or writing code in a tiny font at the bottom edge of the board. In practice, you'll become used to this format and it will benefit you in the interview. It is important to not erase all the stuff you wrote down before coding on the right side because you will want to refer to it. It is easy to forget details after you've come up with the algorithm in your head. Writing important information down will help you remember and will prevent you from needing to ask the interviewer to repeat something from the problem definition. Also an interviewer who sees you fill the whiteboard in such a structured and methodical way will likely be impressed with your problem solving ability. In the time leading up to the interview you'll want to be very intimate with your whiteboard; take the time to think about how you can use it to your advantage.
The Secret to Success
The preceding quote from David Gelb's 2011 documentary Jiro Dreams of Sushi expresses the Japanese concept of shokunin kishitsu: the craftsman’s spirit. Matt Linderman of 37signals wrote a post describing the idea. I believe that the software professional should take pride in her work, continuously investing in learning and working towards perfecting her craft. The key to this is to be passionate about your job. If the only reason you want to work for a technology company is for the money then perhaps you shouldn't make it through the interview process. Great companies want great people who love what they do and will bring passion, creativity, and innovation to the workplace. You won't truly be successful in life until they don't have to pay you a dime to do what you do. Because you are a shokunin and you don't really care about the money. Well maybe you do, but only enough so that you don't have to care about it.
I hope you aren't overwhelmed by all the information and all the work involved with preparing for the interview process at a highly selective company. You should treat this with the importance it deserves. An interview is the gateway to that dream job that will change your life. I hope that this knowledge will empower and motivate someone to learn from their failures and put forward 100% in preparation for their next interview. Your interviews may be done within a day but they cannot control how much you practice, study, and prepare. Given sufficient time for preparation, a sound game plan, and hard work; success is just a day away. Good luck.