I don't know. Being tested in an interview just never sat well with me. I
never minded them want to see programs that I've written or college projects
or even just asking me questions to test my knowledge. I also never liked
being called up out of the blue by a possible employer and being asked to
send my transcripts--I told them my transcripts were none of their business
(if they were planning to interview me and wanted me to bring them, well
that's a different story).
I guess I understand you wanting to gauge what they REALLY know (we seem to
have a lot of "know-it-alls" in this field who don't. Why is that?). I
don't have a better solution, but I still hate being tested in an interview.
One thing we do do is hire co-ops that have impressed us with hard work and
aptitude.
As an extreme of my distaste for this is an article I read in a C/C++
journal (I forget which). In it the author kept patting himself on the back
for his guru-like knowledge of C's darker recesses (of which, some he was
actually wrong about). The article was mainly about how he would test
interviewees on this knowledge, and how most would fail (and gee wasn't he
smart for knowing what they didn't). He stated things like how the people
should study the operator precedence table before an interview! Now, we
know how that can get you into trouble when the operator precedence table
and the standard's parser rules collide (like with cast operator when
dealing with parentheses). What a waste of time for his company and the
applicant.
I'm less concerned with a new hire's impressive list of languages he know
intimately. I like new hired that have the ability apply knowledge than
regurgitate information. That's what reference material is for.
DrX.