I need to be amused

Aug 25 19:32 UTC 2007

Maybe Cross, Remmmers (if he isn't ignoring me), Mcnally, or any other
person that has an iq 2 points higher than nharmon can explain to my why
that during programming interview, half the programming questions they
asked me are just fagged up math problems.

When I went to the second interview for the junior level C++/Java
programmer job at askjeeves.com, half of these questions revolved around
doing run time analysis on associative array, memory reallocation, and
how this was related to the cache.

If I get hired, do these fags really expect me to break out the funky
power series and funkier statistics to determine the theoretical upper
and lower bound on an algorithm? Isn't this why you hire a math person? 

response 4 of 21:

Aug 27 01:44 UTC 2007

Well, when I do an interview, I'm most interested in two things: seeing the
candidate's thought process, and seeing the depth and breadth of his or her
pre-existing experience.  The former is more important to me than the
latter.  To that end, I do ask sort of strange, math-like questions, not
because I care whether the candidate really knows the answer, but because
they're unlikely to be familiar and I want to see how s/he reacts and goes
about solving the problem.

Here's an example of a question I usually ask: If you had to sort an array
of 10 integers, what algorithm would you use?  What about an array of
10,000,000?  The answer I'm usually looking for is, ``what's wrong with the
system sort?'' but frequently candidates resort to reaching back to the
mid-level CS education McNally mentions and start trying to think about time
and space complexities, in some cases just pulling names of algorithms out
of thin air (I've heard, `heapsort' for 10 integers followed immediately by
`bubble sort' for 10,000,000).  Those candidates who *do* say, `why not just
call the library sorting function?' tend to be superior (they have already
realized that the overhead of calling the system sort is likely to be small
for a small data set, unless this is in some sort of tight loop, and for a
large data set, the well-engineered implementations in the library tend to
do well).  Again, it's not that I'm looking for big-O analysis, but rather
an engineering mindset.

Another question I've asked is the following: In C++, the STL contains the
`map' class which is a generic associative container.  Most implementations
use some sort of balanced binary tree structure as the underlying storage
structure; why that, instead of a hash table?''  There are three answers
that I look for (I'll leave them as exercises to the reader), and I ask this
question because the answers require some understanding of computer science
fundamentals (data structures, algorithms and algorithm analysis, etc), but
in an engineering context: someone in the real-world implemented this and
made a decision about to how to do it.  Why?  These are, conceivably, the
sorts of engineering decisions that an engineer in my group may need to
make; are they going to be able to?  Of course, they won't have to do that
*every day*, but then you can hire almost anyone to take care of the day to
day nonsense.  Asking that sort of thing is uninteresting.

response 6 of 21:

Aug 27 02:32 UTC 2007

Cultural issue.  What, I'm such a genius that no one can challenge me?

response 8 of 21:

Aug 27 02:43 UTC 2007

Apparently not

When people are asked questions in the context of a quiz or a test, they're
going to tend to answer within the bounds of the question because that's
what's done, uh, culturally.  There's no reason to think this would reflect
on what they'd do while actually on the job.  Of course, if you want to
disqualify people for things that have no bearing on how they'll actually
perform, that's your perogative

response 10 of 21:

Aug 27 14:10 UTC 2007

(Well, I do usually say, ``how would you sort n integers...'')

response 12 of 21:

Aug 27 17:53 UTC 2007

Nits.

response 14 of 21:

Aug 28 21:06 UTC 2007

Re resp:8: Ah, but when you're hiring for a job like that, do you want
someone who's going to slavishly follow what they think you asked them
to do?  Or do you want someone who will come back and say, "maybe it'd
be better if we did it this way"?

response 16 of 21:

Aug 29 04:42 UTC 2007

Right, and as I said in that response, there's a huge difference between what
most people will do after they're on the job than what they do in an
interview.

Don't respond to me if you're not going to read what I write.

response 18 of 21:

Aug 29 16:33 UTC 2007

cats

response 20 of 21:

Jan 17 13:09 UTC 2008

Even if the job had nothing to do with math?