3 Apr
2006
3 Apr
'06
7:33 a.m.
Chuck Guzis wrote:
On 4/2/2006 at 8:30 PM Jim Battle wrote:
...
One question posed on this list not all that long
ago was: what is the
shortest program that you can run on an 8080 where the program will zero
all memory, including itself. or something like that. The puzzle is
probably equally interesting on many other cpus.
I've heard of people asking these types of questions during job
interviews -- and I think it is an asinine way of judging someone's
abilities.
I disagree. Consider that, as a manager, you might be looking at a whole
herd of people who have perfect university transcripts and impressive
resum?s. That mostly tells me that (A) they knew how to be students and
take tests and (B) had a very talented writer for their resum?s. Neither
tells me anything about their on-the-job capabilities and more importantly,
their ability to program. And I've interviewd enough people who can lay
down an impressive line of BS. An assembly language programmer that doesn't have
the dscipline to know his
instruction sets in detail and use that knowledge either writes horribly
bloated code or spends inordinate amounts of time because, for instance, he
doesn't realize that the 16-bit increment instructions on the 8080 don't
modify any condition codes or that the 8 bit increments don't modify the
carry bit.
Getting an indication of this right off the bat is much easier than trying
to figure out (A) where am I going to find another programmer to do what
this guy was hired to do and (B) how am I going to fire the current guy
without him filing a dispute with the state department of labor.
Sure, if the person advertises themselves as an expert on a particular
machine, then some trick or obscure question about that machine may be
appropriate. If you ask someone a question that has a particular very
clever answer, they get it right or they don't. If they get it right,
is it because they've heard it before or because they are clever? If
they get it wrong, does it mean that they aren't smart? I've also found
in most situations there isn't an oversupply of applicants. Tossing
them out based on a trick question is capricious.
It is much better to ask them a relevant question. Here is a block of
memory. Count the number of "1" bits in it. If they get it right, then
ask them how they might make if run faster. The best situation is when
people make a mistake in a corner case. Then you can give them an
example where their code doesn't work and ask them to make it work --
then you get to see them debug. Interviews often don't leave enough
time to get in to a real problem, so toy problems are used. In real
life most problems are complex enough that they never work the first
time and debugging is required.
When I ask a coding question, I always preface it with: I don't care
what language you use; I don't care about punctuation; you can even make
up a language. The only thing I care is that the algorithm performs the
task I specified. If I'm interviewing someone who has only ever used
vhdl and the company I'm at uses verilog, I don't care a whit -- if they
are capable, it will be a few weeks before they capable in verilog too.
The fact that they don't know the difference between "a = b;" vs "#0
a
= b;" vs "a = #0 b;" is not important.