I agree with what you say here, and that you need both 1/2s.

Reading code that other people wrote, especially with comments that OTHER people wrote in it, is the perfect way to learn. But ONLY after you have invested enough time with reference material and a bit of tutorial so what you read has a chance of being understood.

I interview and tech phone screen a lot of people. I read your link on interviewing, and I certainly agree with that. I do a slightly simpler version my self, but it starts with some silly syntax questions so I get a baseline of where people are, and then I ask them to produce a very simple filter script. Just as key to the code itself is what types of questions they ask me during the process.

Ben whipped it out in a single line, vs my 1/2 dozen or so. I have people who struggle for 20 minutes, come up with a couple of pages of crap, and it is obvious they learned (COBOL|BASIC|Pascal|C|C++|random crap) long ago, and are now writing it in Perl.

My interview doesn't hit that section until about 20-40 minutes depending on the flow, and then I have a few more minutes.

Including prep / review email, a typical interview costs me about an 1.5 hours. I've probably been bitten by 100 people in the last 5 years who don't know crap, but managed to get past the headhunter and HR to my interview, which means I lost 150 hours on them.

I want those 150 hours back!!!

(whine, whine, whine)