This is an appealing idea, although I haven't done it, or seen it done anywhere either. The discussion would seem to lend itself nicely to finding out how the applicant thinks. Your analysis of the difference between understanding the two forms seems spot on. However....
in reply to Re: How to measure Perl skills?
in thread How to measure Perl skills?
As others have said, the key is still in the discussion more than in the "factual" answers.
I don't actually completely agree with this. The CTO's point in requiring the test in the first place is at least partly to find out whether the candidate can not only "solve the problem", but can also get their solution to work. By way of illustration, when I took the original test here, it took me 10-15 minutes to basically understand the code I was given, another 5 minutes or less to "get" what I needed to do, and then over an hour to actually get my changes to run! (A pathetic time, I admit, but in my defense I hadn't programmed in nearly a year at that point, and hadn't written any Perl in nearly 3. I'm much faster now.)
So I'm thinking about a variation of this idea in which the "new style" is only partly written, and the test is simply to finish it. This could have the added benefit (I think its a benefit) of demonstrating how well the applicant can grok and match the style of existing code.