To use a recent movie quote: "If you can dodge a wrench, you can dodge a ball."
ITA's business is all about dealing with fiendishly clever transforms on small-ish sets of data, and the results are needed Right Now. Most of the hiring puzzles revolve around that theme.
Much like any other company giving these kinds of problems, it's not about bringing out that cleverness every day, but it's about figuring out who has the ability to think in that way, along with the persistence to work on the problem until it's done.
They produce more false negatives than false positives. If you aren't in a hurry to grow, thats a good thing. Even "cheating" (memorizing the techniques) to the point of being able to solve a problem on site (which is part of the interview) is not trivial.
Like you said, these problems filter out the people who would be great for getting stuff done and helping you build your software quickly (i.e. more practical people who find these problems a bother). But perhaps you don't always want that kind of person.
Personally, I find these problems interesting but the one I liked the most was the instant search because it had an element of user interaction rather than mere algorithmic problem solving, so I guess I might be the one filtered out :)
I solved the Instant Search problem when I was applying there for an internship. The puzzles aren't required for internships, but I figured it could only help, and I landed the internship. Was a great experience!
For my solution, I tried both tries and hash tables, and I found them to perform at more or less the same level. I later experimented with suffix trees, which I think is probably the best way to go for that problem.
I never liked the practice of hiring puzzles. I love coding useful things. Working on a hiring puzzle feels like jumping through hoops which is something I prefer to avoid.
Perhaps, but did you notice that one of the puzzles actually involves scraping through ITA's own database to find round-trip flights to Chicago? That seemed like a good touch, asking the interviewee to replicate a small part of ITA's own functionality so they could understand the magnitude of the problem.
Actually it sounds like a pretty easy problem from this far out, but maybe if I actually worked on it I'd discover it was trickier than I thought.
Sounds cool, I'd gladly do something like that if they were paying me. I think a good solution is to define a well-scoped project and bring candidates on board on a contract basis to implement them. This contract basis project can even be done remotely. This offers the candidate a chance to learn about you, you can learn about the candidate, and in the end you can both decide what is best for you.
