from tc import ONE_EIGHTY from yoe import SIX Hi all, Prepping for a switch to Microsoft (Redmond or Bellevue) as a Sr. SDE (L63). Aiming for January (that's a good time of year, right?). What are some good teams/orgs? Was thinking about XCloud, but maybe they'll fall into the same category as Azure... Would like to work with distributed systems, but would kind of like to avoid Azure. Big cloud services sound like a TON of ops work, meticulous dashboard monitoring, handholding deployments, with little feature work.
You’d like to work with distributed systems but don’t want to deal with Ops? How would you know the health of the distributed system you built without monitoring the infra in your distributed fleet? Maybe you should try MSR? If you really want to learn about distributed systems and yet get to do lots of feature work, you have to be prepared to support the code you ship, which means you have to be willing to do Ops. Ops in large scale services is one of the fastest way for you to learn and internalize what it means to work with distributed systems. If you are still interested, then reach out to the hiring manager on the Azure App Service/Azure Functions Platform team. Disclaimer: I don’t work on the team but know folks who work there. All engineers take full ownership of feature work. Even interns almost always only work on projects that eventually gets shipped to prod either by the end of their internships or the next couple of quarters.
Hmmm. Maybe it's not for me? Or maybe the team I've heard of is the exception? Ops is fine, it's part of ANY dev role. But I've heard of cloud teams from acquaintances where they spend about 75% of their time meticulously writing very large documents on the minor changes made to the system, getting that document approved, and deploying the change. If 75% of the job is manual, automatable, but not automated work to deploy code, I don't want to be part of it. That would drive me nuts. I just don't have enough data to tell if this is all cloud services, or just some bad teams. Of the teams I've worked on, you push changes into a continuous deployment pipeline, and if there's problems it gets autorolled back. Or QA teams will test and deploy the changes (this one was for a service with a GUI). I've been on-call. I was on-call 25% of the time before, and that wasn't so bad. But if that swaps to 75% of my time is deploying code, I'm out.
Can’t verify what you heard about other teams but you shouldn’t be spending 75% on Ops. That sounds like bad leadership who can’t figure out how to automate for efficiency and enforce reasonable bar for writing tests to guard against bad code being checked in. It’s not the case in the App Service team. Their ops load seems manageable and their engineers ship lots of feature work. Just get an informational with the hiring manager and ask them point blank if that’s your concern.