# Whiteboards - Problem Solving Steps

## Continuing on with Udemy - Coding for Interviews Course

I have been working through more of the Coding for Interviews Course that I started last night. One of the things that the instructor goes into depth of is the steps he uses for solving coding problems on a whiteboard. Going through these steps helps to make sure that you're really understanding what's going on before jumping into the code and can also help show the thought process you went through to get to the end point. I plan on incorporating these into the practice problems as I continue working to better my programming skills.

## 1. Confirm the Problem Statement

Confirming the problem statement helps to make sure you're understanding everything properly. This is especially useful if you've done a similar problem, then you know that you're solving the version the interview wants.

## 2. Write the Problem Signature

Write out the function signature for the problem you're working on. This clarifies all the parameters you're going to need and anything that you are supposed to be returning and that they're all the correct type for the problem.

## 3. Find Examples

Come up with some example inputs for the problem. Be sure to find some edge cases as well as a couple of simple inputs that can be used for testing. Be sure to include as many different characteristics that you can think of.

## 4. Brainstorm

Write down some possible algorithms or data structures that might be helpful in solving the problem. If possible draw them out to help with the next step.

## 5. Combine step 3 and 4 visually

Pick one of the more simple examples and draw out the final data structure and algorithm that you're going to use. This helps to confirm that your algorithm is the one that you want to use as well as creating a template for you to look at when coding out your problem. It also gets you in the mindset to start coding.

## 6. Code it Out

Code out the algorithm you've chosen. Be sure to be talking out loud as you do it. This helps you make sure you're doing what you think you are, and gives the interviewer an idea of your thought process. If you get stuck, take the time to test one of your examples and see what it is you might need to do next. If you're spending too much time doing one particular thing, call it as a helper method. If the interviewer thinks that's an important part of the algorithm that they'd like to see they'll ask you about it. Otherwise it allows you to continue developing your code.

## 7. Test Again

When you think you're done coding. Test your examples against your code. Don't just test the simple ones, test the edge cases as well. This helps you make sure that your code is bug free. It looks much better if you find your own bugs than if the interviewer has to point it out to you.

After he initially talks about this set of steps, he walks through a ton of different problems using them before he dives into some more different data structures and algorithms.