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? 

21 responses total.

My experience with programming interviews is that they very rarely
have much to do with what you end up working on if hired.  So to
answer your last paragraph first, no, that's probably not what they
expect you to spend your time on if they make you an offer.

My next observation is that questions that sounded like they came
off a mid-level Computer Science class's exam often came from people
who struck me as having a mid-level Computer Science mindset.
All I can surmise is that when they were trained, that's how they
were tested and they haven't arrived at any more apt or creative way
to test people for their own purposes (which are probably not the
same as those of computer science educators) so that's what they
fall back on.  The more interesting places I interviewed usually
gave me more interesting, open-ended questions.

And my final observation -- in most interviews for programming jobs
the interviewer asks at least a couple of questions for which you are
not expected to have an answer handy.  The goal of these questions is
*not* to test your direct knowledge, it's to test your though processes.
They hope to gain some insight into how you will react when, inevitably,
you find yourself stuck without a ready answer, dealing with a problem
where you can't just look the solution up.  Ironically you are *extremely*
unlikely to encounter such a situation as a junior-level developer in
most shops.

This response has been erased.

Okay, that makes some sense. The rest of the crap the stuff they asked
me was pretty trivial. Ie, inserting and deleting nodes on a linked
list, reflection, etc.

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.

What about the people who would ask themselves why not the system sort, but
realize you asked them what algorithm?

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

This response has been erased.

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

I would agree with scholar on this one. If asked "which algorithm" a
candidate would prolly be thinking in terms of the different algorithms.
But if he/she is asked how are you going to sort? he/she will prolly
answer system sort etc depending on what he thinks he/she is going to
use.

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

(But you *did* say "what algorithm" in #4...)

Nits.

Cats

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"?

Yup, there's that too.

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.

What'd you say?

cats

I would never interview someone with math problems.

Even if the job had nothing to do with math?

If they can explain a math problem in english then i would consider continuing
the interview

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss