Here be the Code Monkeys
This is another one of those posts about the difference between software engineers and code monkeys. This is going to be different, though. Usually, in these posts, you and I play the parts of allies, as we point and laugh at some other group of people… the code monkeys. This time, though, I’m going to attack a (prevalent?) attitude as code monkey-ish. You might hold this belief. If so, I’d urge you to reconsider.
The Knight & the Dragon Fallout
This started when I was completely struck by some of the responses to my post about the Knight & Dragon problem. For those of you that don’t want to read it, it is basically a puzzle which effectively forms a game that is to be played. I walk through some optimal strategies for said game. The post was originally meant as simply “here’s a puzzle, here’s a solution, it’s kind of cool”. Somewhere along the way it got submitted to reddit and a whole discussion ensued.
By posing it as a “programming interview question”, I got a whole subset of responses that I wasn’t necessarily expecting. These responses (from both reddit and the comments here) ranged from the indignant…
if i was asked any of these types of “brain teasers” i would walk out of the interview.
…to the arrogant…
I have almost 15 years of experience, and if this is the best kind of question they could come up with, then I would likely respond with my own questions about an appropriate candidate screening process
…to the funny/snarky/sarcastic…
How much dragon poisoning will be expected during my employment?
…to the brilliantly funny/snarky/sarcastic…
A knight goes to an interview with a king of a nearby kingdom. The knight arrives expecting to be quizzed on topics such as dragon slaying and protecting the king, but much to his dismay, he is asked the following questions.
“You have an array of size ‘2n’ of these, ‘n+1′ elements are distinct and 1 element is repeated ‘n’ times. You must find the repeated element and say how many times it has repeated. Your solution must use minimum no. of comparisons. Also, say how many comparisons your solution will make in the worst case?”
Unsure of what the hell the king was talking about and deciding that he is obviously insane for asking such a ridiculous question, he does the honorable thing by drawing his sword and running the poor old coot through, thereby releasing his kingdom from his deranged tyranny. He then returns to his own country and his own king who, while not the most generous of employers, at least knows what knights do for a living.
Brain Teasers
There is a common sentiment that brain teaser questions have no place in an interview room. I agree as long as we properly (and narrowly) define brain teaser. The worst offenders are the “gotcha” type questions that require a single lightning strike of cleverness. Gotcha questions absolutely should not be in an interview.
Don’t be one of those people who fall into the trap of extending this sentiment to include all “non-programming” questions. This includes open-ended problem-solving questions (how would you weigh a 747 without a scale?) and simple metaphor questions (example coming later). Don’t be one of these people that see they are being asked something that somewhat resembles a puzzle, but not in programming terminology, and they have a conniption about how “real” programming interviews should be done.
If you are one of those people you are treading in very dangerous territory. Very, very, very dangerous territory. The territory in question is where the code monkeys live. And at my place of work, we don’t hire code monkeys.
The Point (I’m getting there!)
Before we continue, let me be crystal clear: some (but not all) of these non-programming questions are awful for interviews. In my opinion, the Knight and the Dragon problem is inappropriate for interviews because it can be confusing, and it takes alot of discussion to actually establish the rules of the game properly.
Let me remove these valid objections by posing another (semi-popular) non-programming question:
We want to figure out how strong our new super-strong light bulbs are. We know that they will be break when dropped from the top floor of this building (the 101st). We want to know the exact minimum floor from which a fall will cause the light bulb to break. You’ll be given two light bulbs for this task and we want you to do it with the minimum number of trials.
Are you angry that an employer might consider this question valid? Are you intellectually insulted? Would you (threaten to) walk out of this interview (on reddit)? Would you be stamping your feet bristling with indignation?
From earlier…
He then returns to his own country and his own king who, while not the most generous of employers, at least knows what knights do for a living.
You see, the point is that our programmer doesn’t want to work for employers who don’t know what programmers do. A fair point. Programmers don’t make a living solving riddles about knights and dragons, and they don’t make a living dropping light bulbs from buildings, or crossing bridges, or any of the rest of that crap. That’s correct. But I’m not asking you to just solve a riddle. I’m asking you devise an algorithm. For the Knight. For the Dragon. And for the light bulb company. If you walked out of my interview after I asked you the light bulb question and said “I don’t do brainteasers”. My first response, without hesitation, would be: “Apparently, you don’t do algorithms either.” And to continue the snarky metaphor, what you’ve just told me is that you don’t think devising algorithms “is what programmers do for a living”. O RLY?
Every self respecting computer scientist should instantly recognize the parallels that the light bulb problem represents. You should be able to translate that problem into computing terms on your own. Similarly, once you understand the rules of the game for the dragon and the knight, you should be happy to come up with an algorithm for the knight and the dragon to follow.
What you’re really doing by revolting against these simple metaphor questions is admitting that you think development is about only programming. It’s a tacit admission that you don’t devise algorithms. It’s a tacit admission that you don’t expect to solve (abstract) problems. There’s a term for programmers who don’t do algorithms and don’t solve problems: code monkeys.
So feel free to leave. That’s fine with me. I’m not a manager so I can certaintly write the god dammed login page myself.
September 22nd, 2008 at 4:01 pm
IMHO you are ~3/4 correct. These kinds of questions should invoke algorithmic response, but there is a reasonable limit. For example, the lightbulb problem:
I might start talking about binary-trees as a possible solution, but one can’t get more specific than that, because the problem doesn’t have any static variables except the 2 bulbs and the 101st floor. So, it is good as thought-exercise, and gives a vague understanding of the persons imagination/algorithmic-thinking… but that’s it.
September 22nd, 2008 at 5:16 pm
I’m not sure what you mean, kuratkull, about not being able to get more specific than that. It seems to me that the concept of a binary-search can be modified sufficiently with the given information to get an “optimal” algorithm for finding the answer.
October 21st, 2008 at 9:57 am
The light bulb question in a really interesting brain teaser. For an optimum search, one immediately things binary search. Except we have a “fixed” number of failed trials (defined as the bulbs breaking). The standard search would drop from five and then three. The problem is if both drops break the bulb, then we still don’t know if the first or second floor is the maximum height.
My solution to the problem involves a binary tree like kuratkkull suggested. Drop the light bulb at each node. If it breaks, follow the left leg, if it does not break follow the right leg.
__3__
/ \
1 _6_
\ / \
2 4 8
\ / \
5 7 9
Solution: once you test the leaf node you have your answer. If the bulb breaks, the leaf is the minimum floor the bulb will break at. If the bulb survives, the minimum floor is the value of the node +1.
October 21st, 2008 at 8:44 pm
Light Bulb Drop « Iced Penguin says:[...] Light Bulb Drop We want to figure out how strong our new super-strong light bulbs are. We know that they will be break when dropped from the top floor of this building (the 101st). We want to know the exact minimum floor from which a fall will cause the light bulb to break. You’ll be given two light bulbs for this task and we want you to do it with the minimum number of trials. – Louis Brandy [...]
October 29th, 2008 at 5:47 pm
Interesting binary search variant, but I think the challenge with these is coming up with scenarios in which candidates could imagine these being realistic constraints. My first reaction to this was that it’s clever as a puzzle, but horrible as a QA plan
If I were being interviewed to conduct any kind of testing, I’d be a bit worried that the puzzle was a metaphor for my testing resources.
November 2nd, 2008 at 9:01 pm
I’ve read your entire blog over the past few days, and really enjoyed it. The lightbulb question got me thinking, and I came up with an answer I like. Here it is:
drop the first light bulb once every 10 floors (at 10, 20, 30, etc). Once it breaks, drop the second bulb from the previous unbroken floor one floor at a time till it breaks (at 11, 12, 13, … 18). Worst case you drop the first bulb 10 times, and the second bulb 8 times. Best case you drop both bulbs once.
Furthermore, to generalize this for N floors:
take x=ceiling(sqrt(N))
drop the first egg once every x floors. Second egg drops maximum of x-2 times. Which means that worst case scenario for N floors is 2*(x-1) drops. I think. I had a lot of fun thinking about this.
November 1st, 2009 at 3:19 pm
Algunas respuestas y un problema simple « Spin Foam says:[...] (Extraído del blog de Louis Brandy.) [...]
November 2nd, 2009 at 11:46 am
La caída de las lámparas « Spin Foam says:[...] (Extraído del blog de Louis Brandy.) [...]