Seems to me like, you may not be as good as you think. If throwing a RSS feed at throws you then how you going to deal with real life legacy(sometimes not so legacy) crazyness?
Maybe I'm biased (no Objective-C experience), but in the platforms I work with this is a 15-minute task, so I wouldn't hire either. There is nothing extraordinary about being familiar with XML or regular expressions.
Take your point, and it's probable that the employer had other concerns and picked a covering excuse.
(Some Objective-C flavour: NSXMLParser is a more appropriate solution than the one described)
One reason I picked 90 minutes for my example is that I was imagining a hypothetical task, and I don't think you would/should be left sat at a task for 2 hours where 15 mins was expected. I hope that wouldn't happen.
While this may be true, the guy who has worked a bunch with RSS feeds will ace this question even if he is a substantially worse developer. This wouldn't be a problem if said technology was what the company actually used, but in this case it was not.
We're talking about XML basically. So he would have had to deal with the data in JSON if he had access to their API or XML in the test. Traversing XML isn't exactly the hardest thing to figure out and it took him an extra 100 minutes or so to figure it out. I personally consider the ability to learn one of the key things needed in a developer as you're constantly having to learn new things to achieve things you've never done before.
The guy actually learned the tech in less than 2 hours under pressure in an unfamiliar environment. If you fail him for that, the message you are actually giving is "I don't care if you can learn, every minute count in my business and if you don't know something you are out."
Wouldn't you expect someone who had never seen or heard of RSS before to be able to do a bit of research, find out what it is and work out how to parse and give an account of the steps they took?
A good candidate who had never seen RSS before might be better at that than someone who has spent their entire career processing RSS and never thinking about the details.
Fairly easily? If you're maintaining legacy code, here's what happens: you dive in, are horribly confused, and figure it out. Aaaaaaand...now you know it. Who cares if it took you three days to figure it out? You're going to be maintaining that codebase for a long time, aren't you?
We're kidding ourselves if we believe that our dev work is "all-new algorithms, all the time." It's not.
Who cares? Stakeholders who are pissed of the legacy system isn't working and want it fixed now. If it's legacy and you're changing it, it's generally because it's broken and someone finally noticed.
In my experience, cases where the system needs to be fixed right now are fairly rare, and in those cases the task is usually delegated to the person with the most system experience anyway.
But if the only reason they hired someone else was because of speed, it seems really unreasonable. If he needed to spend 30 minutes reading about RSS and did a good job in the end, it really doesn't matter if he spend a little more time.
Consider the following two developers. Who would you rather hire, and who will get hired under this system?
1. Developer completes the task, unfamiliar to them, in 2 hours, or
2. Developer completes the task, familiar to them, in 1.5 hours?