djdoboy
|
|
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?
|
mcnally
|
|
response 1 of 21:
|
Aug 25 20:36 UTC 2007 |
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.
|
djdoboy
|
|
response 3 of 21:
|
Aug 25 21:23 UTC 2007 |
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.
|
cross
|
|
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.
|
scholar
|
|
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
|