5 ms·

While we’re sending warnings, watch out for jobs which have “on-call” responsibilities as they’re essentially SRE jobs and can make you work on nights and weeke

While we’re sending warnings, watch out for jobs which have “on-call” responsibilities as they’re essentially SRE jobs and can make you work on nights and weekends.

WirelessGigabit 3y ago
Well, it's part of the contract right? 1 weekend per month on call. I do find it sad that there is no general requirement to pay employees to be on call. So as a contractor you need to make sure that there is an extra provisioning in there AND that the rules which govern on call are extremely clear. Like what about you going on vacation? Sick? Grandma dying?
throwaway019254 3y ago
It’s strange to see something like this here. I worked for multiple big US tech companies (both FAANG and non-FAANG) and all of them had oncall as a part of software engineering job. Supporting the services you are developing feels like natural part of the job. And when I had a lot of tickets at night I was able to fix the issues and make oncall shifts better.
- gggsre 3y ago
  > Supporting the services you are developing feels like natural part of the job. Paying fairly your employees for providing the support outside business hours also feels like natural part of the job. Unfortunately, surprisingly few companies do this.
  - zdragnar 3y ago
    If you want to charge different rates based on hour of the day, you should consider contract work rather than salaried. The whole point of taking a salary is to have a predictable income, which cuts both ways.
    - gggsre 3y ago
      > If you want to charge different rates based on hour of the day, you should consider contract work rather than salaried. What I'm saying is I don't want to do unpaid overtime and heroically sacrifice my weekends for oncall. > The whole point of taking a salary is to have a predictable income, which cuts both ways. Unsure what point about "cuts both ways" are you trying to make here. I think the company can pretty easily calculate how many non-business-hours are there within a month and allocate some money to compensate people doing oncall.
      - zdragnar 3y ago
        > unpaid overtime There's no such thing for salaried positions. I previously worked for a company that handed out "production bonuses" to people who worked >40 hours a week, calculated based off of your annual salary and hours worked. They were very clear to never call it overtime, because that has a very different meaning (legally). > Unsure what point about "cuts both ways" are you trying to make here Unlike a contractor, you don't have to look for another job after a defined period. You have a regular, fixed income (and benefits) so long as both you and your employer are happy. "40 hours per week" is a convention, not a requirement, though. Most companies are pretty good at picking 40 hours as a reasonable work-life balance mark. Some (notably startups and people mills like Amazon) push for more. That said, if you want a guarantee, stick to contracting paid hourly.
    - mullingitover 3y ago
      The only caveat I would add to this is: if you begin the position without the expectation of on-call being made up front, and then it's pushed on you without any extra comp, that's not exactly fair. However, as long as that's made clear from the outset, yes, your salary covers you performing your expected duties whenever they need to be performed. It's not like salaried engineers aren't compensated well.
    - ipaddr 3y ago
      Office full time work is 40 hours per week during the day for most. If you are working in the evenings you probably are a contractor or a newbie.
- mangamadaiyan 3y ago
  > Supporting the services you are developing feels like natural part of the job. It wasn't always seen as a "natural part of the job". Time was when most companies had a dedicated team of support engineers, who worked in 8-hour shifts, and provided support round the clock. Developers also got to spend the occasional week or month in support. Eventually, a CEO (who I will not name) figured that they could save costs if they got rid of support, and got the dev engineers to do it instead - and sold it as a "natural part of the job" - which kool-aid almost everybody has drunk by now. Which is how devs now burn their weekends, nights, and health being on-call without a choice. I've seen on-call responsibilities pretty much involve being available 24x7 for a week, once every two months. It's not right, it's not natural, and it's a result of CEO penny-pinching. That's just it.
  - noisy_boy 3y ago
    What you are describing is how most financial firms still work today. Sure Devs are the escalation in case the first line of support can't solve it. But the advantage of having a first line is that they are specialists in supporting, get better over a period of time, are mentally prepared because that is literally the job they signed up for and it lets Devs focus on core development. To those who say that this allows Devs to get away with murder because someone else is handling it - support escalations are very visible and if your stuff is breaking all the time, you come out looking very bad in the eyes of your management. Not to mention that any self respecting developer would/should apply a basic standard of care to their code. If anyone has developers that don't, it is an individual or cultural issue, not an issue with the model of separate support team.
- throwaway675309 3y ago
  Sounds awful, in all of the companies I've worked for the R&D department was firewalled from this type of tech support work. If there were site related issues, that was usually the role of dev ops team to handle. That could then get triaged to a quality assurance team, eventually bug tickets could get created. Then during our normal office hours we could assign a normal software engineer to look at them. Even the concept of being on-call physically makes me nauseous.
gggsre 3y ago
Oncall responsiblities itself are not terrible... assuming the oncall is setup in sane way. But more often than not it isn't. Right now I'm SRE in FAANG and the deal is quite sweet: we get paid for non-business hours, we are oncall only during daytime, I can exchange my oncall compensation for extra holiday. We also have enough time to fix recurring issues, remove noise, etc. But: I would never do unpaid oncall again. I would also think twice (or thrice) before agreeing for night shifts. As it turns out putting out fires at 3 AM can burn out entire team pretty fast.
- dilyevsky 3y ago
  Could’ve just said you work at google bc that’s the only place where it works like this afaik
- justinclift 3y ago
  > As it turns out putting out fires at 3 AM can burn out entire team pretty fast. AWS has a terrible reputation for exactly this.

While we’re sending warnings, watch out for jobs which have “on-call” responsibilities as they’re essentially SRE jobs and can make you work on nights and weekends.

WirelessGigabit 3y ago

Well, it's part of the contract right? 1 weekend per month on call. I do find it sad that there is no general requirement to pay employees to be on call. So as a contractor you need to make sure that there is an extra provisioning in there AND that the rules which govern on call are extremely clear. Like what about you going on vacation? Sick? Grandma dying?

throwaway019254 3y ago

It’s strange to see something like this here. I worked for multiple big US tech companies (both FAANG and non-FAANG) and all of them had oncall as a part of software engineering job. Supporting the services you are developing feels like natural part of the job. And when I had a lot of tickets at night I was able to fix the issues and make oncall shifts better.

gggsre 3y ago
> Supporting the services you are developing feels like natural part of the job. Paying fairly your employees for providing the support outside business hours also feels like natural part of the job. Unfortunately, surprisingly few companies do this.
- zdragnar 3y ago
  If you want to charge different rates based on hour of the day, you should consider contract work rather than salaried. The whole point of taking a salary is to have a predictable income, which cuts both ways.
  - gggsre 3y ago
    > If you want to charge different rates based on hour of the day, you should consider contract work rather than salaried. What I'm saying is I don't want to do unpaid overtime and heroically sacrifice my weekends for oncall. > The whole point of taking a salary is to have a predictable income, which cuts both ways. Unsure what point about "cuts both ways" are you trying to make here. I think the company can pretty easily calculate how many non-business-hours are there within a month and allocate some money to compensate people doing oncall.
    - zdragnar 3y ago
      > unpaid overtime There's no such thing for salaried positions. I previously worked for a company that handed out "production bonuses" to people who worked >40 hours a week, calculated based off of your annual salary and hours worked. They were very clear to never call it overtime, because that has a very different meaning (legally). > Unsure what point about "cuts both ways" are you trying to make here Unlike a contractor, you don't have to look for another job after a defined period. You have a regular, fixed income (and benefits) so long as both you and your employer are happy. "40 hours per week" is a convention, not a requirement, though. Most companies are pretty good at picking 40 hours as a reasonable work-life balance mark. Some (notably startups and people mills like Amazon) push for more. That said, if you want a guarantee, stick to contracting paid hourly.
  - mullingitover 3y ago
    The only caveat I would add to this is: if you begin the position without the expectation of on-call being made up front, and then it's pushed on you without any extra comp, that's not exactly fair. However, as long as that's made clear from the outset, yes, your salary covers you performing your expected duties whenever they need to be performed. It's not like salaried engineers aren't compensated well.
  - ipaddr 3y ago
    Office full time work is 40 hours per week during the day for most. If you are working in the evenings you probably are a contractor or a newbie.
mangamadaiyan 3y ago
> Supporting the services you are developing feels like natural part of the job. It wasn't always seen as a "natural part of the job". Time was when most companies had a dedicated team of support engineers, who worked in 8-hour shifts, and provided support round the clock. Developers also got to spend the occasional week or month in support. Eventually, a CEO (who I will not name) figured that they could save costs if they got rid of support, and got the dev engineers to do it instead - and sold it as a "natural part of the job" - which kool-aid almost everybody has drunk by now. Which is how devs now burn their weekends, nights, and health being on-call without a choice. I've seen on-call responsibilities pretty much involve being available 24x7 for a week, once every two months. It's not right, it's not natural, and it's a result of CEO penny-pinching. That's just it.
- noisy_boy 3y ago
  What you are describing is how most financial firms still work today. Sure Devs are the escalation in case the first line of support can't solve it. But the advantage of having a first line is that they are specialists in supporting, get better over a period of time, are mentally prepared because that is literally the job they signed up for and it lets Devs focus on core development. To those who say that this allows Devs to get away with murder because someone else is handling it - support escalations are very visible and if your stuff is breaking all the time, you come out looking very bad in the eyes of your management. Not to mention that any self respecting developer would/should apply a basic standard of care to their code. If anyone has developers that don't, it is an individual or cultural issue, not an issue with the model of separate support team.
throwaway675309 3y ago
Sounds awful, in all of the companies I've worked for the R&D department was firewalled from this type of tech support work. If there were site related issues, that was usually the role of dev ops team to handle. That could then get triaged to a quality assurance team, eventually bug tickets could get created. Then during our normal office hours we could assign a normal software engineer to look at them. Even the concept of being on-call physically makes me nauseous.

gggsre 3y ago

Oncall responsiblities itself are not terrible... assuming the oncall is setup in sane way. But more often than not it isn't. Right now I'm SRE in FAANG and the deal is quite sweet: we get paid for non-business hours, we are oncall only during daytime, I can exchange my oncall compensation for extra holiday. We also have enough time to fix recurring issues, remove noise, etc. But: I would never do unpaid oncall again. I would also think twice (or thrice) before agreeing for night shifts. As it turns out putting out fires at 3 AM can burn out entire team pretty fast.

dilyevsky 3y ago
Could’ve just said you work at google bc that’s the only place where it works like this afaik
justinclift 3y ago
> As it turns out putting out fires at 3 AM can burn out entire team pretty fast. AWS has a terrible reputation for exactly this.