I'm a SWE SRE at Google. That means we had to do a SWE interview with an emphasis on system design.

So I'm expected to be able to do both operations for oncall, but also do RCA and implement fixes and changes to make the systems our team is responsible for more reliable.

We're able to throttle the release cadence of binaries, so we work together with dev teams (SWEs who develop features) to come up with appropriate monitoring, metrics, mitigation, and scaling capabilities.

Some SREs are not SWE SREs, they usually have a specialty related to the team they're on, such as networking, low level linux internals, etc. They're still expected to be able to write production level python/Go code.

They are more likely to send a bug to the devs rather than fix it themselves, where as I will often (but not always) just go right in and send a CL to the devs fixing or optimizing something.

▲

petemc_ 11 hours ago | parent [-]

Hey VirusNewbie, thank you for your response! A few more questions if you don't mind.

Did you read the SRE handbook before applying?

How do you decide who gets alerts (or are devs never on call)?

	▲	VirusNewbie 9 hours ago \| parent [-]
		>Did you read the SRE handbook before applying? Yes, but it wasn't really necessary. Google isn't trying to hire SREs, they're trying to hire SWEs and specialists who they can turn into SREs, if that makes sense. Though I'm sure SRE experience elsewhere helps, they are still expecting SWE level coding/algorithms etc. >How do you decide who gets alerts SREs will be assigned to a team that has a rapidly growing service or essential service (or both), and they will be the primary team that takes the alerts, while the developers have a slower SLO (though still oncall rotations for them).