The Best Advice for the Whiteboard Job Interview

The Best Advice for the Whiteboard Job Interview

Technologists should be aware of the whiteboard job interview. Whiteboard job interviews are ubiquitous in the tech industry.

During a whiteboard interview, candidates for tech roles, such as software engineers and sometimes product managers, are asked to solve technical questions on a whiteboard, piece of paper or computer during the job interview.

The best advice I have ever received for the whiteboard job interview: Communicate!

The best advice: Communication

The best piece of technical interview advice I have received is to communicate! Communication is the most important technical skill to prepare before your job interview.

Let’s say you are in the job interview, and your interviewers ask you to start working on a problem on a whiteboard. Do you step up to the whiteboard and feverishly begin working to solve the problem?

No! While it’s everyone’s first instinct, it’s not the right way to go. Even if you think you understand the problem, you should slow down before moving forward and think about what you’ll ask the job interviewer.

What to ask in a whiteboard job interview

1. Restate the question.

Prove that you understand what the interviewer is trying to ask you in the whiteboard job interview. You might be surprised to find you don’t fully understand what they’re asking for — perhaps the question is similar, but not the same, as a practice problem you have completed in the past.

The interview should give you affirmation, or perhaps, they will help you understand the problem if your understanding is incorrect. Restating the problem shouldn’t hurt you. Instead,  it shows you can articulate a problem and gives you time to think it through while discussing it. Repeating the question can also help calm your nerves or boost confidence before starting.

2. Ask about edge cases.

Before you start coding, think about the inputs and expected output. Ask yourself and the interviewer if there are any potential edge cases. Your questions can help demonstrate your analytical skills and interest in preventing bugs.

3. Ask about test cases.

An excellent “free” question to ask is whether there are any test cases the function should pass. In some cases, your interviewer will expect you to ask this question.

A question about test cases during a whiteboard job interview can help demonstrate your testing knowledge.

How to approach a whiteboard job interview

1. Start with pseudocode.

Write pseudocode and ask the interviewer in your whiteboard job interview if it makes sense. Again, you don’t want to start writing code in an actual language. You might find yourself constrained by trying to remember the methods or other idiosyncrasies of the language rather than trying to come up with the correct logic.

Let your interview know you plan to start by writing pseudocode and that you’ll fill in the actual code later.

You can also ask your job interviewer if it makes sense as you write pseudocode. Often, job interviewers want to understand how you think, even if they don’t want to “give hints.” The feedback you receive can help you code better when you transition to writing actual code.

2. Write the actual code after you receive feedback.

Because you worked on pseudocode already, you should just need to plug in the appropriate code for your relevant coding language. If you forget some syntax or a method name, you should be able to ask your interviewer for this information without too much grief.

The bottom line

Coding doesn’t happen in a vacuum. If you’re having trouble, it’s not illegal to ask for help. Just phrase it conversationally. For example: “I’m a bit stuck here. Do you have any tips to nudge me in the right direction?”

Before the whiteboard job interview, ask the recruiter or your referral what the interview might be like. They could clue you into which language they prefer, the number of questions, the question style, and even the interviewer’s style.

This article was written by Nick Scialli for HackerNoon and was lightly edited and published with permission.