Software Engineering at Google

It largely depends on how impressive you are when you come in, and how in-demand your skillset is across the company. After the hiring decision is made, managers then "bid" on Nooglers they want for their teams, and higher-priority teams (like Android, Ads or Search) will beat out lower-priority teams (like Blogger or Finance). If multiple managers bid on you but you don't like the team you're assigned to, you have the option to work for one of other ones, eg. I was assigned to Search when I joined in 2009, but my recruiter made it clear that if I really didn't want to do it, there were teams in GMail and Docs that would be happy to have me. If only one manager has bid on you, then you're stuck there.

Ah, I see. Location probably has a significant effect, then - I joined the Seattle office, which had only a couple hundred people at the time.

There's a meta-lesson about the structure of the software industry, though:

Different market niches in software have wildly different sizes & profitabilities. It's worth doing everything you can to get into a market that is both huge and wildly profitable, and once you're there, you should do everything you can to defend that niche from new entrants.

Pretty much everything in Google's strategy - the constant rewriting, the expansion into adjacent markets like web browsers and mobile phones and ISPs, the highly-paid employees, the 20% time - follows from this. Also, most of the counter-intuitive advice in the startup world - the obsessive focus on growth, the companies that shut down because they aren't growing fast enough, the existence of venture capital and willingness to accept significant losses of control in exchange for capital infusions, the use of disposable coding practices and technical debt - also follows from this principle. A lot of things about the software industry that seem stupid, irrational, or short-sighted become perfectly rational when you understand the market structure of technology.

>Blindly copying highly expensive software development processes from Google or other super-unicorn companies like Apple or Facebook is likely a prescription for failure.

Yes, this can't be stressed enough. Out here with the little people like non-Google-employed me, there's almost a desperation to copy the things that Google and Facebook do, and it's often justified with "Well, Google, Facebook, or Netflix use it!"

A huge amount of tech fads over the last decade have been the direct result of Google's publications and public discussions. Google might need BigTable, but that doesn't mean we should all bury our SQL RDBMS and use a crappy open-source knockoff "based on the BigTable paper". More than likely, Google would've been happy to keep a SQL RDBMS.

Google has the engineering staff, including two extremely technical founder-CxOs with PhDs on which Google's initial technology was based, and the hundreds of millions of dollars necessary to do things The Google Way. They can rewrite everything that's slightly inconvenient and do a lot of cutting-edge theoretical work. They have the star power and the raw cash to hire the people who invented the C language back in the 70s and ask them to make a next-gen C on their behalf.

Google has the technical and financial resources to back this type of stuff up, provide redundancy, put out fires, and ensure a robust deployment that meets their needs. They keep the authors of these systems on-staff so they can implement any necessary changes ASAP. In many cases, Google is operating at a truly unprecedented scale and existing technologies don't work well, so that theoretical cutting-edge is necessary for them.

None of those things are going to be true for any normal company, even other large public ones. Google's solutions are not necessarily going to meet your needs. Their solutions are not necessarily even good at meeting their own needs. Stop copying them!

I'm so. sick. of sitting through meetings that have barely-passable devs making silly conjectures about something they heard Google/Facebook are doing or that they read about on a random hyper-inflated unicorn's engineering blog.

You want your stack? OK, here it is: a reasonably flexible, somewhat established server-side language (usually Java, .NET, Python, Ruby, or PHP; special applications may need a language that better targets their specific niche, like Erlang), a caching layer (Redis or Memcached) that's actually used as cache, NOT a datastore, a mainstream SQL database with semi-reasonable schemas and good performance tuning, and a few instances of each running behind a load balancer. That's it, all done. No graph databases, no MongoDB, no quadruple-multi-layered-massively-scalable-Cassandra-or-Riak-clusters, no "blockchain integration", no super-distributed AMQP exchanges, ABSOLUTELY NO Kubernetes or Docker (use Ansible), none of that stuff.

Just sit down and get something done instead of wasting millions of your employers' dollars trying to make yourself feel important. If you do need an AMQP exchage, bolt it on after the fact to address the specific issue at hand, once you know why you need it, and make sure you know what you're doing before you put it in production (it's apparently difficult to grasp that AMQP servers are NOT data stores and that you can't just write directly to them and wait for some worker to pick it up if you care about data integrity).

Don't start a project with the primary intention of making a convoluted mess; let it get that way on its own. ;)

Well said, this is the comment of the year.