Software interviewing practices in the US usually involve a combination of the below

• Phone Screens
• Team Pairing
• Take Home Projects
• Design and Architecture Interviews
• Whiteboard Interviews

Hopefully, I am not alone in the shared dread of whiteboarding. As developers who type source code, use tools and reference documentation, approaching problems on the whiteboard is far removed from what we’re used to. I want to focus on some tips that have helped me prepare better for white boarding.

#Practice the Act of Whiteboarding

Write it on paper

Being someone who types, I have been able to avoid handwriting since high school. However, it has made my handwriting atrophy and even more atrocious. Practicing doing problems on paper is a great way to practice space control equal to doing the problems on the board.

Form a group

Form a group to practice whiteboarding. Each member can give each other a question while the third solves or takes notes. I worked in a 3 person group and for two weeks we gave each other questions with a 25 minute alotment for each question.

Follow a format for Organization

It becomes harder for the interviewer to follow if the board is a mess. It will be easier to follow a set strategy like specific spaces on the board you practice like writing key insights and examples.

Practice lots of problems

There are quite a few sites with good practice problems that have automatic tests. Here is a short list:

• Leetcode
• HackerRank
• Codewars

Be comfortable in the language you’re whiteboarding in

Picking a language that you are comfortable in is useful. I remember when I first did whiteboarding, I decided to try whiteboarding in C++ when I had mostly been practicing in JavaScript. It ended up becoming very sloppy, mixing syntax between C++ and Java; It’s better to whiteboard in a language you’re very solid in than one you think the interview would prefer.

Revisiting a data structures course like Problem Solving with Python Data Structures was an excellent refresher for me to know the internal tradeoffs in Python. Python is a language I’ve been using professionally but not my first language I learned programming with.

In addition, at minimum would be recommended to know these structures in the language you’re familiar with. These recommendations come from the Cracking the Code Interview Sixth Edition.

Do your homework

Research your company to find out their process. If its one of the larger firms, it would be good to practice problems findable on sites like CareerCup to be prepared. Often recommended is asking recruiters and engineers what the interview process is like directly when finding out about the company.

Repeat

Doing more of all the above has helped me feel more confident to walk into the office and ace my next whiteboard interview.