Code-Free Whiteboarding Tips

In my brief time as an adult on earth, I’ve had some weird job interviews. One time when I was living in Rome, Italy and interviewing for an internship in the Camera dei Deputati (their equivalent to the United States House of Representatives), my interviewer asked me what my zodiac sign was and was a bit unnerved when I told her I was a Leo (“Really? You are a Leo? Leos are pushy. You do not seem pushy.”) Another time, when I applied for my first law enforcement job, my interviewer looked me up and down and said “You know this isn’t like, ‘Orange is the New Black’, right? This is real.” Pretty condescending, but I guess my can-do attitude won her over because I ended up getting hired.

Now that I’m going into the world of software engineering, I realize that job interviews got just a smidge more challenging — not only do I have to convince a future employer that I would be a decent employee and can work as a software engineer, but I also have to convince them that I know how to think like a software engineer. This metric is usually ascertained by having the interviewee solve what is typically called a “whiteboarding” question — some sort of coding question that is expected to be solved without the help of resources like Google (and, let’s be real, Stack Overflow). Basically, on top of the typical stress of preparing for a job interview in which I’m trying to figure out how to best let my personality and professionalism and limited experience shine, I have to figure out how to let the pure mechanics of my brain shine as well.

So far in my software engineering program with Flatiron School, we have occasionally started the day with some whiteboarding examples and they have…not gone very well for me. I definitely find myself struggling to solve the problems with my limited knowledge of code, and get really bad imposter syndrome when I see what cool solutions other students in my cohort come up with. But a few days ago I was talking this over with another student and we both came to a major realization — yes, some students do solve the whiteboarding problems completely and get to proudly show their solution to the rest of the class, but even more impressive are the students who admit that while they didn’t solve the problem entirely, they are brave enough to show what little bits of the problem they were able to solve. By doing this, they are still sharpening what I’ve come to believe is the real underlying skill of whiteboarding — the skill of articulation. Yes, getting a working bit of code is probably still the most ideal conclusion to a whiteboarding interview question, but being able to explain your understanding, to talk through the components you know you need to solve the problem, to articulate your thought process — these are the most essential parts of the interview. Memorizing common whiteboarding questions without a deep understanding of logic is not going to help you in the long run. Similarly, while being a brilliant coding whiz might get you into the company initially, not being able to explain your code is going to cause issues when you start collaborating in a team later in your career. A mastery of code, combined with the ability to articulate code, is the ultimate key to success in the field.

In my humble experience and research on what to expect in a whiteboarding interview, it seems like there are a few key components:

1. Ask Questions : Asking questions achieves a number of results. For one, it shows you have a deep desire to really understand the problem at hand, which will get you closer to really understanding how to solve it. Asking questions also allows for time for Nervous Nancys like me to calm down, take things slowly, take a deep breath while your question is being answered, and analyze the problem step-by-step. Finally, asking questions is a bit of an indicator to your interviewer that you’re a little bit humble — even though many tech companies love having brilliant know-it-alls on their payroll, having the humility to ask clarifying questions from the get-go shows your interviewer that even if you are actually a coding genius, at least you’re not pretentious about it.
2. Make a plan : Sketching out your initial plan of attack on the whiteboard is an excellent way to show to your interviewer that even if you may not end up with perfect code, you at least had a great plan via pseudocode to get there. Most long-term coding projects in the “real word” require a great deal of planning before a single line of code is ever written. Demonstrating that you know how to plan before you solve a problem lets your interviewer know you would would approach a real-world problem in a similar, methodical way.
3. Know your Acronyms!: This last one comes specifically from this Medium article but I thought it was wonderful because it highlights a skill possessed by wacky people like me who originated from the Land of Liberal Arts. Memorizing may not be particularly helpful when it comes to producing decent code, but memorizing and describing the meaning behind basic acronyms like REST, API, JSON, etc not only demonstrates your knowledge in a non-logic-centric way, but it can also help jog your memory if you feel stuck during an interview. It’s almost like taking a quiz and answering the extra-credit question at the bottom — maybe you missed one or two of the main questions, but any bonus points can help boost your average in the end.

These three tips, coupled with actual practice on a website like CodeWars, will be sure to get you well on your way to nailing your whiteboarding interview. You may feel a bit clumsy at first, but like any muscle, your ability to interview can get stronger. And hopefully at the end, if it all goes well, you don’t even need to reveal your zodiac sign (unless you really want to).