After 3 months at Google I've come to realize the high hiring bar is there because you need to be particularly smart just to get basic shit done in their environment. I spent 3 hours the other day trying to authenticate to one of Google's own internal APIs from within the Google network using their bespoke IDE. In the end the code necessary was pretty simple. But I'd tried many incorrect solutions before that. The API library itself is "deprecated" but the API is still very much in production and not changing any time soon.
1) Treat services you call like your own code. Familiarize yourself with the server code. Try running it locally and poke at it. If you run into problems in staging/production, go look at their logs and monitoring dashboards (if that's still allowed; I have a feeling that things have changed around permissions since I left). What I learned that there was never an error I needed help with as soon as I read the code and error logs of the app I was trying to call. "Oh, this deprecated field is actually still required, it's just IGNORED now", that sort of thing. In the real world, it really helps with open source libraries. There is never any useful documentation. So get used to reading the code, and you'll never notice it's missing. As you get good at it, it really becomes a productivity superpower.
2) Fill out all available forms. I wrote and maintained a monitoring system at Google. I remember going to some tech talk about how the network worked, and realized that I could be using a high network priority instead of Best Effort, just by filling out some form. In the unlikely event of a network problem, we'd probably still have monitoring! Fill out the form I did. And one day there was some network incident where a lot of consumer-facing apps were slow/down, and my service didn't miss any messages. No unnecessary outages or pages or a long night, all because I filled out a form that anyone could fill out. I honestly felt a little bad because I guess we could have lived without the monitoring if it would have saved GMail. But hey, victory goes to the team that's willing to fill out the form and maybe have a quick meeting about it. Not everything in software engineering is programming.
There is quite the ramp up time, and there is a lot of learning to do, but once you get a handle on it, you can really do great things at high speed. If you ever leave, you will miss it. As much as people complain about the tools/systems/libraries, it is all really top notch. The "real world" is a hodgepodge of half-baked systems that all cost $30,000 a year. (Whoever wrote Prometheus left too early and cloned varz instead of Monarch. Hurts my soul every single day.)
I most miss D, Spanner, Blaze, and Monarch. Spanner you can buy from Google, but I can't afford it. Bazel is open-source. The rest... you just have to settle for something not as good.
I like some of the tech so far. And I have a good amount of startup experience, so I know the world of paying for SaaS instead of having your own special internal solution. Sometimes paid SaaS is superior. It's built for users more so than developers. That limits your powers but also means it's meant to be used by someone that doesn't know how it works.
Blaze seems very nice. I'm deep in a special domain far from g3 - so I only came across it this week. But it has worked exactly how I want it to and has given me no trouble, only a good experience so far. Much better than the terrible world of whatever build system NodeJS is using this week.
And the perks are pretty nice. Not enough to make me never go back to startups. But I appreciate them. Extra days off that no one else would get. Free trips to amusement parks. Days off to go sailing. Good free food. Good free cappuccinos. Good free snacks. Free car charging. I'm shocked so many people living in Mountain View refuse to commute in after working from home for two years.
