4 Strategies for Whiteboarding Success February 16, 2020
Sound familiar? Many of our graduates tend to overemphasize technical preparation when it comes to interviews, but the non-technical aspacts are at least as important, if not more so. In this post, I'd l'll highlight four whiteboarding strategies that candidates often overlook.
1. Talk more.
Before I interview potential Rithm students, I always emphasize the importance of communicating their thinking. Interviewers are trying to understand your thought process as much as they're trying to assess your technical proficiency. If I describe a problem and the candidate stares at the whiteboard in silence for a minute before writing out a solution, I have no insight into what just happened. Did they already know how to solve the problem because they saw it in an interview last week? Did they reason their way through the problem step-by-step? What road blocks did they anticipate and solve on the fly in their head? I have no idea!
Sometimes I get the sense that people don't want to talk because they don't want to admit that they can't solve the problem right away. But technical challenges are just that - challenges! If the problems were all straightforward, solving them wouldn't give the interviewer much useful information. More often than not, interviewers expect you to struggle, ask clarifying questions, and so on. This is because they want to know how you think, not just what you know.
If you've been solving problems by yourself in front of a computer screen, communicating your thinking can feel unnatural. However, in a work or school environment, communication is key for success. Before a technical interview, I'd highly encourage you to get together with a friend and practice talking while solving problems.
2. Listen more.
At the other end of the spectrum, sometimes candidates have no trouble talking, but are too nervous to listen. One quality that interviewers are looking for is coachability. If you outline an approach and the interviewer tells you about some pitfalls, do you listen, or plow ahead? If you're stuck and the interviewer makes a suggestion, do you go with it or try to forge a different path? If your interviewer is making a suggestion, you should take their advice. They're not trying to trick you; they're trying to see whether ot not you can take feedback and apply it. If you don't understand the feedback, that's okay too. Just ask for clarification (see point number 1).
3. Slow down before writing code.
A majority of the candidates I interview start writing code too soon. This may sound like a strange remark to make about coding interviews, But coding on a whiteboard is very different than coding in front of a computer, in a way that rewards a slower, more thoughtful approach.
Let me give you an example. Most people who want to come to Rithm are used to writing some code, trying it out, seeing what the computer tells them, and then repeating this process until they get the correct answer. The whiteboard is unable to provide this sort of instant feedback, so it forces you to be able to reason effectively about your code as you're writing it. One way to manage this effectively is to decouple the problem solving from the code writing.
(Need some tips on problem solving? We've got you covered! Check out the first post in our problem solving series here.)
Whenever someone has finished solving a problem on the whiteboard, the first thing I ask them is "Ok, does it work?" I'm not trying to trick people who have come up with a correct solution. Instead, I'm asking whether or not they're comfortable reasoning about what they've just put on the board. Can they walk a sample input through their code and describe what happens line by line?
Most of the time when I ask this question, I get very short answers: "Yes," "I think so," or the dreaded "I don't know." Treat this as your time to reflect on what you've done and really demonstrate that you understand what you've written.
This is also the time to double-check your work! More often than not, you'll be able to catch bugs by walking through your code with this level of detail. And it's always better to catch a bug yourself, before your interviewer has to tell you that you've made a mistake.
Whether you're looking to get into a coding school or apply for your first engineering role, odds are you've got a whiteboarding interview in your future. Don't be like most candidates and focus solely on technical proficiency. Practice these non-technical aspects of the interview as well. Often times, demonstrating these skills can make the difference between passing and failing.
Written by Matt