5 Easy Steps to Crush your Whiteboarding Interview
1. Restate the problem in your own words
“If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is.” – Einstein, Some Yale Professor, and Abraham Lincoln (apocryphal)
An engineer doesn’t just solve problems. They work hard with stakeholders to define the core of the problem and they document it in great detail. So before you do anything you want to prove to yourself and to the interviewer that you understand what they are asking.
Coincidentally by stating, restating, and reviewing a problem, you’ll prime your brain to figure it out. This single step will help you on each and every one of the subsequent steps. Lastly, and rarely, if the interviewer has not written down the problem out loud then it’s worthwhile to verify that they’re asking the right problem. Interviewers can make mistakes too. Check their work like they should check yours.
2. Assemble expected inputs and outputs with extra attention to edge cases
In the grand scheme of things, only a small percentage of an engineer’s time is actually spent writing production code. You’ll find both your own manual and automated testing take up significantly more time. Due to the back and forth of communication, having someone else find your bug is worse for both you and the organization. This is a good moment to point out to the interviewer that putting together a list of test cases can and should form the basis for automated testing. In particular, you want to make sure you cover all the edge and special cases that can easily trip you up or significantly alter the behavior of the problem. Ask yourself:
Can any of the parameters be null or of a different type than you’d expect?
If you are working with numbers:
What’s the behavior for cases like -1,0, and 1?
Do you have to worry about positive or negative integer overflows?
If you are working with strings:
What characters can be found in the parameters?
What about empty strings or strings with only one character?
3. Solve some examples by hand
All programming is automating. But before you can automate, you have to be able to do the task by hand. Take one of the examples and work it out on the board.
For example, the interviewer asks you to write a function that takes a string and returns true if and only if the string is a palindrome (ignoring capitalization and punctuation). Let’s say you get the test case, “Eva, Can I Stab Bats In A Cave?” Put that example up on the board. Put a finger from one hand on the first letter and use a finger from your other hand to point at the last letter; compare the two, then move your fingers towards the center. That’s a valid procedure (algorithm). Alternatively, you could have written the word in lowercase forward and backward without punctuation and compared the two. That’s also a valid procedure!
4. Write out the process you used
Once you know how to solve the examples, you should be able to see the common pattern. Write out that pattern in as much detail as you can. I’d recommend using plain English as much as possible. Similar to code, the goal is to have no ambiguity in these instructions.
Once you’re comfortable with this version of the explanation it’s worth pausing and reviewing. If you put some of your examples through the procedure, do they result in the expected output? Are you doing any unnecessary work? If you know algorithmic complexity, review the computational and spatial complexity and discuss it with your interviewer. Don’t be afraid to come up with a totally different procedure than your first attempt. Solving the same problem multiple ways shows your mastery of it.
5. Go to code?
Some interviewers don’t care about writing syntax perfect code, they just want to see you get a good algorithm. If the interviewer wants to see actual code, ask if your preferred language will work for them. If they ask you to use a language you are less comfortable with, just ask for a little more forgiveness on syntax and standard functions. If you’re going to actual code remember to test that code. Once you get it functional, refactor it to clean up the style and ask the interviewer for any code review-like feedback.
Finished!
Congratulations! You just tackled one of the most nerve-wracking parts of a developer interview. Take a step back and take a breath. Ask your interviewer for feedback. And if you’ve never seen this problem before, ask if you can take a picture of the board and publish the code to your GitHub. At the very end of the session, thank the interviewer for their time, effort, and feedback. They put in a lot of work too. Mutual expression of gratitude for good work shows how awesome of a coworker you would be.
This content was originally published here.
About the Author
