Is it a bad idea to switch to a SRE role from SWE?
Posted by wintergoon_7@reddit | ExperiencedDevs | View on Reddit | 23 comments
Senior SWE, have an option to join a FAANG company but as an SRE/Production Engineer as an IC5/E5. I have heard that the WLB can be tough, but will the workload also be difficult given that I haven't spent most of my career doing SRE related work?
I have decent experience with adding on to existing terraform to create new cloud infrastructure, troubleshooting bugs in production, using observability tools, etc. But I'm wondering if the SRE work at FAANG will be much more difficult than what I am capable of.
Efficacy@reddit
Based on the job titles, this sounds like Meta? I worked there for 5 years as a PE -> PE mgr (E4 -> E5 -> M0 -> M1 - they don't do M0 anymore) and would recommend it. PE is tighter knit than SWE - it's 1/10 the size, even if you're only counting backend/infra SWEs, and there's a culture in PE of reaching out and supporting each other across teams and orgs. IMO, it makes for a good experience ramping up at a FAANG.
PE operates in roughly three different modes, depending on the team. Many PEs embed in software engineering teams, where you'll be working alongside doing the same (or very similar) day-to-day work as the SWEs on your team. Generally your work will trend towards reliability, dev velocity, improving operations, designing resilient systems - that type of work, though you may still work on product features if that appeals to you - working in the product will make you a better PE.
Other PEs work as a type of platform team, where many SWE teams all rely on you to provide some service or expertise for them. This type of engagement can be challenging, since you're often solving a problem for your SWE teams that they don't have expertise in, and sometimes don't feel a sense of ownership over. On the upside, you'll have way more PEs around you in your platform/expertise team. And the third type is a team of only PEs that operate a service themselves without SWEs. This is more common in areas where the product is deep in PE skillsets - think running a network backbone or similar.
Meta doesn't consider PEs as lesser than SWEs. PEs get paid exactly the same and have extremely similar job expectations - to the point where PE and SWE partner managers will both weigh in on engineering impact. And of course you'll be getting and giving peer feedback to SWEs. The work itself is the same for most infra teams as well - everyone is on call for the code they write, and this gives SWEs a very direct incentive to care about the oncall experience and reliability of their service(s).
WLB to some degree is what you make of it, and will vary heavily based on your team. If you're joining the general eng pool, ask the teammates you sit with during team selection what it's like for them. Some people will work a lot; (close to) nobody constantly works 60+ hours or something. It's simply not sustainable and the company actually understands that. For me, I found that I worked significantly more - say 50 hours - when I was trying to "level up" my skills by taking on something large or new for me. Changing teams, trying to get skills for promo, working on things I'm bad at. The rest of the time, 40 hours was plenty for me as an IC. Something like 25% of the time working a lot, 75% of the time working a reasonable amount - not including oncall weeks.
If you're very worried about future job prospects, you can switch from PE to SWE while working there, you just have to pass the same interview loop as SWEs. Folks will ask you why you want to switch since the goal is for PEs to be able to work on and get credit for pretty much any impactful work a SWE would do, but if it's important to you; they'll let you do it. I know a couple folks who went through the effort.
If you decide to go for it, join e-non after bootcamp. It'll be annoying to adjust to open-source/paid tooling when you leave, so enjoy it while it's good. Good luck!
wintergoon_7@reddit (OP)
Yes it is Meta. Your response has been extremely helpful and is making me lean towards this role.
What teams do you think are the most interesting to get into as a PE?
Also sounds like you had a lot of career growth in quick time. How did you like PE management vs your IC role? I've heard that it's more difficult for PEs to get promotions into higher levels, is that untrue?
Efficacy@reddit
Ads/Monetization had a reputation for poor WLB, which I assume is still true. Other than that, the best team will be the one you're most interested in that is doing impactful work for the company. For me, I loved working at the bottom of the stack where reliability is the most important feature and outages are critical. That type of role also let me experience dozens/hundreds of lesser outages for other services, which gave me useful experience you just can't get at a small shop.
I loved PE management, but it was very hard on me. You must do a lot of thoughtful, accurate writing about people, their performance expectations, and promo considerations, which I am slow at. But there is no option to say "sorry boss, I already worked 40 hours, I'll get you that promo doc next week." Those deadlines are set in stone and missing it would mean letting your team down big time, and potentially impact their career for months if not years. When my boss was laid off and I helped cover for his other teams, I had to make tough prioritization decisions constantly, to the point where it affected me significantly outside of work.
That said, I wouldn't do it different. For me, it was the right strategy. Though my current role is IC work and it's nice to have nobody depending on me at the moment :)
It is tough for most people to get to IC6, PE or SWE. In my experience, SWEs have a better support system for setting the path ahead offe you. It's not a checklist, more like an outline that many promos similarly follow. PE is a bit more unique, every promo is a bit different from the rest. Focus on impact, talk to your manager and listen to their feedback, ask for or find your own mentor and you'll get there.
IC7+ PEs and SWEs start looking even more similar - both skillsets are needed. Also IC7 requires an incredible amount of constant impact. I suggest focusing on killing it at IC5 before trying for promo. Definitely bring it up with your manager, but I have seen many folks get discouraged at how much work IC6 can look like before IC5 is easy for them. I've never sat in on a SWE E7 promo, so I can't compare them, but they have similar proportions, so I don't expect too much difference if any.
Also just to be clear, I wasn't doing SWE work before Meta so I was not in your position. But I knew and supported multiple SWE-turned-PEs and none I personally know regret it.
wintergoon_7@reddit (OP)
Sounds like you’ve gained a lot of valuable experience during your time at Meta. Do you think you’ll ever want to go back into management again? I want to go into management in the future but I also don’t want my IC skills to stop here before I can reach a peak of my individual learning curve. Did you choose to go back to I IC for any similar reasons other than not having to worry about others like you mentioned?
Finally is there any material you would suggest that are good reads to know more about actual incident management and root cause analysis / post mortems?
Efficacy@reddit
I may consider going back into management eventually, but I've found a position where I can work ~half time instead of full time, and I can't imagine doing a proper job in a managing role without working full time. This fits my personal life too well to give up in the foreseeable future.
Why do you want to go into management? I ask because there are other roles that get to do the "fun" parts without the "bad" parts. Leading, mentoring, planning, technical ownership, and decision-making, for example, can all be done as an IC if you find the right company with the right fit. In my experience and observations, your technical skills are almost forced to be cannibalized over time as a manager; regardless how much you want to prioritize some time digging in the code or reading merge requests, those activities will always be lowest on your list and lack of practice will degrade your ability over time. That said, if you stay involved in the product, the outages, the oncall/support issues, and steep yourself in the technical details of plans when you have some extra time with your most technical engineers, it helps. And staying technical will certainly help you succeed at a manager/senior manager level. I'm less sure at Director+ if it's a pro or con - depends on the person. Also, it's worth mentioning that I know a few managers that were able to stay genuinely, deeply technical while managing. Their secret was just being faster and putting in more time than you might find worthwhile.
I don't have great recommendations for incident management, unfortunately. I learned it the hard and slow way. The google SRE book is worth a read, I'm sure, and it has a section on incidents. There are good internal resources for learning about SEV management if you do join Meta. Check old PE Summit talks, for example. SEV Review is also public internally, anyone can go to any of them, and that's a good way to learn how systems interact and fail. If you go over time, it'll be clear which incidents were handled well and which weren't and learning from the ones that should have gone better (process-wise) is a great learning tool. But really nothing can replace hands-on experience, unfortunately. There's a lot to remember and it can be a high-stress situation for folks. But keep in mind that at Meta, SWEs are oncall for their own services, so there's plenty of people that have run few or no incidents before - it's a very teachable skill. This public talk is from before my time, but seemed good when I skipped through it and checked a few parts.
wintergoon_7@reddit (OP)
Sounds like you've gained a lot of valuable experience during your time at Meta. Do you think you'll ever want to go back into management again? I want to go into management in the future but I also don't want my IC skills to stop here before I can reach a peak of my individual learning curve. Did you choose to go back to I IC for any similar reasons other than not having to worry about others like you mentioned?
Finally is there any material you would suggest that are good reads to know more about actual incident management and root cause analysis / post mortems?
fishWeddin@reddit
Take my opinion with a big grain of salt, because I am not working at the FAANG level, but I made the switch and find it much easier. It's still technical work, but it doesn't tax the same parts of the brain as writing software (for me). Even Terraform, while it has its nuances, is so much simpler. I am filling in a lot of knowledge gaps (it's always DNS), but you have to learn in any position.
My team has better work/life balance than the SWE teams at my company because we aren't product-facing, and because they've done a great job of actually making things more reliable.
If you truly love software engineering, though, don't stay in an SRE role for too long. I can already feel the doors closing for me. Get your foot in the door somewhere, enjoy broadening the base of your experience, and keep writing code where you can. Then go back.
wintergoon_7@reddit (OP)
Why do you feel the doors are closing on you? Is it because you're able to cite less SWE work in your resume?
karl-tanner@reddit
No, if you don't know SRE already it will just make you a (much) better engineer. It's crazy how little some devs know about how to run systems these days.
wintergoon_7@reddit (OP)
100%.
ExperiencedDevs-ModTeam@reddit
Rule 3: No General Career Advice
This sub is for discussing issues specific to experienced developers.
Any career advice thread must contain questions and/or discussions that notably benefit from the participation of experienced developers. Career advice threads may be removed at the moderators discretion based on response to the thread."
General rule of thumb: If the advice you are giving (or seeking) could apply to a “Senior Chemical Engineer”, it’s not appropriate for this sub.
Scarface74@reddit
Yes it’s a horrible idea. You are going to hate yourself. Until 2018, I was your typical enterprise Dev. I learned cloud and became the de facto ºcloud architectº at a startup. But the minute I saw my job even hinting at becoming an infrastructure babysitter and I got called off hours for a production troubleshooting session I went to my CTO and said they need to hire someone and I will interview them.
Two years later¡ a position at AWS Professional Services (full time direct hire) fell into my lap. It was supposed to be to be specializing in “application modernization” cloud + app dev. But more and more of the projects were pure ºdevopsº strategy consulting. I found it mind numbingly dull. The same thing happened at my next job fir a year until last month. It took 7 months and a lot of rejections - most without even getting a chance to interview - to get back into a more software development/architect oriented role (Staff software Architect).
Even this position is not for a product company. I am working full time for a cloud consulting company.
cell-on-a-plane@reddit
What’s the point of the weird text?
Scarface74@reddit
Either he can be an SWE or he can be an on call infrastructure babysitter
cell-on-a-plane@reddit
No, the small degree circle around some titles, Devops, cloud architect.
Scarface74@reddit
If you are a “DevOps” engineer, you are by definition “operations”. DevOps is a culture where “you build it, you deploy it, you monitor it” as a team. My official title usually veers toward “cloud application architect”. Meaning I am a software developer who leverages cloud. No one would ever send me to a client to architect a large infrastructure with multiple VPCs, hybrid networking etc. They bring me in to integrate the processes between developers and operations. I try my best to convince them to at least embed someone from their “DevOps team” [sic] into their development team.
cell-on-a-plane@reddit
I’m referring to these strange characters. Is this an SEO thing?
‘ºcloud architectº’, ‘later¡’, ‘ºdevopsº’
Scarface74@reddit
Just because you haven’t heard of something doesn’t mean it’s not a real thing. Maybe you should take it as an opportunity to learn something new
cell-on-a-plane@reddit
I guess it’s character set issue? https://imgur.com/a/HabP3GM
Empanatacion@reddit
If it was me, I would take it as the opportunity to put FAANG on your resume with the plan to switch back to SWE as soon as possible.
If you've already got a FAANG on your resume, I personally wouldn't do it. It feels like a career cul de sac.
Appropriate_Culture@reddit
SRE has never been technically more difficult that SWE, so I wouldn't worry about it being something you aren't capable of. Being an SRE is a lot about mindset more than anything, as long as you have it you should be okay. In the long term however, the pay and job opportunities are always going to be a bit better as an SWE.
titogruul@reddit
I've moved to SRE and back to SWE at faang (the move back was prompted by engineering going back to SWE with another SRE team support). If you're production minded, I'd heavily recommend it. I still love production, incident management, correlation etc and make easy friends with devops. It really helps with building reliable software. And then there are war stories (and whiskey)!
Just check about the ease of transition back. In theory it shouldn't require any hoops (both are engineering roles), but details may matter.
joeydeviva@reddit
it’s fine to go and work at Facebook for a year and see if you like it and are good at it, not every decision has the entire weight of history upon it