[jlees]

I think with a certain definition of training the argument works, but it's not clear if this is actually the definition they had in mind.

If you have the choice between hiring two people for an engineering position, one of whom can write code and one who can't, you'll probably want to pick the one who can rather than training up the one who can't. If your hiring efforts are lackluster, perhaps you can only attract the latter category of people, so you spend a lot on training people to simply do the jobs they're hired for. It's a bit like the Silicon Valley "senior engineers are impossible to find" argument right now. Nobody wants to take the burden of training a junior engineer into a senior engineer if they can hire someone who's already made their mistakes somewhere else. (Not a mindset I particularly agree with, since it implies a failure-intolerant atmosphere, but you get the gist.)

On the flip side, once someone is in a position that they are qualified to do, training for growth and development is a must-have -- 31 hours seems low to me. I definitely spent more than that in learning/development programs at Google, and I don't think that culturally they have an anti-training mindset, but I could be being too generous -- the quote on the site certainly reads exactly like your interpretation.