That's what I thought before I joined. Once I got into the swing of things and started doing actual work, I was like "Goddamnit. We need <i>more</i> employees. There's too much work to do!"<p>The simple, non-confidential answer is that running a global service used by billions of people entails facing a lot of problems, on a daily basis, that most developers will never face. And that makes everything move slower.<p>Have you ever internationalized an app? It's not just a matter of translating every string in the UI, although that certainly is a pain in the ass. You also need to handle right-to-left text and mirrored UIs for Arabic/Hebrew/Farsi, and English text mixed in with that mirrored text (this is common in Israel) which requires a directionality reset. Did you know that you're not supposed to bold Chinese characters? The typographic convention is to make them red for emphasis - but <i>only</i> Chinese characters, English text embedded in Chinese characters (eg, "President Obama" in a Chinese news article) should still be bolded as necessary, so you can't just use a global CSS rule. You know that several European countries format a million bucks as $1.000.000,00 instead of $1,000,000.00, right? And dates go DD/MM/YYYY instead of MM/DD/YYYY, and your date parsing routines have to understand that as well as your date display routines. Ever dealt with Russian plurals? In English, you know something is plural based on whether it's one or many; in Russian, it's based on whether the last digit of the number ends in 1, 2-4, or 5-0, and sometimes depends upon its position in the sentence. Can you do case-insensitive comparisons in multiple languages?<p>And every single UI engineer needs to be familiar with these pitfalls. A lot are hidden behind frameworks and utility functions, but then every single UI engineer needs to learn the frameworks and utility functions, and understand the purpose behind the libraries so they know when they're appropriate to use.<p>Do you worry about efficiency when you program? Most programmers these days grab something like Python or Ruby whenever they need to do something, but doing a complex parsing routine in Python can easily run 100x slower than doing it in C++, and at Google scale that means 100x more machines. There are a bunch of open-source libraries for the type of internationalization problems above - but the ICU libraries can easily pull in 50M or so of data files into RAM. If you're running on 20K machines (number pulled out of a hat), that's a <i>terabyte</i> of additional RAM consumed because you wanted to use an open-source library. Do you care about end-user latency? Most webdevs these days take for granted that they'll have JQuery or Prototype available to deal with cross-browser differences. One of the first things I did when I joined Google was try to convince them to allow JQuery for development, and as part of that I ran an experiment to figure out what the actual user impact would be. It turned out it would've <i>doubled</i> end-user latency of the time, and so we had to keep writing everything from scratch based on browser primitives.<p>Then there're all the issues surrounding running a massively distributed system. Machines fail, packets get dropped, and you have to handle those failures gracefully. It's impossible to upgrade a distributed system all at once without downtime, so every time you make a change that crosses a component boundary, you need to make the new component backwards-compatible with the old one and run both versions of the code in prod until the whole fleet has been upgraded. Many familiar algorithms that work on one machine don't parallelize effectively, so you're limited to what you can compute. Even if they do, the standard libraries for them usually assume a single flat address space, and so you have to really understand the algorithm and how to convert it to a distributed network of computers, and then reimplement it yourself.<p>If this sounds exciting, we're still hiring. :-) If it doesn't, well, if your startup gets big you'll have to face these problems anyway. Hopefully you can hire someone who finds them exciting.