4 ms·

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 so

by 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.
  - justinclift 3y ago
    It seems to be fairly common for the on-call part of (salaried) jobs to be paid extra. For example, if you're rostered to be on call - whether or not you actually need to do anything - for a given week, then you'll be paid some $$$ for the inconvenience. Likewise, if you do actually need to do some after hours work during that on-call time (eg: some servers went down unexpectedly, find out what/why/etc + fix) then you'll be paid for that time as well. At least, this is how it's been at my last few roles.
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

> 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.
- justinclift 3y ago
  It seems to be fairly common for the on-call part of (salaried) jobs to be paid extra. For example, if you're rostered to be on call - whether or not you actually need to do anything - for a given week, then you'll be paid some $$$ for the inconvenience. Likewise, if you do actually need to do some after hours work during that on-call time (eg: some servers went down unexpectedly, find out what/why/etc + fix) then you'll be paid for that time as well. At least, this is how it's been at my last few roles.

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.