Whiteboard interviews get a lot of negative press for being ‘unfair’ or ‘not real-world scenarios’. They put candidates on the spot, away from their comfort zones. Countless articles, comments, posts, and tweets declare the irrationality of the process. The thing is, this is the point.
The whiteboard phase usually occurs after a candidate is already vetted by the HR team. They already passed an initial phone screen, and have been researched on Github and social media, painting a general picture of their technical abilities and personality. The whiteboard process is all about how the candidate copes with being put on the spot.
As an interviewer, I am looking for how the developer thinks on their toes and to also get a sense of their communication skills. Being able see how the candidate communicates and navigates their limitations in an open setting offers insight to their personality and professionalism.
As the candidate, I use this time to show my thought process of understanding and solving a given challenge. Syntax and perfection are not the primary focus of the interviewer. I tend to use pseudo code to explain the logic and solution. The code doesn’t have to be bug free, it does however, need to show understanding of the problem, and a solution understood clearly by other developers.
This is also a great time in the interview for the team to get a real feel for how you interact with others, take criticism, and handle yourself. Very few companies want the stereotypical code monkey working in isolation. Companies are looking for good personality fits. Candidates who prepare, learn from mistakes, and are honest with the team will succeed. They know their own skill level and shortcomings.
The last time I interviewed, one of the DBAs asked a pretty tough question. He drilled me on index speed differences, memory management, and the cost of a theoretical query at the scale of 5 million+ records. I didn’t know — and said so. I plotted out a couple optional solutions anyway. We spent twenty minutes discussing why two of them were terrible ideas. He showed me the solution their team came up with as well. They had spent a week testing several people’s contributions. Once we got into the nerd moment, I forgot I was even interviewing, and started working on the problem. It turned into a fun experience, and I learned from it.
Not everyone is comfortable being in front of peers and exposing their faults. While difficult, this is becoming and expectation of being a team developer. If this process is out of your comfort zone, it will benefit you greatly to practice in this area before your next interview.