I started as a test engineer on an SRE team (ads database, which I think no longer exists), did a mission control rotation, and then sort of found a way to be a software engineer (non-SRE, which pissed off the SRE leadership) and run my own projects in prod without any real oversight (that was exacycle- using all the idle cycles in prod). I used my knowledge of SRE and my good connections with SRE to run my service with minimal impacts on the $MONEY$ services.
Later I did stuff that involved working closely with SRE and hwops but always SRE-adjacent, not part of SRE. I had a standing offer to join multiple SRE groups but chose not to because I can't do oncalls while my kids are still at home.
What are test engineer roles like at Google? I’ve basically only spent my time in startups on critical systems (defense, finance) so have no idea what it’d be like at a larger company or team.
It's varied. Some posts below describe the standard software test engineering. Test engineers on Google Fiber would buy every microwave and 2.4GHz cordless phone and baby monitor, and see if our changes to interference mitigation algorithms improved or regressed between releases. So you're basically in a lab trying to break Wifi algorithms, probably not writing much code. (Also things like "does our change to move iPhone 6 to 5GHz when it's closer to the 5GHz access point also work with and iPhone 5?")
This was a long time ago and it was a "bespoke" position created by the SRE team. I set up a continuous build and then fixed bugs until it went green.
Test engineers at Google at the time (~2008) were expected to build test infrastructure, rather than writing unit tests (SWEs were expected to write unit tests and integration tests), or to build complex system tests.
Yeah that sounds pretty familiar to my experience! Right now I'm in an infra team and work on the CI pipelines, testing frameworks for devs, testing infra, etc... So more time dealing with docker/k8s than a unit testing framework that's for sure!
Often times the interesting teams knew who they wanted to fill headcount with. They would say "stop by for an informal chat", then in that chat they would interview you on (e.g.) very niche terminology. After that they would tell you it is not a good fit. Tried to go to 3 different teams on my way out of Google and none of them were interested. I think it is a bit of a status game, like they are looking for a PhD or to justify a visa.
Specific examples, an Android static analysis team and Fuchsia security both passed after informal chats (unprepared interviews). I've spent a ton of time in reverse engineering frameworks, malware, and building automated code analysis solutions (with tons of bugs found to my name). When you have that experience, and they bring you on to do front end dev on some internal tool, like there is just such a disconnect.
At the time (2009 or so) it was hard to leave SRE and be a SWE because SRE had a hard time keeping employees given the oncall and nature of the role. My mistake was to tell people it was easy to leave SRE, which the head of SRE didn't like. He called my new manager and chewed him out. To his credit, my new manager told me I wasn't in trouble, but to be more circumspect when dealing with predatory leadership.
I wonder if it's still that way. At Meta it is not, you need to go through an interview loop to move from Production Engineering to SWE (even though the culture at Meta makes PE far more similar to SWE than SRE is to SWE). I bet the reasoning is the same: they don't want to make it easy for folks to move from PE to SWE.
I’ve had someone unironically tell me SREs are just people who are too dumb to be SWE so there’s probably more to the gatekeeping than just on-call lol
No, you can move easily, which is why he could piss off his current leadership without consequence.
Being able to move doesn't mean your current manager will be happy about you moving. The "easy" part of the process means that they just can't do much to sabotage you or your future.
