This post is in response to this article. Read it and then come back; it’s not too long.
I actually really like Whiteboard interviews. I like taking them, I like helping people prep for them, I like mock giving them. I enjoy the puzzle and the straightforward goal. I find them WAY less intimidating than traditional “tell us about yourself” interviews, which scare me to death and I’m so glad I never have to take. I will always prefer technical interviews over non-technical ones because I’m still not sure what I’m actually supposed to do in a non-technical interview.
Clearly, I’m in the super tiny minority, and I’m trying to understand why. Sometime during years of TA’ing my knowledge of Java passed “useful for a job” into the land of “tiny details that will never matter in any context other than a Whiteboard Interview or JVM development”, so perhaps I’m speaking from an unfair standpoint of having more knowledge of absurdly small details that will never be useful on the job. (Though you never know. Knowing the actual explicit steps Java and similar languages take to initialize an object when you say “new” caught a bug today. Tsvi can vouch).
After reading the actual tweets again, though, I have to wonder if the problem isn’t the format but the questions being asked. I don’t see anything wrong with whiteboard interviews, but asking someone to code up bubble sort is worse than useless. It says nothing about their ability to think critically, made design decisions, or meaningfully choose data structures, but only whether or not they’ve memorized how to write bubble sort. For what it’s worth, I haven’t. (As far as algorithms go, though, I could code Dijkstra’s in my sleep. I taught it too many times to forget it).
The point of a whiteboard interview is two-fold:
First, to get a grasp of how well the person knows the language in which they are interviewing. It would be amazing if we could speak in pure logic and the computer would understand, but we can’t, and I believe a fast and flexible knowledge of at least one language (hopefully more) is a fair prerequisite of any software job. I don’t think there’s any other way of measuring this other than seeing it in person. For every project or class listed on a resume, you have no idea how much was done by the candidate themselves and how much they were helped along by others.
Second, to determine how their mind processes and works through technical problems. On a more general level than the language, did they understand the problem easily? Did they ask intelligent clarifying questions about requirements for a valid solution or the use of well-known public functionality? Were they able to talk out their thought process, and in the case of getting stuck, were they able to explain how and why they were stuck concisely and clearly? All of these qualities, I believe, are exceedingly important for every software position, and again the only real way to tell is to find out yourself.
I think the problem is not the format, but lazy interviewers/question writers. The whiteboard interview succeeds at testing these qualities when it’s testing the candidate’s ability to code, *not* their ability to recall and write a specific algorithm or data structure that could be found in full on such and such a page in such and such a book. Developing truly novel questions is hard, and keeping them novel and not leaked for interview after interview is next to impossible, but compared to Bubble Sort we can hardly do worse. This speaks to the diversity side of the issue brought up at the end of the article as well. If the problem doesn’t require or even reward rote memorization, hopefully the people who “spent as much of [their] scarce time as possible learning to code” won’t be punished for not having memorized quite as many algorithms.
In the pursuit of better whiteboard questions, I’ll leave off with the best whiteboard question I was ever asked (not for Google, but for one of my internships). It requires absolutely no knowledge of any language, only a basic understanding of arithmetic and I suppose Algebra. As such, it can be attempted by anyone even if they’ve never taken a single CS course. Nevertheless, it still accomplishes the whole goal of a whiteboard interview. Here it is:
Consider a new, exceedingly primitive language in which you have only the four following statements/control flows:
1) Initialize and set a variable to 0, such as x = 0.
2) Increment a variable, such as x = x + 1, also written as x++.
3) Loop, which takes a variable, and repeats the following statements in braces a number of times equal to the variable *when the Loop statement is first reached*. Thus:
x = 0
x++
x++
x++
y = 0
z = 0
loop(x) {
y++
z++
}
Would set both y and z to 3, as the loop body would be executed 3 times.
4) Return x, which yields x as the result of your computation. This must be the final line of your code, and cannot be within a loop.
Given only those four statements/control flows, write a function that takes a single argument `A` and returns a variable with value `A-1`.
It's Just A Game 