8 ms·

Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engi

by dvtrn 4y ago

Some companies hire dedicated tech people whose only job is to be oncall, handle alerts, and improve the oncall infrastructure. This role is called ‘DevOps Engineer’ at some companies, SRE (Site Reliability Engineer) at others, and may also be called ‘Operations Engineer.’ Someone finally said the quiet part out loud about ‘Devops Engineer’ as a job title. Only a matter of time before we wise up about SRE as well, I suppose.

no_wizard 4y ago
If I understand you correctly you mean that they are really Operations Engineers right?
- dvtrn 4y ago
  I don’t know anymore, and honestly I don’t care anymore. If the job wants to call me an SRE fine, if they want to call me Devops, sure. I’m more focused nowadays on “what problems are you hiring me to solve?” since it feels more and more like the Venn diagram of the three job titles has nearly completely coalesced into a perfect circle. Difference for me is I’m scrutinizing far more intentionally in job interviews about why an org is hiring for SRE/Devops before accepting any offers. Too often orgs are hiring for this talent and turning them into kitchen sinks for anything and everything the SWEs aren’t doing. Compliance? Send to Devops. Upcoming audit and need a pen test done in 3 days? Send to Devops. Did a bad job prioritizing bug fixes and now shits crashing? Devops. Etc. once you go through that a few times you start to figure out the right questions to ask in an interview and figure out if you’re about to join a company with Devops practitioners or pretenders.
  - scottyah 4y ago
    I’ve experienced similar. What are some of the questions you ask?
    - dvtrn 4y ago
      Take what works you, ignore what doesn't, good luck. - Why are you hiring Devops/SRE? - What is a Devops/SRE going to bring that isn't/can't being done by engineers presently? - Why isn't it being done presently? What have you tried so far? - How many other SREs/Devops do you have? When will I get to interview with them (if applicable) - Who is responsible for platform? Infrastructure? Deployments? How are they involved? When are they involved? etc. As mentioned in my last comment, a lot of it comes through the baptism of working at a lot of really crummy shops to know the kind of bullshit you don't want to put up with. You gotta deal with some of it no matter where you go, but you sure ain't gotta deal with it all. This is a lot of boilerplate stuff, sometimes you're lucky and these questions get answered before you can ask them, sometimes they're in the job description. So let me talk about that for a minute. You really want to take your interviewing to the next step? Learn how to inquisitively, but tactfully challenge what you're reading in job descriptions. The answers I've gotten have been far more revealing than "what will I be doing day to day?" if you ask for more details about a bullet point or two and why those bullet points matter, or who they matter to. That includes, yep, on-call. Most of my other questions are very probing questions about things in the job description; not necessarily because I'm looking for a specific answer, I want to see how the hiring managers and others describe those topics. Can they actually talk about why they're looking for someone to do x, y and z? Can they have a meaningful dialogue about what those responsibilities mean for the team or are they just parroting back what the job description says, like someone in a zoom call just reading words off a powerpoint slide? Here's an example: Job says they want a Devops to come in and also be responsible for security, risk and compliance in the infrastructure? Okay, here's my counter-inquiry about that: if Devops has the responsibility for security, risk and compliance, talk to me about the authority Devops has to recommend or deny certain actions in the platform if it is assessed to be too risky or costly to maintain a compliant and secure posture were we to do it anyway (if you've ever been in that unenviable position, you probably know exactly what I'm getting at with this question). Interviews are two way streets, and in my thirties with a family where "family time" has no fungible cost, I'm driving very defensively on my side of the street.
  - dilyevsky 4y ago
    > “what problems are you hiring me to solve?” Interviewed with dozen of companies over my career - never been able to get a straight or truthful answer to this
- wpietri 4y ago
  That's certainly what I've seen! I think the DevOps paradigm was a possible revolution in how we worked. But pretty quickly a lot of places just slapped the new label on the old sour wine.
notesinthefield 4y ago
And suddenly I understand why the worst tech job ive ever had as an Ops engineer was so bad. We really only existed to improve alerting, pipeline and wake up other engineers at 3am.
- dilyevsky 4y ago
  Majority of companies i talk to are really poorly run wrt to software operations. Case in point - misusing devops term to mean sysadmins/operators
- lmarcos 4y ago
  A sincere thanks. As a software engineer I couldn't care less about what happens to my company's services/products outside the 9-5 time range. Don't get me wrong, I give myself 100% at my job, keep myself educated regularly and I'm rather on the "boring and stable stuff" side of things (instead of the "shiny/trendy and unstable" side). I have commitments outside work and no amount of money is going to make me give more than the (already exhausting) 40h/week my contract states. The "you build it, you run it" may work for people on their 20s (they usually are excited to earn "easy money" by being oncall). For people on their 30s and above the extra oncall money is not worth at all.
  - wpietri 4y ago
    I certainly believe that's true for you. But in the case where engineers choose not to ever run what they build, how do you reconnect the feedback loop? Put differently, I think one of the ways somebody goes from the "shiny/trendy and unstable" side to the "boring and stable stuff" side is by experiencing the operational pain of their choices. If the pain falls on others, will they still learn? Of course, the way you talk about your job makes me wonder if you are already experiencing so many systemic/managerial issues that there the feedback loops are already pretty broken, so this one may not make a ton of practical difference.
    - trombone5000 4y ago
      Engineers can run what they build during normal working hours. Oncall is a scourge not because of the experience of technical problems, but because people already working full time have to arrange their lives outside of work around a second "oncall job". A job which occurs after hours, one out of every X weeks. A dedicated, pure "Ops" night shift (perhaps in another time zone) would be more humane.
dijit 4y ago
Sysadmins. Those people are sysadmins. I don’t know why we need to have a job title treadmill for this; I hate not knowing what your definition of “devops” or “SRE” is when interviewing. (Both as a person who interviews others and is interviewed by others). Before anyone says it: Sysadmins could code (not to the same level as feature folk), shitty operators pretending to be sysadmins couldn’t.
- BurritoAlPastor 4y ago
  We didn’t make software engineer money when we didn’t have “engineer” in our titles. I would be perfectly happy to be a “senior systems administrator” or similar if it didn’t impact my earnings potential.
  - dijit 4y ago
    That’s not my experience. The feature folks used to come to sysadmin because the money was better.
  - analog31 4y ago
    Oddly enough traditional engineers (electrical, mechanical, etc.) don't make software engineering money.
- Aperocky 4y ago
  So.. what do you call feature folks that also do sysadmin work?
  - LegitShady 4y ago
    Underpaid?
  - Jach 4y ago
    Amazon-style full-ownership software engineer teams?
    - babyshake 4y ago
babyshake 4y ago
No you have it all wrong. Regular mid-level software engineers need to have expertise in dozens of different deep subject matter areas, but they get a "flexible" vacation policy and a $50 monthly gym stipend so they're actually getting a pretty sweet deal.
kodah 4y ago
I disagree. DevOps Engineer, as much as I hate that title, is really a sysadmin who can do orchestration code (like ansible or terraform). They're not supposed to be responsible for any application code. In a lot of ways they're more like systems integrators these days, but most of them carry some pretty fine OS and distributed system chops. SRE-SE and SRE-SWE's are responsible for application code and often embed on application teams to bolster either code or system performance or both. Please do not take companies bastardizing these practices as truth to what they are. There are companies who do this right and we should champion them above the garbage.

by dvtrn 4y ago

no_wizard 4y ago

If I understand you correctly you mean that they are really Operations Engineers right?

dvtrn 4y ago
I don’t know anymore, and honestly I don’t care anymore. If the job wants to call me an SRE fine, if they want to call me Devops, sure. I’m more focused nowadays on “what problems are you hiring me to solve?” since it feels more and more like the Venn diagram of the three job titles has nearly completely coalesced into a perfect circle. Difference for me is I’m scrutinizing far more intentionally in job interviews about why an org is hiring for SRE/Devops before accepting any offers. Too often orgs are hiring for this talent and turning them into kitchen sinks for anything and everything the SWEs aren’t doing. Compliance? Send to Devops. Upcoming audit and need a pen test done in 3 days? Send to Devops. Did a bad job prioritizing bug fixes and now shits crashing? Devops. Etc. once you go through that a few times you start to figure out the right questions to ask in an interview and figure out if you’re about to join a company with Devops practitioners or pretenders.
- scottyah 4y ago
  I’ve experienced similar. What are some of the questions you ask?
  - dvtrn 4y ago
    Take what works you, ignore what doesn't, good luck. - Why are you hiring Devops/SRE? - What is a Devops/SRE going to bring that isn't/can't being done by engineers presently? - Why isn't it being done presently? What have you tried so far? - How many other SREs/Devops do you have? When will I get to interview with them (if applicable) - Who is responsible for platform? Infrastructure? Deployments? How are they involved? When are they involved? etc. As mentioned in my last comment, a lot of it comes through the baptism of working at a lot of really crummy shops to know the kind of bullshit you don't want to put up with. You gotta deal with some of it no matter where you go, but you sure ain't gotta deal with it all. This is a lot of boilerplate stuff, sometimes you're lucky and these questions get answered before you can ask them, sometimes they're in the job description. So let me talk about that for a minute. You really want to take your interviewing to the next step? Learn how to inquisitively, but tactfully challenge what you're reading in job descriptions. The answers I've gotten have been far more revealing than "what will I be doing day to day?" if you ask for more details about a bullet point or two and why those bullet points matter, or who they matter to. That includes, yep, on-call. Most of my other questions are very probing questions about things in the job description; not necessarily because I'm looking for a specific answer, I want to see how the hiring managers and others describe those topics. Can they actually talk about why they're looking for someone to do x, y and z? Can they have a meaningful dialogue about what those responsibilities mean for the team or are they just parroting back what the job description says, like someone in a zoom call just reading words off a powerpoint slide? Here's an example: Job says they want a Devops to come in and also be responsible for security, risk and compliance in the infrastructure? Okay, here's my counter-inquiry about that: if Devops has the responsibility for security, risk and compliance, talk to me about the authority Devops has to recommend or deny certain actions in the platform if it is assessed to be too risky or costly to maintain a compliant and secure posture were we to do it anyway (if you've ever been in that unenviable position, you probably know exactly what I'm getting at with this question). Interviews are two way streets, and in my thirties with a family where "family time" has no fungible cost, I'm driving very defensively on my side of the street.
- dilyevsky 4y ago
  > “what problems are you hiring me to solve?” Interviewed with dozen of companies over my career - never been able to get a straight or truthful answer to this
wpietri 4y ago
That's certainly what I've seen! I think the DevOps paradigm was a possible revolution in how we worked. But pretty quickly a lot of places just slapped the new label on the old sour wine.

notesinthefield 4y ago

And suddenly I understand why the worst tech job ive ever had as an Ops engineer was so bad. We really only existed to improve alerting, pipeline and wake up other engineers at 3am.

dilyevsky 4y ago
Majority of companies i talk to are really poorly run wrt to software operations. Case in point - misusing devops term to mean sysadmins/operators
lmarcos 4y ago
A sincere thanks. As a software engineer I couldn't care less about what happens to my company's services/products outside the 9-5 time range. Don't get me wrong, I give myself 100% at my job, keep myself educated regularly and I'm rather on the "boring and stable stuff" side of things (instead of the "shiny/trendy and unstable" side). I have commitments outside work and no amount of money is going to make me give more than the (already exhausting) 40h/week my contract states. The "you build it, you run it" may work for people on their 20s (they usually are excited to earn "easy money" by being oncall). For people on their 30s and above the extra oncall money is not worth at all.
- wpietri 4y ago
  I certainly believe that's true for you. But in the case where engineers choose not to ever run what they build, how do you reconnect the feedback loop? Put differently, I think one of the ways somebody goes from the "shiny/trendy and unstable" side to the "boring and stable stuff" side is by experiencing the operational pain of their choices. If the pain falls on others, will they still learn? Of course, the way you talk about your job makes me wonder if you are already experiencing so many systemic/managerial issues that there the feedback loops are already pretty broken, so this one may not make a ton of practical difference.
  - trombone5000 4y ago
    Engineers can run what they build during normal working hours. Oncall is a scourge not because of the experience of technical problems, but because people already working full time have to arrange their lives outside of work around a second "oncall job". A job which occurs after hours, one out of every X weeks. A dedicated, pure "Ops" night shift (perhaps in another time zone) would be more humane.

dijit 4y ago

Sysadmins. Those people are sysadmins. I don’t know why we need to have a job title treadmill for this; I hate not knowing what your definition of “devops” or “SRE” is when interviewing. (Both as a person who interviews others and is interviewed by others). Before anyone says it: Sysadmins could code (not to the same level as feature folk), shitty operators pretending to be sysadmins couldn’t.

BurritoAlPastor 4y ago
We didn’t make software engineer money when we didn’t have “engineer” in our titles. I would be perfectly happy to be a “senior systems administrator” or similar if it didn’t impact my earnings potential.
- dijit 4y ago
  That’s not my experience. The feature folks used to come to sysadmin because the money was better.
- analog31 4y ago
  Oddly enough traditional engineers (electrical, mechanical, etc.) don't make software engineering money.
Aperocky 4y ago
So.. what do you call feature folks that also do sysadmin work?
- LegitShady 4y ago
  Underpaid?
- Jach 4y ago
  Amazon-style full-ownership software engineer teams?
  - babyshake 4y ago

babyshake 4y ago

No you have it all wrong. Regular mid-level software engineers need to have expertise in dozens of different deep subject matter areas, but they get a "flexible" vacation policy and a $50 monthly gym stipend so they're actually getting a pretty sweet deal.

kodah 4y ago

I disagree. DevOps Engineer, as much as I hate that title, is really a sysadmin who can do orchestration code (like ansible or terraform). They're not supposed to be responsible for any application code. In a lot of ways they're more like systems integrators these days, but most of them carry some pretty fine OS and distributed system chops. SRE-SE and SRE-SWE's are responsible for application code and often embed on application teams to bolster either code or system performance or both. Please do not take companies bastardizing these practices as truth to what they are. There are companies who do this right and we should champion them above the garbage.