Yep, that sounds about right.
My two tips are:
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.