7 Steps To Solving Your Technical Interview Problem

If you’re anything like me, technical interviews can be very nerve recking, especially timed ones! You look at the problem, look at the ticking clock, and before you even read the question your palms are sweating and you’ve magically forgotten everything.

Well, I’m here to help calm your nerves and, hopefully, help you get your thoughts in order so that you can pass that technical interview and be that much closer to getting your dream job.

I was fortunate enough to dig into the world famous book ‘Cracking The Coding Interview’ by Gayle Laakmann McDowell. If you are a software engineer or just getting into the tech industry, I highly recommend you get your hands on a copy. The book does a great job of preparing individuals for the technical portion of the interview process. Today I am going to be talking about the seven steps to problem solving during a technical interview, discussed in the book.

Step 1: Listen

You want to make sure you get a good grasp of the problem description. Be sure to ask any necessary question to clarify any details that may seem not so clear. Do not be afraid to ask questions! I find it helpful to take little notes and jot down specified details that the interviewer may have given so that I can refer back to the notes and be sure that my code takes all details into account.

Step 2: Example

Before you begin coding, you want to make an example case. Actually, you want to have multiple test cases for examples. But you don’t want to have an example that is too easy, because this may not cover all test cases and could easy slip past a specific detail. So what does a good example consist of? Well, according to ‘Cracking the Coding Interview’, your example should be: ‘Specific… Sufficiently large… Not a special case.’

Step 3: Brute Force

Next up, you want to find the easiest solution you can think of. This will show the interviewer that you are capable of solving the problem. This will also help you gain clarity on the problem and give you some guidance while writing your optimal solution as well. So before you begin spending the time to write the most optimal solution, try to get the easy solution out first.

Step 4: Optimize

At this point, you want to go through your brute force solution and find ways you can optimize your solution. Things to look for?

• Bottle necks that may be slowing down your code. This is where you want to think about Big O and find ways to speed up runtime. Find ways that you can consolidate steps for better optimization
• Eliminate any unnecessary work
• Try to reduce duplicate code. Find areas you may be able to reuse code. This not only can speed up runtime, but looks cleaner to the interviewer.

At this point you ay also want to create new examples to test your code with. You also want to go through the problem and your notes again to make sure your solution accounts for all the details provided.

Step 5: Walk Through

Once you have the most optimal solution, you want to walk through this solution in detail. You want to make sure you completely understand your solution and the problem at hand. Don’t rush to the code without having a solid foundation laid. If you do these first five steps properly, you should be able to complete the coding problem with ease. Write out any pseudocode to help you through the coding process if necessary.

Step 6: Implement

Up until this point you should not have actually coded anything yet, but you should have a solid foundation and blueprint to build your code on. At this point you will begin writing your code, based on the solution you have created. Be sure your code is neat and error free. Also, be sure to have descriptive variable names. Although variable names such as ‘x’ and ‘i’ may be appropriate for instances such as recording your starting points for iterators, it can lead to confusion when used for other instances.

Step 7: Test

Once you have written your error free code, you should then test your coded solution. You can do this with your example case, but you can also verbally walk through the code to make sure all of the pieces work as you intended them to. To get a quick feel for if your code is written properly, you may want to create a shorter example version for time purposes. It may also be a good idea to test any special cases that may typically cause issues. If you find any bugs, it is perfectly ok to think through the bug and come up with a fix.

Congrats! You made it. These are the seven steps, as provided by the book ‘Cracking The Coding Interview’. Along with these seven steps, it is also highly advised that you are talking through your thought process during each step aloud with your interviewer. This will allow them to see how you think, and may benefit you in certain scenarios, such as if you get stuck, or if you are headed in the wrong direction, or maybe if you don’t finish the code in the allotted time.

I know that technical interviews can be very daunting, but hopefully these seven steps will help organize your thought process while completing your next coding challenge. Good luck to you all!