A plane is flying at cruising altitude when suddenly the pilot hears a loud bang. Immediately she begins to lose power to one of the engines. With over 300 passengers on the plane, it is up to her to safely respond to the situation.
Just as she’s wondering what to do next, the first officer pulls out a large binder of checklists and flips to the one associated with engine failure. By staying calm and following the steps outlined on the checklist, the pilots are able to safely maneuver the plane to a nearby airport.
Commercial aviation is one of many fields that relies heavily on checklists. Checklists are critical because they greatly decrease the chance of human error.
Particularly in times of stress, we forget pertinent information. Have you ever had to stand up in front of the classroom or up on stage and completely forgot what you were going to say? Having notes with the key points you want to mention makes it much easier to ensure you say what you wanted to say.
A job interview is a perfect example of a time when stress can greatly affect your performance. There is a lot of pressure on you to do everything right, from making a good first impression to finding an optimal solution to the problem they pose.
While you likely won’t be able to bring notes into an interview, you can still develop a repeatable process for solving coding interview questions. By having this mental checklist, you can ground yourself and perform better and more consistently, even in the high stress environment.
Having a prepared process is also critical for you when things go wrong. Sometimes a problem is easy to solve, but sometimes you get totally stuck. When you get stuck, knowing the next step in your process is key because it gives you something to fall back on. Rather than freaking out (as many, myself included, tend to do), you can simply take a deep breath and move on to the next step in the process.
So what is this magical process? Well first let me say that there is nothing magic about having a process in and of itself. You need to understand the process. You need to know how to execute the steps. Once you do that, however, it opens up many possibilities.
The process that I will define is not static. You can and should practice using it and determine what works best for you. Some steps can be modified or added/removed to make this work better for you. This process is based off of the process defined in Cracking the Coding Interview.
Now that I’ve got you all pumped up, let’s look at the process.
- Understand the problem
While this may sound obvious, it is a step that is constantly missed. My favorite go-to problem when evaluating people is asking them to print out a linked list in reverse order. Consistently, at least half of the people will spend a lot of time reversing the linked list and returning it, rather than using a simple stack-based or recursive solution that prints out the list and returns nothing.
Understanding exactly what is being asked of you is critical to your success. Ask any clarifying questions necessary (you can also ask later so you don’t have to figure out all your questions now). Also consider the example they give you. Look at the input and figure out how that resulted in the given output. If you see any obvious problem areas or edge cases, add in your own example. Based on the input and output, what should be the signature of your function?
- Find a brute force solution
While I’ve already somewhat belabored the point here, it is absolutely essential that you start with a brute force solution. Far too many people try to jump into an optimized solution and get lost. At that point it can be really hard to recover without simply starting over, and in an interview you definitely don’t have time to start over. Finding a brute force solution also guarantees that you find a solution.
When searching for a brute force solution, there are a couple of things you can try. If a question asks for the most something (longest path, largest weight, etc), you can solve it by finding every possible solution and comparing them. If you’re unsure how to approach a problem, try solving it by hand first and then codifying your approach into an algorithm. Remember that your solution can be super inefficient. It doesn’t matter at this point.
- Optimize the brute force solution
Here is where you have the chance to shine. You shouldn’t spend more than 5-10 minutes on this step before moving on to coding, but this is your chance to make your algorithm as efficient as you can.
There are plenty of approaches you can try here, including brainstorming more efficient data structures, looking at duplicated or unnecessary work that you’re performing, or just looking for more efficient solutions unrelated to your brute force solution. The key is, though, to not spend too much time here before simply selecting the best solution you have and starting to code it up.
- Code the solution
Now that you’ve done all the legwork, coding your solution should hopefully be the easy part. If not, it’s worth dedicating time to practicing coding, particularly on paper or a whiteboard.
- Test the solution
This final step is critical, and something that many people do wrong. Not only does it show your interviewer that you are careful and thorough, it gives you yourself the confidence that your solution is correct. How would it feel to answer your interviewers “Is your solution correct?” with a confident “Yes!”?
The key to testing your code is to actually go through the code line by line. Too many people simply talk through the logic. This is a good first step, but it guarantees that you miss small typos or indexing errors. Missing these could leave a bad taste in your interviewer’s mouth even if you did well otherwise. Therefore you should pick a simple example and go through the code in it’s entirety.
With a defined process at your side, there is no reason to be nervous in an interview. Even if you see a problem that confuses the hell out of you, you know where to begin and can simply take it one step at a time.
Sometimes, you’re lucky and get easy problems. Most of the time the pilot doesn’t have to deal with engine failure. But when you get faced with hard problems, or the engine cuts out, it’s good to know the next step.
Get Free Stuff!
Sign up now and I'll send you weekly emails with more content like this.