Hacker News Reader

Comment by bfung | Hacker News Reader

How are these puzzles hypothetical? They look better written in specification than specs in the real world:

  (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

Some test simple programming skills (Hoppity Hop is basically the Fogbugz for-loop question + no brainer file parsing) and the harder ones seem to involve knowledge of (not too tough) algorithms.

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

View on HN

Hoppity Hop is basically the Fogbugz for-loop question + no brainer file parsing

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.

"Why not give me a real world use case, with a code base to work off of?"

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)

As someone with a lot of industry experience: It's great to know how people solve puzzles and tackle algorithms. It's even better to know how they can fit those solutions into a bigger picture, how they structure, comment and document their code, and how they interpret a use case and user stories.

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.

Because the people you want most aren't going to waste a ton of time jumping through hoops? The nice thing about puzzles is that they're self-contained and can be understood and solved in a few hours. When I was applying for a Facebook internship, I wound up spending ~6 hours over a couple of days finishing two of the puzzles. This already seemed like a significant time investment. A problem that involved "a real world use case, with a code base to work off of" would necessarily take a lot longer to understand and implement. I was pretty busy that month, and if the puzzle questions had been more time-consuming I might have skipped Facebook and applied to other companies instead. (As it happened I wound up at Google)

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.

That's confusing to me, 6 hours is more than enough time to implement a small but significant feature. I think it's possible you're assuming the request would be a particularly large one.

Reply on news.ycombinator.com