Whiteboarding

Whiteboarding is one of the most critical skills you need to have in order to become a successful software engineer. Above all, it is super important for getting a job and you will be doing a lot of it during team projects or anytime you are trying to solve technical problems. But often times, people struggle with whiteboarding and I do as well. The first time I practiced whiteboarding, I let about 5 minutes pass in awkward silence and struggled to make sense of the problem that was given. Since then, I have been practicing whiteboarding through few different approaches and finally came up with steps that I feel comfortable with.

  1. Ask any clarifying questions in the beginning. We don’t want to make any assumptions about the problem we are given because we want to return an answer that satisfies all the requirements required by the interviewer.
  2. Take time in the beginning defining inputs, outputs, edge cases and constraints and make note of them on the whiteboard so you don’t forget!
  3. Use the whiteboard. A LOT! Especially if there is a piece of the problem that doesn’t make sense to you, you want to spend time visualizing examples by drawing them out on the whiteboard. When you can visualize different edge cases, it will be much easier for you to come up with a solution.
  4. Once you are pretty confident with the solution you came up, move onto pseudocoding. Only when you are confident with your pseudocodes move onto actual code writing. I usually recommend NOT jumping straight into coding without having a pretty good solution in pseudocode. Writing the actual code should just be translating pseudocode to JavaScript. Likewise, pseudocode should just be translating a solution into plain English logic.

Takeaways/Things to keep in mind: 1. Don’t be afraid to turn the questions back around to the interviewer. As we have said above, we want to clear out all assumptions we might have about the question prompt. Also, asking more questions buys you more time! 2. If you can’t think of any edge cases that are specific to the problem, think of standard edge cases for the data types you are working with (ex: arrays: empty arrays, duplicates/copies, numbers: negative or positive). 3. When you are creating example data, try to include all possible edge cases as this decreases the chance of you missing or forgetting about important edge cases. 4. Try your best to structure your pseudocode to make translating from pseudocode to JavaScript codes as easy as possible. We want anyone to be able to look at the pseudocode and translate them into actual codes. 5. Be confident, stay engaged, and do your best to keep conversations flowing! This is the most important part. We want to show off our communications skills and positive energy, eventually wow-ing them to want to work with us.

*****
Written by Hera Kim on 22 January 2016
comments powered by Disqus