Technical interviews: it’s not actually about the whiteboard
There are some interesting points in the above article on why folks fear and/or should avoid the whiteboard. I think the whiteboard hate is a crutch.
It’s like paper, but on a wall
Many preparatory materials will tell you to practice on a whiteboard before doing a technical interview. Of course, mindless practice will only get you initially comfortable with holding a marker, writing on a wall, and caring about your penmanship.
One important aspect of whiteboarding is to spend a few minutes thinking about space utilization. What is your process for solving technical problems and how can you use the space on the board to facilitate your process?
Do you work best by writing pseudo-code? If so, consider using the side of the board for notes (test cases, important bits of knowledge from the problem, logical conditions) and scribbles (algorithm structure or pictures of data structures). Or do you prefer writing code directly? If so, use the central/primary space on the board and consider leaving room between lines to fix bugs.
That’s it. That’s all you have to think about. Heck, you don’t even need to use a whiteboard to think about this. Practice space utilization on paper and that’ll transfer fine.
Yes, you might smear marker and get your hands dirty. Do you avoid writing on paper for the same reasons?
Focus on displaying your solution to the problem, not the medium.
Be careful of using the central part of the whiteboard for test cases or pictures. You’ll have to erase that stuff to code up the solution. Erasing the board wastes time. You may also erase an important test case and have to rewrite it — wasting even more time.
But I need access to Google
No, you don’t. If you don’t remember some part of the API (ex: forgetting if JavaScript has a method to trim whitespace from both sides of a string), vocalize that you don’t remember and use a helper method. No interviewer should ever knock you for that.
If an interviewer asks you to implement a classic sorting algorithm (like Mergesort), then that’s poorly testing memorization not application. In my experience, interviewers will expect you to know of the algorithm and its time/space properties, but are fine with you using sort as one operation in a larger algorithm.
Google is a crutch. Method names are details not worth worrying about. Worry about your algorithm. Worry about whether or not you actually solved the problem. That’s what matters.
But I prefer to code in an editor
One great aspect to whiteboarding (or solving problems on paper) is that it promotes delaying the actual writing of code for as long as possible.
If you use an editor directly, where do you scribble notes or designs? How do you make sure that you’re not jumping into coding before having analyzed the tradeoffs of multiple solutions? Coding too quickly is one of the biggest mistakes in these types of interviews. Avoiding lateral thinking puts on blinders that may commit you to the brute force solution without any awareness of a more optimal (depending on what you need to optimize for) approach.
If you must use an editor (if on a phone screen, for example), then one technique is to outline the solution using helper methods. Run through the outlined algorithm to make sure that it’s operationally sound. Then, if you and your interviewer agree, start implementing the helper methods. With this approach, you’ve avoided being too committed to an idea and avoided spending too much time down a potentially wrong path.
The code that you write for a solution does not need to run perfectly when interpreted or compiled. It should convey your thought process and correctly model the chosen solution to the problem. This is not an excuse for sloppy coding. Do a light pass code review after you’ve written your code to make sure it’s syntactically correct and typo-free. Banking on an interpreter/compiler when solving a problem hints that you maybe “code and pray” and don’t proofread your code or outline it ahead of time.
Remember the goal
You need to demonstrate that you can come up with a solution to a problem based on time/space constraints. The medium doesn’t matter. Don’t rule out whiteboarding because of the whiteboard; it’s a red herring that will deprive you of opportunities to join great teams.
