Wednesday, August 17, 2005

Boo to Brainteasers

I enjoy brainteasers as much as the next person.

No, that's not true. I enjoy brainteasers much more than the next person, who typically despises it as an exercise for braniacs on crack. The crack part, though, would probably be detrimental to solving problems.

Microsoft and companies aspiring to be Microsoft often use brainteasers as a means to interview candidates. The hope is that a clever person, who can figure out a brainteaser also has what it takes to write good programs. Well, clearly this isn't really true because there are plenty of folks who are good at brainteasers (say, mathmaticians), who can't program a lick.

Programming well is a particularly difficult skill. It requires the ability to reason at a high level, similar to the kind of reasoning that might go on in brainteasers, reasonably detailed knowledge of a programming language, but also the ability to deal with lots and lots of details.

Think of an event planner. Such a person has to coordinate many tasks with many people, including money, space, timing, backup plans, and so forth. Programming requires a similar skill. You are managing hundreds of thousands of lines of code, where the smallest little glitch can cause the program to crash or at the very least, produce incorrect results. How do brainteasers help there?

Off the top of my head, here are some of the skills needed to program well:

  • Proficiency with at least one, if not several, programming languages
  • Ability to learn or use an IDE
  • Ability to understand CVS, etc. (tools outside of programming)
  • Know what other technologies are out there, and evaluate them, and use
    them properly.
  • Be familiar with algorithms

You see, brainteasers are told in an extremely confined information space. You
use your ability to reason about things you know well to solve the problem. It
requires very little domain knowledge.

On the other hand, real world programming requires an understanding of all of
technology. RSS, HTML, HTTP, SQL, XML, UML, and on, and on. Brainteasers is
like Macgyver trying to escape out of a trap using bubblegum. Programming
is like sitting in front of a tool chest of hundreds of tools, half of which
you've never seen or used, and trying to figure out how to use what you have.

And worse still, programming is filled with arcane rules, arcane exceptions,
minute details, any of which can come up and bite you, when it comes to writing
reasonably bug-free code.

Yet, these brainteasers persist. How does a limited domain problem that can
be succinctly described in a few sentences allow you to solve huge coding
problems. It's all correlation. A person who can figure out brainteasers
is, in principle, able to write programs.

I liken it to the "combine" which is a camp of sorts for those interested
in being drafted by the NFL. College players run through a battery of
tests, such as running a 40 yard dash, and scouts determine, from these
series of numbers (and some interviews to judge personality), whether a
person is ready to take the next step and perform at the highest levels
in football.

Yet, because the tests in the combine is not football, you're just guessing,
and you're as likely to pick a bad person as a gem. I'm sure it's better
than nothing, but how much better.

I'm not saying I have answers to this. It just seems, to me, that brainteasers
aren't all that related to programming, even if solving them may indeed be
correlated to writing programs that work.

No comments: