I was a lowly software engineering intern at Google and spent most of my summer writing MapReduce jobs which would traverse (1) every document in a large index

I was a lowly software engineering intern at Google and spent most of my summer writing MapReduce jobs which would traverse (1) every document in a large index of the web or (2) every book Google has scanned. Even worse, I sometimes needed to compute correlations between pieces of text in the documents. So, not only was the input size huge, the work per document was non-trivial. The remarkable thing about this sort of gig is how utterly unremarkable it is in a large tech company. If there's anything to Big Data beyond hype it's the commoditization of previously incomprehensibly large computations...and everyone doing computation on that scale should at least know the basic language of reasoning about time/space/communication complexity. You don't necessarily need to know the official jargon (though it helps to concisely describe ideas), but you should at least be able to think about how much extra work your program does for each additional input item (and how much extra storage it needs, and how network bandwidth it will eat up).