(I ask this from the perspective of a young, inexperienced developer.. so excuse the thoughtlessness!)

I don't mean to imply that you are unable to think, of course - the puzzles are surely an imperfect heuristic - but that's my understanding of their aim.

  (selected few and summarized...)
  Hoppity Hop! 
  Input: filename as arg from command prompt, file contains a number
  Output: Some variation on the word "Hoppity" repeated

  Simon Says
  the gist: Connect to some server, call some api's in a certain order.

  Battleship - write a client that connects to some server that plays battleship...

  Find Sophie - read some data,build some data structures/run algorithm,output result
  Input: filename and specifications of the file format
  Output: result

If the questions were more like "How would you move Mt. Fuji", then that's certainly hypothetical.

Why not give me a real world use case, with a code base to work off of? Put up a codebase on github, provide a set of user stories and requirements to satisfy (ie, "add a real time search using this data set and code base which works cross-browser and degrades in IE"), and ask me to add it, thus basically mirroring a normal development process.

As someone who has had to interview programmers before, that would tell me infinitely more than their ability to re-iterate the word "Hoppity" on the command line.

Puzzle-based interview questions are meant to be a rough cut to weed out the people who are clearly unqualified for the position. They're not meant as a substitute for more in-depth discussion of skills, work experience, etc. If the filter is too time-consuming, it's going to weed out some of the best people who are confident they'll get offers from other companies. And a large company like Facebook doesn't necessarily want to test specific skills because they may not have yet decided which position you'd be hired for, and in any event you're likely to work on multiple projects during your time with the company. For entry-level positions (which is presumably what these questions are designed for), it's better to hire the smartest guy you can find and train him on specific technologies than to hire a guy who already has a specific skillset and then discover he's a one-trick pony.

Because they want you to be good enough to do it without that.

(I'm saying this as an about to be new grad who is studying these subjects to not have that much help and have to do it on a whiteboard in an interview

and also working on these puzzles and similar ones from a lot of other companies)

Dealing with things in the abstract, stripping it of context, interface, interaction, and real world requirement, seems to be an incomplete way to understand the capabilities of the person you're potentially hiring.

Unless, of course, you're hiring for the position of Junior Abstract Puzzle Solver. In which case, by all means, Godspeed.

If you consider the fact that:

- It is unlikely I am well-versed in the problem domain of your code,

- I am unlikely to be aware of external design constraints or coding pressures,

- I am probably going to randomly select the worst section of code to review,

- I have no context for how the code evolved

the chances that I walk away with a negative impression are high enough that it should give you pause. If I do manage to walk away with a positive impression of your code, it will be offset by the perception that you believe your time is more valuable than mine (why else would you send me a massive amount of code and ask me to review it to determine your suitability for a position) - and you still haven't answered the other big question I need answered which is whether you are a good "fit" for the team from a personality/cultural perspective.

If you really want to impress me, go ahead and send me a list of your projects and contributions and then slice a relevant sample of code from it. Describe what the problem was and how you solved it so I can understand the context. Try to make it relevant to the position, but failing that describe how you could utilize that experience in the relevant domain. Keep it small enough that I can review it in under an hour or two.

Is it a lot more work for you? Absolutely, but if you do this I guarantee you I will look at your code and will likely call you for an interview because you are demonstrating a high level of competence and professionalism while still respecting my time and needs.

It's presumptuous that I would be asking you to do a full code review (my Appleseed project is tens of thousands of lines of code, for instance), and that I wouldn't recognize the impracticality of such a request.

I would find it problematic, then, if you responded with tests and puzzles, without any interest or questions about my code. Or if the test and puzzles couldn't be skipped once I mentioned my experience level and accomplishments. This is often what interviewers have done, and I find it to be a good indicator of a workplace I'm not interested in working in.

The best workplaces let their developers take some time to comb through the best parts and the worst parts, and have a conversation about what I've done, my goals, how I did things, etc.

And for the record, I don't like "puzzles" either - even if I know the "trick" to the puzzle, sometimes my brain doesn't work right and I can't think of it after a long day of interviews. I would much prefer to be evaluated on how I work in a real environment, seeing my real code and my approach to real problems as opposed to impossible problems whose solution hinges on an obscure bit of semantic parsing in order to arrive at the solution. But as an interviewer, I don't have unlimited time to evaluate candidates so if you want me to do something, it helps to make it as easy as possible for me to do it.

In the end, I don't disagree with you, but I can understand interviewers that don't make the effort if you don't also make an effort.

I think it's fair to assume that after my years in the industry, that I would not simply hand you a link with no context, nor that I would be applying for a job which didn't relate to the work I had done, and I don't feel these arguments apply to the situation I presented.

But as far as I'm concerned, my preference would be to hire based on established code and real world tasks, not abstract puzzles. Not only are puzzles like these faddish, I've met too many programmers who excelled at puzzles, but were severely lacking in more mundane (but all too necessary) departments, so in terms of what kind of things I would use to weed people out, I'd do a set of real world tasks like the one I mentioned above, well before I'd ever give a list of clever puzzles to solve.

Assuming the applicant didn't contribute to open source, which would always be a huge plus in my book.

However, that leaves a whole lot of candidates out of the picture. Faced with limited recruiting resources, puzzles are about the next best thing to serve as a recruiting filter. Plus some people send them in without being told to, which is usually a plus, as it implicates coding in their spare time is something they enjoy doing.

But it is important for Facebook - so that's what they test.