There are pluses and minuses to working for Google. On the plus side, they pay well, your colleagues will be uncommonly capable, and you'll get a chance to work on a vast scale. It's cool.
On the minus side, the company is very, very strict, particularly around its codebase. For each language, there is an extensive set of coding guidelines (actually rules) covering even minute issues like spacing. And it's actually enforced. If you're looking for a high-trust environment, or just some elbow room to do things your way, stay the heck away.
The company is also very bureaucratic, particularly around hiring and promotion. Promotions are done by independent boards, based on extensive documentation (the "perf packet") provided by the candidate and his manager/lead. At this point, these packets are hefty enough to beat a man to death with. To submit code, you'll also need to get certified for "readability" in each language you will be working in, a process that takes months.
Finally, I'd say Google has a bit of false consciousness around what sort of culture they actually have. They want to think of themselves as a free, loose sort of place where people are empowered to look for problems and go fix them. That's why they still have 20% time, for example. In truth, what you'll be rewarded for is doing what your boss wants, to his satisfaction; everything else is at best marginal. And you know, I think the employees know that, since 20% time is taken by less than 5% of the engineering staff. A culture of
"do what your boss tells you" isn't bad of course; what it is, is ordinary.
So, some big pluses, oh yeah, but some big minuses too.
I appreciate your perspective, but would like to add a few quibbles:
I'm a big fan of the strict coding style. It enforces a consistency that I think has real value at only a temporary cost in adjusting your coding habits, which quickly (in my experience) becomes second nature. That said, I understand opinions can differ on this.
Readability is not required to submit code. It's nice to have it, of course, but it's not a blocker to productivity.
One of my favorite things about Google is their, still legitimate in my eyes, sincere desire to defeat bureaucracy as much as humanly possible for a company that is obviously at this point so big and complex. They have multiple initiatives on this front with decent exposure and I think the success on these fronts is palpable. But obviously it isn't and can't be the same as a startup in this regard.
I find the people that like lots of strictness and rules are usually managers or high level non-coding engineers. Usually these people are trying to limit development rate to something they can have control over. Usually by complaining about whitespace.
I doubt I could ever work in a place where I cannot unilaterally deploy code whenever I want. If I can't it's usually because someone is trying to be top dog by limiting access to the codebase in some way. Usually it's someone in a management or pseudo-management role. In those cases where I can't just ignore them, I can always quit and work on my own projects to restore 'engineering primacy.'
I'm sure you're right about not having quite as much elbow room at google compared to other companies - but saying that I'm not sure strictly enforcing a style guide is great example a developers freedom being quashed.
Anywhere you're working on a codebase that you want to be maintainable having a style guide that is strictly enforced seems like a no brainer. Keeping in my mind google could have any number of developers working on a codebase
I don't object to having a style guide. I object to the extent of it. Some rules of good practice make sense. But having a really extensive style guide shifts code review away from what it should be focusing on -- correctness, clarity, efficiency -- towards punctilious enforcement of minutiae.
On the minus side, the company is very, very strict, particularly around its codebase. For each language, there is an extensive set of coding guidelines (actually rules) covering even minute issues like spacing. And it's actually enforced. If you're looking for a high-trust environment, or just some elbow room to do things your way, stay the heck away.
The company is also very bureaucratic, particularly around hiring and promotion. Promotions are done by independent boards, based on extensive documentation (the "perf packet") provided by the candidate and his manager/lead. At this point, these packets are hefty enough to beat a man to death with. To submit code, you'll also need to get certified for "readability" in each language you will be working in, a process that takes months.
Finally, I'd say Google has a bit of false consciousness around what sort of culture they actually have. They want to think of themselves as a free, loose sort of place where people are empowered to look for problems and go fix them. That's why they still have 20% time, for example. In truth, what you'll be rewarded for is doing what your boss wants, to his satisfaction; everything else is at best marginal. And you know, I think the employees know that, since 20% time is taken by less than 5% of the engineering staff. A culture of "do what your boss tells you" isn't bad of course; what it is, is ordinary.
So, some big pluses, oh yeah, but some big minuses too.