Ben Barrett wrote:
> As for integer sort and binary search, I know very few programmers
> who would do this from memory in 30 minutes.
"Would" is different from "could". Besides, it isn't a test of
memory, it's a test whether the candidate understands the algorithm
thoroughly enough to recreate it from scratch. I would absolutely
expect anyone who joins a development group I'm in to be able
to implement those two algorithms easily.
But I wouldn't ask an interview candidate those specific questions
they're identical to problems you've seen in algorithms or data
structure class. There is a chance that the candidate will remember
the solution rather than inventing it.
At Convex, we interviewed about a trillion new graduates for
software positions. We relied heavily on the problem we called
"moving zeros". It went about like this.
Given an array of integers, write a routine in the
language of your choice* that will move all the zeroes
in the array to the end. Please think out loud as you
solve the problem, and write the code on the white board.
It's an easy problem so you can reasonably expect it to be done in
10-15 minutes. We asked it of so many candidates that we had
identified three basic solution strategies. Eventually we dropped it
because students knew to expect it and prepared for it.
Followup questions for the unsuccessful were designed to draw out bugs
that testing would have found if a real computer were used: "What is
the value of i at this point?" "What does your code do if the array
is empty/has no zeroes/is all zeros?" "Step through your algorithm
with this input: [1 0 -1]." (input carefully chosen to expose a bug)
We learned about their problem solving ability and watched how they
debugged their code.
Followup questions for the successful were about runtime complexity,
testing strategy, and a harder problem to solve,
I am a strong believer in this kind of interviewing if you're hiring
someone for a software development position. No amount of discussing
past projects and design philosophy or reference checking will give
you as much insight as watching someone write 15 lines of actual code
on a whiteboard.
Microsoft is famous for interviewing this way. When I interviewed at
Juniper last year, an ex-Microsoftie in the group asked me to
implement fair multiple reader/single writer locks using the Intel
CMPXCHG instruction. He was happy to explain exactly how CMPXGHG
works -- he wasn't testing my familiarity with the IA32 architecture.
* This was before the advent of scripting languages, Java, or C++, so
the candidate usually chose C or occasionally Pascal. Today, I'd
require it to be in a "real" language, either C or Java.
--
Bob Miller K<bob>
[EMAIL PROTECTED]
_______________________________________________
EUGLUG mailing list
[email protected]
http://www.euglug.org/mailman/listinfo/euglug
