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.

If you know enough to ask these questions, doesn't that prove that you can, in fact, code your way out of a paper bag? Each question he asked is basically the pseudocode representation of a diff to add each branch or feature to the code.

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

It is a joke, but I've heard similar sentiments expressed seriously so I made a serious response.

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.

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 interviewer from doing that job anymore, I'd have someone better question the interviewee, and I'd probably hire her.

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.

Crushing the interview, but failing the interview badly by failing to see the reason for the question. I'd end that interview early, not because of lack of tech skills, but because the interview is an ass.

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

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.

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

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.

The problem is, this is exactly the same kind of argument you'd hear from someone whose programming ability extends merely to the ability to string together API's, or from MIS students who don't understand the point in learning how to write a compiler or OS kernel.

Alternatively, you also hear the same thing from the types of people who want to sit down and gather ALL the requirements before writing a single line of code, rather than just prototype and iterate.

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?

Not worth reading.

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?

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.

Try fizzbuzz: http://www.google.com/search?q=fizzbuzz

Well, for one, if someone doesn't specify something you should have enough initiative to make an informed decision on your own instead of, as this author is suggesting, acting like a conceded ass.

Two the "valid point" could be summed up in a sentence not two pages of text. Hence I felt is was a waste of time to read as there wasn't anything that was particularly insightful and the writing wasn't particularly good.

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

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.

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).

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.