So you’ve been practicing JavaScript for a while, and you’re feeling confident in your problem solving skills. You land an interview, and you spend hours solving technical challenges. But when you get in the room with the interviewer, your confidence evaporates. You clam up, your nerves get the best of you, and you walk out of the interview feeling shaken.
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.
The most successful candidates are the ones who can write out a solution to the problem in pseudo code or plain English, and then translate their notes into valid syntax for whatever language they’re writing. People who don’t do this are basically waging a battle on two fronts: the problem itself, and the language they’re using to solve the problem. By separating these things, you can focus on the problem purely as a problem first. By the time you start writing code, ideally you should know exactly how to solve the problem, so that the only thing remaining is a translation in to JavaScript, Python, or some other language.
(Need some tips on problem solving? We’ve got you covered! Check out the first post in our problem solving series here.)
4. Reflect.
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.
