When I interviewed at Garmin they gave me a couple pages of their actual code and asked me to point out the bugs they introduced to it. Thirty pages seems like a bit much for an interview, but I definitely like the idea. Most jobs you'll be looking at other people's code way more often than writing your own.
I really like this idea, but it's not easy to apply. Nowadays, most jobs involve writing code that are based on layers and layers of abstraction, so a lot time, you have rely on the API/docs that are given to you.
On the other hand, if the job requires a lot of algos and low level code, this will be a good test to gauge an engineer's thought process and mental capability.
Many libraries and abstractions that I come across don't have much/any documentation (or it's out of date, etc), so the ability to quickly look at the source and understand it still seems valuable to more than just low level programmers.
I recently interviewed with one of the "big 10" tech companies and was asked to do similarly; I was given 4 pages instead of 30. I felt like it was a good and useful exercise.
I've done this for interviews - we showed them some code that had real bugs in it, as well as some poor design choices (we told them this in advance so they wouldn't think our real code was like that). We were looking for people who weren't afraid to tell us the code sucked and what they'd do to improve it. If they said it was fine as-is, or spotted very few of the bugs, that was a strong no-hire indication.
We tried sending the sample to them the day before, but there wasn't a strong correlation between doing that and good responses from the candidates. Basically, if they got it, they got it. And if they didn't, they didn't.
