The message that I am getting from this fictional interview
question is, “Please solve this ridiculous problem to prove to me that you are
intelligent.”
This line of command and performance encourages pride in
being able to solve the specific problem without placing the problem in
context. It sends out a false sense of security in being able to do whatever it
takes to get the job done. It encourages “hard coding” instead of developing once
for many problems.
And talking about
this matter instead of writing code
in this post is just me showing many sophomoric folk out there in the “real”
world that I am simply stalling because I cannot solve the problem. I am using
my slick talk to slide out of getting “real” work done. Right?
Many, many years ago, I failed to answer a job interview
question where the interviewer was measuring my experience with VBA by finding
out if I knew whether the StrReverse()
function existed or not. What the interviewer would never know is that I wrote
all of my string handling functions years before the interview and years before
the StrReverse() function
appeared in VBA. So I was doomed because I was unaware of this new function and
I failed to memorize my own code that worked so well I forgot about it!
I will have the same problem now with C# because I fully
intend to write my code so well that I won’t need to memorize every algorithm
just to impress an interviewer. In the same manner that writing in Microsoft Word
2003 does not improve spelling skills, writing good code does not help me
remember every algorithm under the sun. “Good” code is meant to be
forgotten—and “good” documentation helps us remember in the appropriate
context.
To me, the best way to interview a programmer is to put her
in a room with a computer, tell her what the problem is and walk out of the
room with a promise to return in 15 minutes. Very, very few programmers get the
opportunity to stand up in front of a white board and “lecture” to people about
solving the problem.