In one large company I worked for, with a graduate recruiting program, the newly hired graduate spent a week or two in second-level and third-level support before starting in a dev team.

This is an excellent practice, because it gives the newbie exposure to what the customer is trying to do with the organization's service/product, and shows where people are having problems. That experience puts them in the right headspace to look at the code behind the current system.

".. thousands of files and no documentation" .. Interested to learn the history of that one!

I'm not really sure about the history .. this was code that had been in place for some time. It was what I thought of at the time as a Super Application because it did so much stuff. Unfortunately, most of the POD was still the original boilerplate, and I can remember the test script for one of the modules was

use_ok ( ModuleName );
ok ( 1 );

done_testing;
[download]

I think it was 2-3K lines of code.

Pair programming can also work well to bring new hires up to speed fast.

Sure, I'm a fan of that for getting people started. I got a little pair programming at a recent job -- I watched, while this ace developer zoomed through a solution at blistering speed, both in his typing and his speech. I got most of it, but I certainly would have benefited from a slower presentation, just because it was like trying to drink from a firehose.