Research skills are always more prized than memory. The engineer's hierarchy is never to compute what you can measure, and never measure what you can look up. (Although sometimes the last two are reversed, depending on context.)
When I interview C programmers I always ask them to write code on the whiteboard to sort an array of ten integers using the Quicksort algorithm.
Here is the correct answer (apologies to non-programmers):
Code:
int array[ 10 ]; /* presumed initialized */
int compare( const void *a, const void *b )
{
return *((int *) a) - *((int *) b);
}
qsort( array, 10, sizeof( int ), compare );
For the non-programmers, this simply invokes the C library sorting function, which is implemeted as Quicksort.
The next most correct answer is "Knuth, volume 3" referring to Donald Knuth's seminal
The Art of Computer Programming. That is, the candidate knows the proper reference for finding a definitive implementation of the algorithm.
The next most correct answer is "Why does it especially have to be Quicksort?" indicating that the candidate is willing to challenge the assumptions on which the problem is based and think outside the box. There are many methods for sorting data, each with attendant strengths and weaknesses.
The
incorrect answer is an attempt -- successful or otherwise -- to write out the Quicksort algorithm in C.
Why the devious approach? Few people have the Quicksort algorithm memorized correctly, which means an engineer who tries to reconstruct it from memory will waste time getting his implementation to work. There's no advantage to reinventing that wheel. A good C programmer knows what's in the standard C library and how to make effective use of it. The C library implementation of Quicksort is fully debugged and likely optimized for the particular computer. Too many software engineers are eager to build systems from the ground up instead of building on what's already there. And finally, if for some reason you can't use the C library (e.g., you're on an embedded system), then for heaven's sake make sure you get it right when you type it in. There's no shame in having Knuth's books in your lap when you have to recreate these basic program elements. You get full points for doing your best to get it right the first time.
Other engineering disciplines aren't usually as susceptible to this point as software engineering simply because they're more used to working from references and consulting appropriate printed authority. But still, the ability to get it right by knowing where to look is the prized skill.
[/code]