

Stupid Interview Questions - gchpaco
http://exold.com/article/stupid-interview-questions

======
philwelch
The point of the exercise is to see if the candidate can code their way out of
a damp paper bag. This is the kind of pedantic bullshit that's all about
showing how clever you are at the expense of understanding what's going on.

If you're clever enough to know that "copy a file" is an incomplete
description of what a user actually wants or needs, you should be clever
enough to know that "point out as many edge cases to confound a simple
interview coding question as you can think of" is not what the interviewer
actually wants or needs with that particular question.

~~~
jpwagner
dude, it's a friggin joke...

i suppose you don't find this funny either:
<http://www.bibliomania.com/2/9/77/124/21473/1/frameset.html>

~~~
rdrimmie
Yes, it's just a joke, but while it's a moderately entertaining implementation
of the FrustrateTheInterviewer response pattern it's really not especially
unique or noteworthy.

------
tptacek
At any point this hypothetical sequence could have been put back on track by
the interviewer saying "look, I just want to see that you can write simple
systems code, and I need to see you write a basic file copy". People laugh at
the interviewee, but in fact she's clearly crushing the interview.

I'd disallow the interview _er_ from doing that job anymore, I'd have someone
better question the interview _ee_ , and I'd probably hire her.

~~~
wglb
As an interviewer, after the third or fourth question, I would have said "If
you could, in addition to writing the file copy function, list all the issues
that you can think of that the code should take into account; the code sample
can implement a subset of these" thus giving the interviewee an opportunity to
show the familiarity with real-world concerns along with the ability to code.

------
mynameishere
"Write a file copy function" is suitable for basic vetting. The answer to his
3rd or 4th (whatever) question is, "Just write a basic file copy function,
thanks."

~~~
gchpaco
I dunno. The thing that sold it for me was this assertion:

    
    
      Q. Look, I’m sorry if you feel put-upon here, please don’t 
      get hostile. I’m just trying to get a clear picture of the 
      specs I need here. Obviously if I’m going to write a file 
      copy method, instead of using one of the many extant file 
      copy routines in various libraries and frameworks, it’s 
      going to be fulfilling a specialized set of requirements, 
      and I’m going to need to have good answers for these 
      questions. If you want, I can hack something together in a 
      minute, but I’d have to note that there were many 
      unresolved issues as to requirements and purposes.

~~~
swolchok
"The candidate has a myopic focus on documentation and best practices, as
demonstrated by his failure to apply a simple solution to a simple problem. No
hire."

~~~
xsmasher
I'd say pedantic and difficult to work with, but agreed, no hire.

The correct answer would be to write a simple solution and _note your
assumptions_ and point out the edge cases - but not in such an antagonistic
manner.

------
pilif
Also an interesting point to note is the fact that all questions are valid and
non of them are asking for too much detail. This leads me to think how complex
our world has become.

Features being added to the API and to the file systems lead to an ever
increasing complexity creating more and more opportunities for stuff to go
wrong.

And yet, despite increasing complexity, we are still asked to write bug-free
code and add even more complexity be it by stacking up abstractions or really
add more features to the process itself.

How long until a single person can't know all the steps involved in copying a
file any more?

------
pmorici
Not worth reading.

~~~
harpastum
Yes, the author is snarky and makes a mountain out of a mole-hill. On the
other hand, the basic point is valid -- interviewers often don't choose
suitably specific questions for on-the-fly implementations.

That's what I got from the article. Can you be a little more specific on why
you think that it's not worth reading?

~~~
smokey_the_bear
When I was doing a lot of interviews I often wanted to give a simple problem
that the person could code in 20 lines or so, and hopefully had another level
that could be discussed after they'd shown some code. I found it surprisingly
hard to come up with questions that could be explained quickly, especially
across cultural boundaries. Things like ransom notes and anagrams would really
just confound people to the point that they couldn't think about the
underlying problem.

~~~
ig1
Try fizzbuzz: <http://www.google.com/search?q=fizzbuzz>

------
olalonde
Bookmarked. Makes a good example of why requirements are important even for
something as seemingly simple as file copying.

------
motters
I've done a number of these tests, and typically they consist of
unconventional pointer arithmetic, designed to catch you out. Despite having
been writing software for the last couple of decades, I probably don't perform
well on these paper and pencil tests. My typical strategy is not to sit and
stare at code to determine bugs by intuition alone, but just to compile it and
see what happens in a much more interactive way, and I also make extensive use
of reference materials including the internet, books and previous code which
I've written to do similar things.

------
icey
When I interview people, I'll often ask open-ended or incomplete questions
because I want to know if the person I'm talking to has any critical thinking
capacity. If someone started down this road they wouldn't get very far before
I wrapped the interview up.

The business of software development very rarely comes with a full set of
instructions, I'm not sure why this guy has such a problem with being given an
open-ended question (and one that should be very easy to interpret).

~~~
nomoresecrets
Maybe, but a lot of interviewers ask questions like this because they love
being smug about catching people out for not asking about requirements before
starting.

I was in an interview where a couple of the interviewers asked me to do
something, and I asked some basic requirements. After a few questions they
just started grunting non-comittally and indicated I should get on an answer
the question.

The feedback from these interviewers? That I didn't ask enough about the
requirements/details before diving in to answering.

So I have sympathy for this guy.

