If you live in the Bay Area, you would be familiar with the chatter on how difficult it is to hire talented engineers these days. Well, looking back at tons of interviews I have done, that comes hardly as a big surprise. Seems that our education system still produces generations and generations of engineers with below-average passion for solving problems.
Extracting the traits of failed newbie developers, let me emphasize three of them which I have seen over and over again. To make it more vivid, I’ll relate this to the possible answers you might get if you are given the following problem (which I already blogged before and also discussed at Stack Overflow):
You have rand5() function at your disposal, it returns an integer number 1..5 with equal probability. Your job is to implement rand7() function, which returns an integer number 1…7, just by using rand5().
(1) misunderstand the problem
Typical rookie’s mistake is answering the problem with scaling the return value from rand7() so it fits the desired range 1…7. While this might be the obvious answer, it is an excellent way to show how sloppy you are. In fact, there is a reason the problem has the word integer in it. Also, do you think high-tech companies want to hire you for solving a problem with just high-school math?
Another variant of miss-the-point approach is by ignoring rand5() and just return another random number. Totally off the mark. The reason rand5() exists at the first place is so that you can show your analytical and problem solving expertise. In real life, the same verbatim problem will likely never show up in your job. However, the similar problem solving situation usually occurs again and again.
Personally I never realized the power of reading and understanding the problem statement, until I studied in Germany and I had to read the exercise questions over and over again (it’s in German!) till I finally got it. Even if the problem is described in your native language, carefully going from one word to another might reveal something important and critical for your upcoming amazing discovery.
(2) only think one step ahead
A very common answer to the problem is by producing a number greater than 7 and then taking the remainder when dividing it with 7. For example, one can call rand5() twice and add both numbers, which results in a new range outside 1..7. Facing with this answer, the interviewer usually asks you back: what is the distribution of rand7() implemented that way? And if you manage to figure it out, the challenge is bumped: now rand7() is required to have a uniform distribution.
This is a case where, when you try to solve a problem, your gaze is fixed to the gravity of the problem and forget to look around and think outside the box. Obviously, the goal of this interview question is to realize a uniformly distributed rand7(). Otherwise, you might as well return whatever rand5() returns (giving a completely skewed distribution since 6 and 7 will never show up).
Playing the devil’s advocate in your mind is a great way to anticipate what’s coming. Chess players know this very well. Even with tons and tons of practices, a grand master is still prone to make a serious blunder. Imagine if you never think ahead more than one step.
(3) lack of basic training
Now that the interviewer teases you that she wants uniformly distributed rand7() implementation, what do you do with your rand5() manipulation? A lot of bit fiddling and arithmetic operation, if you don’t think carefully, will not yield 1..7 with equal probability. If you scroll through the comments in my previous blog entry, most of the wrong ones falls into this category.
You might be stopped there forever, if you hardly grasp the math behind it. As with any technical question, the correct answer hardly matters. The purpose of the interview process is to follow your train of thoughts, to see how you would attack the problem with different angles and analytically converge to a solution. This is however only possible if all the basic concepts of logic and problem solving is imprinted in your brain.
Just like Peter Norvig asked, why the rush?. In his Outliers book, Malcolm Gladwell popularizes the notion that expertise requires 10,000 hours (or roughly 10 years) of continuous practice. You may not completely subscribe to that theory, but there is some truth to it. Our instant culture does not really help if you want to push your career further. Everyone wants to get an executive summary version of everything (don’t you think there is a reason it’s called executive summary).
If you dream of solving real-world problems, start by doing your homework and doing it really really well. Code more, tweet less.
And by the way, just buy the T-shirt if you like.