Re: interviewing tips

["M. Dannenberg" <midannen -at- SI -dot- BOSCH -dot- DE>]

In an episode of Northern Exposure, Fleischmann says: "If you want to
catch fish, you have to think like a fish." If you want to catch geeks
you have to think like a geek. A large part of any geek training
consists of stuff like "this is algorithm A, this is algorithm B.
Compare them and say which one's better". The answer is usually "it
depends on your application". Another all-time favoured is comparing
programming languages, like "what are the performance issues when
comparing C to C++", etc.

The more geeky your questions are, the more inclined the geeks will be
to answer them. If you ask "what's a method?" the geek will groan and
think "Oh my god, what a clueless idiot". If you ask "what's the
difference between a method and a procedure?" he/she'll more likely than
not launch into a little lecture about the relative merits of precedural
vs. object oriented languages.

I've also often found that challenging their design decisions is very
effective. They don't take this kind of thing personally, because that's
the kind of stuff they talk about with other geeks all the time. So if
you ask "why did you use the LaForge algorithm and not the Picard one in
your Heisenberg compensator?" again you should at least some kind of
response, and maybe even some useful information.

As many people have said already, do your homework. The easiest way to
find common ground with geeks is to know as much geek stuff as possible.
It certainly helps if you've had some kind of computer science training,
or at least have knocked together a few BASIC programs.

Mike

--
Mike Dannenberg
ETAS GmbH & Co.KG
midannen -at- si -dot- bosch -dot- de

	http://www.documentation.com/, or http://www.dejanews.com/