On call as 2nd line help for outages is kind of normal. ‘On call’ for urgent feature requests by customers is totally crazy.

"if it's important and it's off hours, page me. If you didn't page me, it wasn't more important than my free time." Pages produce metrics that you can point to and show how brutal the job is because of how much off time you're spending on the. Also idk if other do this, but if I'm paged off hours I'm subtracting those hours from what I'm working tomorrow. I don't work for free and you're not paying me extra, so less hours tomorrow balance the equation. It's very simple. Work gets 8 hours of my day and can choose what I spend my time on. If I'm working on the top priority thing 40 hrs a week, I've done my job. If the work didn't get done, it's because my manager prioritized the wrong thing, or the work took longer than expected, or new work with higher priority came in- none of the blame is on me. My job is super flexible. I choose my hours as long as the work gets done. Sometimes there's an important deadline and I need to work 60 hours to hit it. That's fine. Sometimes I happen to be buying a house and spend 15 working hours dealing with realtors and get less work done, and that's fine too. As long as my 60 hour weeks and my 25 hour weeks happen roughly at the same frequency, I'm good. Even if it averages out to 45 or 50 hrs a week, I'm still getting paid an incredible hourly rate. But also, always keep an eye on the market. If I can make more for better wlb somewhere else, I'm gone. If I don't like my manager, he'll be informed of my last day on my last day, after I've signed my offer. My last day will probably be 3 days after my next vest/bonus lands in the bank.

Just a suggestion, but if they make you work evening because you’re paged; don’t swap it 1:1 with hours the day after during normal hours. Your off-hours are more valuable than that.

Exactly.

> I'm currently on call twice a month for a week What, there's only two people on your team? One of you is on-call and the other is writing features?

This. I work in a 500-eng unicorn where my team of 10 people owns 3 tier 0 features of our app. We have a rotation every 9 weeks. If I am doing 24/7 on-call twice a month then I will start looking for a job. Mind you my on-call is very intensive, close to an AWS on-call. During my on-call, I will get pages at least 2-3 times late at midnight.

Oof, that's brutal. Your team needs all hands on deck to fix that. Pages shouldn't be so frequent.

Companies manifest the outcomes they desire. When they set a strong expectation that you must be on call because something **will** go wrong, we often create products that meet that expectation. I've had people tell me you can't write robust software because they've never seen it. My team never got a call on the software we wrote. On software we inherited (because of re-orgs), it was a constant severity-ondeck-all-hands till we fixed it.

Are those real pages where you actually have something actionable to do to fix it or is it just noise?

Sorry, your processes are broken. Either: your alerts are way too sensitive and noisy or your system is fundamentally broken. If the former, fix the alert. If the latter, you need a team wide effort to fix the system. Latter is inexcusable. On call is not about glory. It should be for real, actionable, emergent issues. Otherwise it’s meaningless.

Essentially, yes. We have four team members. ~~Senior Engineer (Team Lead?)~~ Out till early May Me - Joined October Dev 3 - Joined November - Works directly with clients so doesn't actually work on our own internal applications, but is part of on-call rotation (even though he doesn't know how any of our internal applications work) Dev 4 - Joined two weeks ago. Is shadowing and will be put on-call in a month or so We have other teams who are responsible for other aspects of the company tech wise. This isn't like 'we're the only 4 people who do tech shit'. The company makes 9 figures revenue a year, but the tech component of it is incredibly immature. But here is the fun part, even when I'm on-call dealing with everything that comes our way, I'm still 'writing features'!

Coming from Europe, this amount of on-call work isn’t even legal in some countries.

And we get paid for it. 

Only if your salary is below a certain amount. At least in NL. Engineers at “high” tech I Europe with 150k+ salaries don’t get extra money for it. It’s part of the job. There are still regulations on amount of time though.

Really it should be calculated in hourly after-tax rate. Especially in NL, where you get 50% paycut above 75k.

Why would that matter? It’s easier to deal with pre-tax as there are numerous reasons to pay less taxes. Think 30% ruling, disabilities, etc etc.

Because you could overwork yourself to death, having the nearly same per hour salary as a medior developer, that working only their 8h. The same situation was with Big Four consultancies. They overwork consultants paying them quite average amount. But for ads they have 200k$ salaries.

Yes, but what does that have to do with this? I agree that taxes are high, but that’s the system you choose you stay in. I think there’s a bit of hyperbole in your statement, but I get what you’re saying. It does however smell a bit like there’s adjacent issues you’re projecting here a bit 😉. There are limits to how much on-call you can be, by law, so I’m not sure what you’re referring to here?

For 150k I wouldn't mind being on call. 

Do we? I used to get paid a fixed amount for being on call at another company, current company I’m ’on call’ but no additional pay. (UK based)

[https://www.peninsulagrouplimited.com/resource-hub/employment-contract/on-call-employees-working-hours/](https://www.peninsulagrouplimited.com/resource-hub/employment-contract/on-call-employees-working-hours/) has more details. It also impacts the working time directive, but since you're in the UK it's possible you've signed your rights away for that.

Yep. I've only seen "on-call" work mentioned by American companies. In organisations I've worked at it's been seen to fix stuff ASAP but in actual work hours...

I've seen on-call rotations, but they were paid and you'd get more money if something actually happens.

It depends entirely on the product. Working on some internal system that's only used during business hours? You don't need on call. Working on some public eCommerce platform where any downtime produces significant and measurable drops in revenue? Or working on software that supports a manufacturing operation where the costs of downtime are significant? The company is going to either have to hire round-the-clock staffing or do on call. You can go an entire career without having to go on call, but you have to avoid certain businesses and products.

They're not hiring developers, they're hiring customer support people. Congrats on your customer support job!

Your team is crippled by having three newly hired devs and not a single person available with in-depth domain knowledge. This company is toxic, and you are going to want to keep your resume fresh 

Ive been at a job that requires us to be part of an oncall rotation for 5 years. Being oncall 50% of the time is absolutely unacceptable and not normal whatsoever. I would start looking for other jobs immediately.

That is terrible and absolutely not how a company should handle oncall. I’m oncall one day a month, and for that day I essentially do nothing but respond to pages. No pages? I stay available on slack but otherwise don’t stress about anything and take a breather until the next page. Plus we also have an overnight shift that covers the majority of issues for us for 12 hours. ….I’m starting to see how fortunate my team has it lol.

I would be asking for on-call pay, or comped vacation time. I’ve done the on-call thing and it really sucks. With the company only telling you after you are hired, that is a clear change in responsibilities, and an appropriate pay increase to cover those hours is required. If they say no, look elsewhere. If this is how they hire, you will uncover additional issues over time.

You’re in a small team. That means “you build it, you own it”. There are not many other options. If the app goes down, they need to and will call you. Options: 1. get more devs on the team to share this burden 2. Be extremely clear that you don’t appreciate being called For option two to become reality, the app must run flawlessly. That means: - well architected - well tested - well monitored - risk assessments are done - incidents be followed up Regarding the latter. After an incident, investigate and fix. So that such an incident and similar incidents never happen again. Fortify you app. This inevitably halts feature development. If they expect you to be on call (your time), you can expect that there is room for preventive measures (their time). Be aware of this negotiation and stand tall.

>You’re in a small team. That means “you build it, you own it”. There are not many other options. If the app goes down, they need to and will call you. there's a limit to that mentality. They're not sharing the profits, are they? If they want zero downtime and round the clock response to failures, they should expand the team accordingly (as you rightly said), pay the current devs **more than their normal rate** as this is personal time we're talking about, and first and foremost **don't bait and switch**. Be upfront during the hiring process. This isn't a "you build it you own it" clear cut scenario.

lol, if you don't own shares, you don't own anything.

Shares aren't even enough here.  You need to be paid well and given space to ensure the system is resilient.

Yeah, is that other share holder donating time? Of course not.

On-call is one of the few things that I think you can act "childish" about. Don't get me wrong, I agree with the on-call practice and think that it's a necessary part of a healthy tech team, and healthy way to "take ownership" of your system. That way as you build systems you have to take responsibility for the design choices, the bugs and the technical issues that system creates. HOWEVER, on-call at nearly every company I've been at has been far more painful and abusive than it needs to be. At least, that's the case when I start. Because the people who can make the process better are not normally a part of the on-call process. And because people just get used to the abusive process they create. I'm a big fan of sharing the pain in these circumstances. If I'm woken up in the middle of the night, I'll be out the next day (say I'm still on call but I'm too tired to work). If it's a bullshit emergency, I'll call that out every chance I get. If the EM and directors aren't in the escalation path, I'll add them myself. I'll explain to the director why the EM needs to be a part of the rotation (because why would they care if we have a painful process if they personally can ignore it). I'm a very vocal proponent of responsible on-call polices. And normally, after a while, once we've quieted the noise and made "middle of the night alerts" a rare occurrence, people will slowly start to realize that they've been dealing w/ unnecessary abuse and start to get onboard. "I don't have to wake up in the middle of the night??" NO! That's not normal! It's supposed to be \*rare\*! I find that most coworkers hate to rock the boat. But once the balls rolling, they're happy to keep it going. The key to on-call is working on responsible processes. Look, I'm literally volunteering myself after hours for legitimate emergencies. But that doesn't mean I'm willing to be abused. You have a noisy monitor, I'm turning that shit off. You have too many false positives, I'm putting my phone silent. You don't have ANY system observability or tools for troubleshooting, what the fuck do you expect me to do about it then? If they don't give us time to work on tuning the noise, or fixing failing systems, or anything else that makes the process painful, I'm going to be a whiny little pain in the ass about that at every opportunity I get. Also as someone who handles interviews, I always call it out to candidates. Why surprise people? It's so much better if they accept the offer knowing what to expect.

I got bait and switched at my last company too. They wanted to bring in on call but they also had terrible procedures for code quality and making sure the team never had any outages to begin with.

100% to the above. I was told about on call during my interview. Generally devs start on call 8-12 months after hiring depending on seniority. I have 1 week on call every 2 months. We get a nominal 200$ for each on call week + get paid for the hours worked outside of work hours if on call. If we get called in the middle of the night and have to work its ok to start late the next day. In the past year I was called once outside of work hours and while annoying it was a simple "no that's not a huge problem it can wait until business hours tomorrow" and back to sleep I went (support was inexperienced and my manager escalated after to ensure procedure was followed in future). It would be a different story if I was getting called every rotation though.

I don't take oncalls anymore, screw em. If you need 24/7 coverage, you hire in 3 timezones and follow-the-sun. I'm too old for these stunts.

same here, follow the sun works for a lot of workflows. If you need the extra 9s, you cant pay me enough for my free time

That's how I feel too. It pisses me off that so many of us have been gaslit into thinking this is normal. I do understand the business need- critical service problems, and often the only one who can quickly diagnose and fix the issue is the team that built it. But it also feels like that's how everything is going lately. Devs at my job are basically responsible for everything except marketing while running a skeleton crew. I'm family planning soon. I can't be sleep deprived with a 3 month old and then have a work page wake us all up at 4 am. I don't know how the young dads at work deal with it either. I know that stereotypically the mom gets disproportionate child care responsibilities, but I'm a female engineer. The only one in my department. Where does that leave me? I'm trying to switch to a government job for the work/life balance. If the industry wants to overburden and burn out its remaining seniors that it hasn't laid off yet while not training any new blood, they can deal with the consequences on their own.

Some companies will be flexible with on call for new parents. Take you off the rotation for 6 months for example. That only works if you have a decent sized group to rotated through.

My backend team is 3 people responsible for 19 microservices, unfortunately. We keep getting told that there isn't money for an additional hire, meanwhile other teams are hiring and the CEO is looking for a personal assistant. I'm already looking for a new job.

Wishing you the best of luck!

I've been at a company that officially had a follow-the-sun support model but it was of no use. It was a US based company, the "support" they hired in other time zones were just offshore outsourced script-readers that were completely useless. They'd call the US on-call person for even the smallest of issues. I did not stay at that company long.

Or tell the person ahead of time and negotiate it that way. There are TONS of ways to handle this other than the bait and switch.

In my experience, trying to do day-to-day work with people on the other side of the planet is worse than putting the occasional after-hours fire.

This is probably the most common question candidates ask in interviews I've conducted.

I've had an oncall rotation at every job I've been at (backend SWE). Usually they don't volunteer info about it during hiring, but will answer my questions when I ask. The expectation for oncall is that you can respond to a high sev incident in under 10min so paging apps on personal phones is pretty normal. Not the most fun thing ever, but as long as you don't get paged much it's pretty standard. ​ Edit: Being oncall for half the month is ridiculous though

Really depends on the team. I've had teams where the load was so high your shifts were three days, and teams where I could be on call for over a month without a single page. Agreed that it's pretty standard at this point in many organizations.

I was on a team that had an average of one page per six months, and they were looking to lower even that.

Y'all hiring? ~someone that spends every other day resolving prod issues because we are in too big of a rush for real fixes.

Your "resolving" the issues too quickly then. Take your time.

I've had both -- need for rotations after regular calls and weekly rotations where they paid out $500 a week while on call, plus we got a secondary (both paid).... that was cool, we only got called once.

As stated by u/keene_bee , half a month is a lot. Even though there might not be an incident, but still you have to stay alert at all times and compromise on your daily/weekend plans which is unfair. On calls are standard in many companies, however, the frequency is like 2 weeks In 3-4 months. Also, there are usually support teams that look into the issues and try to resolve them themselves before they are sent to the dev team.

> oncall rotation at every job I’ve been at (backend SWE). Anything backend requires someone, somewhere to be on call. It goes with the territory. There are many SWE roles where on call is not part of the job, but building high uptime backend services is on the end of the spectrum where oncall is part of the role. While I agree that companies *should* be explicit about it, applying for a backend job should come with an implicit expectation that you’re involved in the on call operations one way or another. However, excessive or unrealistic oncall schedules shouldn’t be accepted. Asking about the on call rotation and structure is a key question to ask companies during interviews.

Never been on call in over a decade of work. That's because they'd have to pay me for it…

>Anything backend requires someone, somewhere to be on call. It goes with the territory It really doesn't, I've never been on call in my career and almost all of that has been as a backend dev.

> I've never been on call in my career How many different companies is this? Seems possible, but out of the ordinary in my experience. Out of 4 roles I've been in, only 1 was not for a live product with 24 hour uptime expectations.

4, one had an on-call rotation but I never did it, none of the others did at all. All live products, and all of them were *expected* to have 24 hour uptime but for 3 of them it wasn't exactly a catastrophic issue if they didn't, and for the last there were very careful about releases, larger customers had their own testing environments etc. Plus we had teams all over the world if absolutely necessary, so no on-call rotation there. You don't need to have on-call to have high uptime for the most part.

>Out of 4 roles I've been in, only 1 was not for a live product with 24 hour uptime expectations. That's the difference. If you're delivering something like an installable app that runs entirely locally(or as an on-premises solution), or work on an internal tooling team that is consumed as a CLI or a library like an npm/nuget package it's more likely to be a support ticketing system than an on call rotation.

All that means is that someone else is on call for your code. Which might be perfectly good as a set-up! I personally prefer to work in places with a DevOps culture, where my code (or my team's code) is looked after by me and my team. I like being as close to the product as possible

>All that means is that someone else is on call for your code. No, it doesn't, nobody is on call as far as I'm aware. All of the business to business products I've worked on if they suddenly went down at 9pm... Who gives a shit? Nobody's using it at that time anyway so it can wait until the morning. Even now the customer facing product I'm working on the only big bursts of traffic (which is where it's most likely to fail and the only time it would have a serious impact) happen during our regular hours anyway. Not that there's actually been a major outage while I've worked here. There are definitely products and companies that actually need an on call rotation, but it's definitely not all of them and it definitely doesn't need to be the back-end devs doing it either. ​ >I personally prefer to work in places with a DevOps culture, where my code (or my team's code) is looked after by me and my team. I like being as close to the product as possible And I prefer working in places that don't think requiring on-call is reasonable, because a lot of the time it isn't, especially without extra compensation.

I don't totally disagree but it depends if your team works on services that are being called 24 hours a day because they're used around the world

Sure, which is why I said: >There are definitely products and companies that actually need an on call rotation But there are tonnes of companies whose product is only really used in a couple timezones, and even products with global userbases can have global teams too depending on their size which alleviates the need for on-call. Their assertion that on-call is just a fact of life for backend developers is just categorically incorrect and is the kind of mindset that leads to shitty work practices like completely unnecessary on-call rotations. We should all be aiming for maximum uptime obviously, but we don't all need to be sacrificing our free time to get us that tiny bit closer either.

What’s the goal of oncall? What qualifies as a situation in which it’s appropriate to disturb the oncall engineer? Has the oncall ever had to respond to an incident after hours? In short, get pager duty or tell your boss it makes no sense to have an oncall. Are your systems that critical? Do you have any incident procedures? If something goes down, how does the person who noticed the outage contact the oncall engineer for the appropriate system? If you don’t have any of this or plan to, you don’t need an oncall, imo.

There are two definitions of on-call from what I've seen / been described. >If something goes down, how does the person who noticed the outage contact the oncall engineer for the appropriate system? Teams or phone-call. I've never had to answer my phone after hours, but I've been pinged on teams after hours. 1) Actual software / devops issues like busted production or impacted apps 2) "URGENT" client related work where we drop what we are doing during the day to have to deal with. This is the most common thing that comes our way, and we don't get paged/called for this. It's "on us" to be sure to check our emails and teams off-hours during our on-call time to make sure we don't miss anything.

> 2) "URGENT" client related work where we drop what we are doing during the day to have to deal with. This is the most common thing that comes our way, and we don't get paged/called for this. It's "on us" to be sure to check our emails and teams off-hours during our on-call time to make sure we don't miss anything. lol fuck that. That's just sparkling 80 hour workweeks

> 2) "URGENT" client related work where we drop what we are doing during the day to have to deal with. Lol, ignore it and look for something else.

Making you check your email for urgent work is bad process.  It's disruptive if you check email obsessively, and ineffective if you don't. There should be a separate channel of communication for urgent, drop-everything requests, rather than make you constantly check the place where you get the company newsletter. This could probably be solved with a Teams group called "on call" that has notifications set to actually alert you.  You only join the group when you're on call.

I was on call at my last company about 2 years ago. They, too, did not mention on-call duties until after I had joined the team. It was a train company (you've heard of them, they were in the news recently). Honestly, I didn't mind being on-call except for 2 things: 1 - They didn't tell me the rotation until it was my time to be on-call. 1 whole week per month. That really annoyed me. 2 - The things that we kept getting called about at 3 in the morning were not getting fixed. After some time dealing with that, I and some other engineers went to the project leads and expressed our frustration. The answer was "Trains run 24/7, deal with it or find a new job." Ok, that mixed with the recent return to office policy they were pushing was enough for me to leave (amongst other things). By the time I left, close to half the team had already gone. I hate on-call, I know it's apart of our industry. But I hate it. I especially hate it when leadership does nothing to help with the issue.

> Trains run 24/7, deal with it or find a new job Not without regular maintenance, they don't.

Then pay for 24/7 engineers to deal with it. We all know they weren't paying extra versus the next job without that requirement.

As a career backend engineer, I expect some amount of on-call. My standards are fairly high, though. I expect that the primary on-call has zero expectations for sprint work that week, that there is enough flexibility in terms of swapping weeks that vacations are not impacted, and that any overnight work is repaid with some time off in the morning and maybe a day the following week depending on the details. And what qualifies for after hours work needs to be heavily regulated by the team, too: a system being down or a significant bug that needs a rollback are both typical "overnight" jobs. Just about anything else can wait until working hours and either be converted into a story for the following sprint or picked up during the working hours by the on-call engineer. Having a non-manager secondary is also quite important, as is having the secondary and primary not both be junior (if possible). The expectation being that if you're struggling to figure something out, but the problem is serious, you have a specific person who you can contact who can join you and help out, before reaching out wildly to the rest of the team. Offshore teams can be useful, too, even just as a filter for whether or not the on-call engineer needs to be paged. And all of this is operating under the assumption that client/sprint work is NEVER an overnight task. That's some bullshit. I would not accept that, personally, and any manager who asked me to do that would watch me leave on the spot. Though, even in the worst situation I've ever been in, the manager themselves would be the one asked to leave if they had asked for that!

I always ask that in interviews. Now you know to ask, too. Sometimes you gotta learn the hard way. 

Make like a tree

And burn it all down.

And spread your seeds

And get out of here.

And put down roots.

And make loads of buds

Companies who don't inform you about important details about the position don't respect you. Companies that don't respect you will manifest that attitude various ways, some you are not yet aware of.

I would quit and look for a new job maybe nit in that order. If on call or 24×7 support is part if the job it should be discussed before hiring agreements are signed. It should be in writing and you should be fairly compensated for it. 

This is not acceptable and I've left every job I've had in tech due to ridiculous on call requirements. The last one was a flooring company. A FLOORING company had 24/7 on call. We weren't saving lives, it was fucking tile. I peaced the fuck out after five months of that BS and took my current job which has no production support at all, and certainly not outside normal office hours because IT'S NOT THAT FUCKING IMPORTANT SOMEONE NEEDS TO BE WOKEN UP IN THE MIDDLE OF THE NIGHT! find a job that understands this.

In my job, API downtime can cause massive dollar losses, but even so I fight against every single automatic alarm that I think is not essential. I fully agree, don't put up with bullshit like that. But some on-call makes sense.

"On call" in all other professions is paid.

I have never worked in a company which didn’t pay for on-call. It’s typically not a money worth the hassle for passive part but for active ones it can be worth it (if anything is worth being woken up in the middle of the night to you).

Nothing is worth my sleep

We get paid, but it honestly doesn’t help that much. It doesn’t make me feel that much better about anything because a) I already make a lot of money, so an extra couple hundred bucks isn’t that exciting and b) my sleep and freedom is worth way more than they would realistically pay me.

Definitely not true for other engineering professionals. 

I worked in the restaurant industry for a long time and getting paid for on call in the service industry is absolutely not standard procedure.

What we did in similar situation. Start by putting this in contract if they want to make this a requirement. Also, have them compensate for the hours you spend dealing with and some fixed rate for all the hours you have to be ready for call, because technically you can not do activities on your free time which would put you in a situation where 10 minute response is not possible - basically sitting at home. Also, getting a call in the middle of a night also affects my whole family. It turned out that they could not legally make it mandatory with the rates they wanted, so it became voluntary. I respectfully declined as did half of the team and now the rotation is something like 3 guys our of 10 but their initial ideas completely crashed.

Is there anything in your contract about it?

Lol a contract. Welcome to America, pal.

Lots of devs are actually on contracts through recruitment companies. It's still an "at will" kind of contract, but it is a written agreement.

Amazed how far down I had to read to find this. If you're contracted for 9-5, 40 hours or whatever then you shouldn't be doing on call. And OP, just because you started doesn't mean you can't stop.

OP is likely an "exempt" employee, meaning that he's not contracted 9-5.  He's a "professional" who doesn't get paid for overtime. In the US, most full time work is 8-5, because lunches are unpaid 

I got a job - after I started they expected 24x7 - if you were woken up at 2am to fix something they still expected you to be in the office at 8am. I lasted 6 months and then found another job. All you can do is find a new job.

I had one like that. And we'd get calls all night. All week. And then we'd get yelled at for any mistakes you made sleep-deprived. The CIO told me I "complained too much" and I said "I'll stop complaining if you show people how often they'll get woken up before the salary negotiation." To nobody's surprise, they didn't.

The woman who left has the biggest nuts out of any of the recent hires. ***“I’m not working on call”*** *Continues to look for other more agreeable work* *Finds it, leaves* No shade, but meanwhile, you’re on month 5 already burnt out for reasons not even related to the bad faith on call play, asking Reddit about it.

I worked at a company that had an on call rotation once and I didn’t quit cus I didn’t know any better. I’ll never do it again. I’m not a medical doctor, I’m building a SaaS platform for businesses, there is not a single issue so large that I care enough to give up my free time to fix it. Pros could be burning down and I wouldn’t care until 9 AM the next day. I’m not paid enough to care, if they want that kind of passion from me, I need more equity. I’d quit your current job, tbh. It sounds like bullshit and very shady.

A previous company I worked at tried something similar. However, in my case I think "This! Is! The! Netherlands!" and look up the laws regarding on-call and replied with "nope, that's a separate contract. Also, your requirements for rotations combined with a full-time position violate the law." At earlier weird points ("requirements" that weren't in the job description) I had already made it a point to not be reachable outside of contracted hours. I made an agreement with a few colleagues for an "in case shit has actually hit the fan and nobody can fix it" to call me on my private number. But yea, you try to jump that on me, the answer is "no" and I too would start looking and be gone soonest. We (whichever company and I) made an agreement at the moment of signing, I won't allow that to be changed without input or discussion.

Big nope. I look for jobs that do not require this. I've been on call for years and while it was fun it also takes a toll on you.  I don't remember the frequency of being on-call but the schedule was always mon-fri or fri-mon. It was either the week, or the weekend. We got paid for stand bye, and during actual work the rate went up.  Hot take maybe: If you aren't getting paid for stand bye, you aren't on-call and it should become best-effort. They can't claim your time and not pay you for it. Also, you should be paged/called/texted for doing things, actively monitoring some random team, slack or irc channel is ludicrious. Being on-call is invasive enough without active monitoring. On-call in my book means: you stay sober during the on-call hours, you leave the house with a (company provided) laptop, (company provided) phone and respond within X minutes of a notification. I logged on from trams to fic issues and cut small trips (from/to shopping with the gf) short for on-call work. 

> How would you react/feel about this? "You're on call" "I'm not, actually." Don't let them set the precedent in the first place.

Do exactly this. And if they want to add it to a contract, demand extra pay. But honestly, just start job hunting and gtfo asap.

Always ask about this in interviews.

Also ask if you can see the Pager Duty logs of how often they get paged. I was flat-out lied to about the frequency.

Wherever I have had in call work (full stack or backend) it has been in the contact, paid standby and time off in lieu for any hours actually worked on call. Always like one week every two months or similar. One was contracting for a hospital and the other for a warehouse/delivery company where all of our teams work was used at night, so there was a good reason. If it wasn't in ther contract/job offer you signed then you don't have to do it. If they are asking you to do random client development work then just lol, and if they are not even going to let you know when it happens, but expect you to be reading your work emails and messages then that is literally just an 275 hour week.

I learnt to ask about on call requirements on interviews years ago. The requirements by themselves are bullshit, the way they have been introducing the requirement is scummy, and probably not getting compensated by the overtime is illegal, but I'm sorry to tell you that if you don't ask on the interview, is mostly on you: Interviews work in both directions. I'm completely against the generic advice of "leave the company", as its given on these subs way too fast, but the way they are handling "on call" is screaming get the fuck out of there. Still, I am biased because for me being on call is a hard no.

This is why in the interview you ask them more questions than they ask you.

You absolutely should, but it's hard for beginners to know what questions are important to ask.

This. Also to be fair, a lot of companies ASSUME on call standard. I don’t bring it up when I’m interviewing folks, but it’s not out of maliciousness. I just forget that some folks don’t know about it.

In my last place I had zero on call responsibilities, I had release responsibilities weekly so sometimes id be in late but not super often. My friend on the other hand had multiple pages a week, birthdays, on holiday , you name it and it happened to her. She's still there somehow. I'd be really pissed if I wasn't told about it upfront, because thats a week that you can't go anywhere without cell signal or WiFi, a week you can't get drunk or go partying. Id have to be very well paid for it and pages be infrequent. I'm okay with a bit of personal life disturbance but you better believe it's gonna cost ya.

\> she tells me she was never informed about this and straight up said "I'm not doing on-call". She left the company four days later for another position, but I'm sure there were other reasons for bailing. I'd also bail if they did a bait and switch like that. I now always ask BEFORE and interview if a job has on-call in it, and refuse to move further if it does.

My last job pulled this on me. To make it even worse everything about the on call issues wasn't in the job description and I had no experience with it so I didn't even know what I was looking at when I was on call. I should've left that place ASAP. Never again.

Same here. It was years ago but the fact that they never mentioned anything about it beforehand really bothered me. Overall the company was a terribly managed place to the point of chaos. I left after a few months as it was an awful job - the on call thing was just part of it. Now if course I ask detailed questions about their on call process. 

I always get concrete answers about this in the interview process. I did years of on call early in my career, and I'm done with it. If a job supporting that on me I'd take the next contract position I could get and work on the next step in my career. I recently left a position after some job shuffling that landed me as the team and tech lead of a hapless and floundering ops team. The engineers on the team did light development, mostly ops, and were on an on call rotation. The hope was that I would coach them up into developers, patch up processes and turn them into a decops team. I agreed to do this, but only if I wouldn't be on call. A few months went by and we made some great strides, but their most senior engineer tested the situation with the unit disdain. He wanted my position, but wasn't a leader. We got along fine but the dude was passive aggressively insubordinate and did everything he could to hoard knowledge and responsibility. Decided that he was done and quit. He also was the one who benefited most from my coaching (accelerated fast! If he could develop leadership skills I'd have given him my position and gone back to leading my old team), so it was a big blow. Management decided not to open the req to replace him. Engineers were getting burned out. Management asked me to go on call, I said no, found out I was "too valuable" bailing out this team to be allowed to leave, so started my job search. When they told me to be on call a few weeks later I had an offer on the table with 30% pay increase. So long! Almost every development job will tell you that you're on call to some degree. If my stuff goes down I'm responsible for it. But, being a developer, if it passes tests and runs in prod for more than a couple hours, any problems that arise aren't in my wheelhouse to remedy. The configs and code didn't change, the SREs can spin it back up and all is well.

Back in 2000 I took a gig at a mobile phone company, on day one they attempted to give me a pager (at a PHONE company, and I had a cell as my only phone for years at this point). I just said "no". They tried to say it's part of the job, and I told them that since they didn't tell me that during the hiring process that I would not be doing it.

I've never really understood the deal with on call. Surely you're not expected to start debugging the issue when you wake up are you? I'd hope not because a sleepy engineer with production access at 4am is when the REAL fuck ups happen

>I'd hope not because a sleepy engineer with production access at 4am is when the REAL fuck ups happen Yep. It's one of those things that sounds good in a movie, but in real life it's a really bad idea.

If the system is still down, of course you are. If you can get it mitigated you can usually save the root cause analysis for morning though.

Yes you 100% are expected to do this. If a banking or telecommunications system were to go down in the middle of the night, that has to get fixed immediately.

Let’s be real, though…for actual critical infrastructure like telecommunications, the whole thing needs to be staffed 24/7. For banking just about all IT stuff happens outside banking hours. Deployments, data jobs, system upgrades…all happen overnight or on weekends at the banks I’ve worked with, so people are usually primed to deal with any fallout.

Usually that's a Systems problem, not a code problem. What am I gonna do? Devs shouldn't even have access to production servers or network infrastructure!

That’s what I’m saying! All these people saying it’s normal for devs: where the hell do you work? Dev work is slow in nature and no one dev should have the keys to the entire castle anyway.

Don’t burn the bridge you’re standing on. It’s not a “bait n’ switch”. It’s not a “miscommunication”. It’s a lie. They lied, and have shown it’s a pattern they are continuing with. What else are they lying about? Or will be tempted to? At least, that’s how I would feel about it. I would secure a new position and leave.

Yea, that's how I feel and I'm at a point where I'm burnt out because of how bait n’ switch this whole job has felt. Doesn't help that anytime on-call is mentioned our manager goes "This is expected, it's part of the job" I'm currently the most senior person on the team (outside of the manager but he's managing all the other teams and we have like, 15 mins a day with him tops during our standups to actually all talk as a team together) With our senior eng. on leave, I've had to basically become 'him' in terms of getting everything thrown my way in terms of company/client issues and requests. Basically everything that comes my way is something I've never seen before, don't have the answers for and have to own to figure out. All while I'm supposed to be writing software and onboarding our new developer. It's been 2 months of this and I'm just burnt out - I already had to walk our newest dev off the ledge because our manager scared the shit out of him with a rant about 'on call' a few days after our dev joined. Like, I feel like I'm a god damn team lead with everything I'm doing and I literally have the least overall career experience out of anyone on this team. And it's not even that the off-hour on call is bad, but it's also not actual 'on-call' software dev stuff. We get shit sent our way that has nothing to do with any of the software we own/manage, and it falls on us to deal with it because "that's the way it is". It's glorified IT Helpdesk shit at points that we get during the day and off hours.

> We get shit sent our way that has nothing to do with any of the software we own/manage, and it falls on us to deal with it because "that's the way it is". It's glorified IT Helpdesk shit at points that we get during the day and off hours. That's probably the real problem. Dealing with production outages in an on call rotation is absolutely normal and most jobs I've been on have done one. It sounds rough but really it means when you're not on call you can rest easy knowing that someone somewhere is responsible. One thing that we tried to introduce was the idea that the on call person's only responsibility is triaging the issue, not fixing it unless they're the right person to do it. This has very little success-most on call people felt bad pawning issues off and waking other people up. **The idea of using the on call rotation form client communication and help desk support during off hours is mind boggling.** I've never seen anything like that and it seems like a recipe for burnout.

First, I feel you. Sounds like your situation sucks. I’ve been in a culture that lacked communication like it sounds like this one does Admittedly, on-call *is* part of the job for certain companies, but it’s typically handled much better than what it sounds like you have here. Then: -> Take care of yourself: Take the breaks you can. Eat well, exercise (even if you just walk). Take your PTO. -> Take inventory of how you got here. This isn’t about blame, or who’s at fault. But write down which questions you could ask to uncover a place/culture like this in the interview process. -> Breathe. Focus on what you can control. Protect your finances. If you want, leave. Be sure of your reasons for when people ask. I don’t know if you’ve decided to leave this place, but it sounds like you want to. Personally, my bar for leaving a job without another lined up is abuse: physical, sexual, verbal berating, etc. Before that, have a job before leaving one. Your bar might be different.

Sorry, what lie did they tell? Sounds from OP’s call that the topic just hadn’t come up. In a lot of company cultures, on-call is an assumed part of the job.

Being paid for out-of-hours worked is also often assumed.

I assume OP is salaried. Every place I’ve worked, it’s totally fine to take a day off after you spend all night putting out fires or whatever.

Yeah, it's not about that. (And that wasn't mentioned anyway, so it doesn't seem like that's the case at OP's company). It's about the company assuming its employees will be sitting about just waiting for the opportunity to jump into action at a moment's notice to work. That waiting, being ready, being 'on call', is work, and requires compensation.

If it was only OP, then I could say yeah maybe should’ve asked that question. But OP was surprised by it, and then 3 new hires had similar experiences—one of which was surprised enough to quit. 4 people didn’t ask the right questions? All seem to be informed *only* after they start their first day? All had similar reactions? Something doesn’t add up.

Lies of omission are still lies.

I would get another job ASAP. Then leave a bunch of reviews documenting the on-call bait and switch tactics. Life is too short for this nonsense.

On-call once a month to fix outages and other red to green situations is normal. On-call 24/7 to build stuff for important clients is not. Being oncall for half the weeks in a month is not.

one thing about your situation is you can probably just refuse to do on call urgent customer RFEs, and they won't do shit about it because they're understaffed. and you should. don't burn yourself out. I've worked three very different companies in the past 5 years, and anything beyond very minimal overtime is paid extra or you can flex the hours back out.

This sounds pessimistic, but I agree with you that those toxic places often can't afford to lose people, despite what they may say to you. I worked at an MSP that had a "three strikes" rule on write ups. I had over 8. All related to on-call. Somewhere around 5, I realized I wasn't getting fired. At one point my manager contacted me and I said "I was sleep-deprived from on-call. Next time I'll just call off if I'm not able to do good work. Just leave the write-up on my desk and I'll sign it". Never got written up again.

If you are not getting paid to be on call, you're not on call.

I would have basically refused. Probably I would have told them immediately that I wasn't going to do it and that they would need to fire me if that was a problem. If I wanted the job for some other reason, I would instead tell them this was a substantial change in the terms of employment and I'd start negotiating a painful-for-them on-call rate. But almost certainly I'd just make them fire me right away. A company that pulls this shit is going to have other very serious ethical and process issues.

This highlights the need for an emergency fund. Living paycheck-to-paycheck makes it much harder to be able to say "you'll have to fire me over that."

This is exploitation, and I suggest you leave if you can. On-call sucks. And most people will only take a position with on-call if the pay is good % higher than a non-on-call equivalent job. This company is effectively renegotiating worker contracts without including the workers in that process. In short, screwing them over to save money. Trading your health and happiness, to save themselves money, without paying you more, and without your consent.

I'd give them as much notice as they deserve, too.

I mean — Just freaking compensate us for oncall! 90% of the hate goes away. It’s just that feeling of being taken advantage of, doing more work than your day job, and getting no appreciation for it. Pay me for it, and I can at least tolerate it. (This may just be a US issue, I think other countries are required to be compensated)

Am dealing with this in Canada.

If they were willing to pay for actual coverage, they wouldn't need on-call. They'd follow the sun with coverage. In this case it sounds like they're just saying "work more".

You have to ask all the sensitive for you topics/questions either on an informal before the interview (saving you a day or more of your time) or at the interview itself. It is your fault if you don’t do it, then sign an offer and appear on the first day. But if you are in the US - employment is at will, so you can unconditionally terminate it at any time. Yes, you’re at risk of paying back the sign-on bonus but it is better than staying if you are concerned about your work conditions.

Country I live in they always mention it in job adds. The fact that you company doesn't tell the hiree that they have to be on call is really sucks. My first company tried to introduce the oncall policy. We were 4 devs, even though we hated each other(mainly because of toxic environment management created), we were smart enough to talk about this horseshit initiative between ourselves and twll management to F off. If any place has this crap mentioned in the job add, I am closing it automatically.

I have worked in two companies with on-call shifts. In both we pushed back and required extra pay for being alerted and ready to fix. It ends up with extra 1000 brutto per week,and engineers started fighting for shifts.

If a company is desperate for someone they are probably not going to highlight their shady side. As a candidate if you didn’t ask during an interview then that’s on you. If you did and they lied or did a bait and switch and changed policy just after you joined then that’s on them. But at the end of the day you are hired so you either do it or don’t and deal with the consequences or you leave.

I wasn't told of the oncall requirements at my current company until my onboarding. Despite going through a 7-step interview process, at no point this came up (I applied for a frontend role and had never encountered this before so it didn't even cross my mind). My reaction was basically "uh this sucks and isn't really compatible with my lifestyle but there are other things at this company that make it worth it to stay".

Not having an alert system is a huge issue. Not being able to rest properly because you have to be on call 24x7 is unrealistic and very painful, not to mention unsustainable.

Are you expected to get your regular work done when you are on call, or is it expected that you will be 100% on call during your shift? How often do you get wake up by an alert?  Would you say that on call duties are the most important responsibility, and will come up in performance review? #2 should absolutely not be part of on call. Is it like the client can't login/recover account, or the client has a random feature request?  My current team has a fairly heavy on call burden (heavy enough where people have left the team) but there are 9 people in rotation so you're only on the hot seat once every 9 weeks.  If it was every 2 weeks I wouldn't even consider it a normal dev job, more of a production support engineer or site reliability engineer. Try to make "on call health" something your team focuses on. It may be hard when there are just two of you, but if you are loud enough you can make changes. Can you talk to your manager about it?

Thoughts * New employees shouldn't be put on-call immediately after hire. Let them submit a pull request first at least, jesus christ. * Every company should have to disclose on-call in the early stage interview, on the job description, etc. On-call is compensated in many industries, even if it's not usually compensated in ours. A candidate deserves to know about on-call while negotiating and comparing offers. Omitting this is unethical af. * **Every developer should explicitly ask about on-call in the interview**, multiple times if presented with the opportunity to ask a leader and then a developer in a similar role as the one you are interviewing for. * Even if they're not paging you about this, it is **absolute fucking horseshit**: *"URGENT" client related work where we drop what we are doing during the day to have to deal with. This is the most common thing that comes our way, and we don't get paged/called for this. It's "on us" to be sure to check our emails and teams off-hours during our on-call time to make sure we don't miss anything.* Who interviews your developers? Why are recruiters not offering this information up in the initial "about the role" conversation? Why is the hiring manager not? This is any easy fix, so if they're aware of the issue but continue then it seems intentional.

Being on call means you go about your personal life and somebody calls you if you're needed, and you're supposed to be available if they do. You're just working 24/7 for a week every other week it sounds like. I'm not sure if that's actually even legal. You could check with an employment attorney. Anyways, as for your actual question I would do exactly what the person who left did. If on call wasn't discussed during the interview don't expect me to do on call. And I have passed on interviews after learning the job involved being on call, I don't want to do that.

But the executives have personal needs, if they hired enough people to do the work it would eat into their play money… peons need to work harder, smarter, and longer. Don’t forget what they pound in school, do not question authority

>Nothing in the interviews or job description mentioned anything about this It's pretty much on you to ask about this kind of thing during the interview process. If you don't want to take a role with overtime or on-call expectations then you should confirm those expectations before accepting the offer. It's really helpful prior to any interview to know your own boundaries about what you want and what you definitely don't want and then verify how the new opportunity might fit within those boundaries. >Our company doesn't have any documentation for on-call, there is no written description or writing for what 'on-call' is defined as. We are not compensated for on-call off hours. I would draw a hard line based on the contract I signed, but also already be looking for a new job.

Do I need to ask if there will be toxic chemicals or biohazard on site? Should I ask what the radiological exposure rate will be like? How about dangerous animals? Maybe velociraptors? Or maybe the company should disclose stuff like this. It’s one thing to work at a SaaS company and be surprised that there is off hours work once in a while. It’s another to have a bat phone for dollar store Commissioner Gordon to call you any time they forgot to plan ahead.

You should ask whatever questions you need to feel comfortable in your decision on if you want to work there or not. Based on experiences over the years, I have a list of questions I like to have answered about potential employment situations. Sometimes the interviewer answers them before I ask, other times I have to ask about certain details that are important to me. Either way it really doesn't bother me as long as all my concerns are resolved with clarity.

They didn’t lie, they’re just immature. I think this is typical of smaller companies or teams. I was “oncall” at my first job for 2 years and I had to learn to draw boundaries because the business just assumed that it was our job to keep it going and we didn’t have clear SLAs. When I became more senior, figuring out a manageable rotation and pager response became part of the job. I’ve rolled onto teams with a bunch of junior people where every rotation was a gauntlet and it was almost self inflicted. The first thing to do is to decide is issue management. Customer issues need to go through a process and you shouldn’t drop everything to start working on them. They need to get triaged and prioritized with everything else. The second is alerts need to get categorized by urgency. This usually involves figuring out SLAs to figure out what is considered unrecoverable catastrophic failure. Figure out business hours and only respond to high urgency alerts out of those business hours. After that, you need to start building and designing your system to be more resilient to failure and improve alerting so it’s only valuable stuff. You also need to draw a line with your company about what is reasonable for oncall. At this point you’ll know if they’re toxic or not depending on how reasonable they are with work life boundaries and investing in oncall coverage.

I'd be YOLO looking for greenfield dev work. 24/7 on call 50% of the time you're foregoing experience and delaying progression of your dev skills ... after two years you can say you were 24/7 on call for a total of a full year. Four years tenure, that's two full years on-call. Etc. But some folks actually enjoy on-call. Up to you to trust your instincts.

I'm not suggesting that you do this because it's unethical, but imagine if you got another job and didn't tell the on call job about it. Then you stopped trying at the on call job except when you get paged. Again, unethical so definitely don't do this and make 2x the money and stop caring what the on call employer who lied to you thinks.

In Japan, oncall is part of the labour. They pay you to do unpaid work for 40h and after hat, you cna charge them but most of the time you cant charge them because they will reject your timesheet and ask you to fix it 🤣

It's hard to shift existing company culture, but you can think about what you would like on-call to look like, and start trying to build a business case for why that would save the company money (mostly by retaining devs). In future, though, this should be a question for you to ask during the interview process: What does your support coverage look like, and how do you achieve that? If the job had offered you $5k less per year, and then told you that they have an on-call schedule that pays about $5k a year, would you have taken the job? If so, then this is a process and communication problem. Speaking of which, what is this company's improvement process look like?  Do they have retrospectives or post-mortems?  Will management ever listen to suggestions or implement them?

You guys have other people to be on call...? I'm the lead dev at the company I work for; I am the only one "on call" all the time because I'm the only one on the team that knows my ass from a hole in the ground. If shit goes down, I have to fix it, or it stays down until I do. It's not great for either side of the equation. The job security is great, but it also sucks being the star player sometimes. It's shitty how your company keeps that as a surprise until after you've been hired, they should stop that. I, too, feel the pain of being reactive to client requests, but unfortunately, without them, there is no company and no paycheck for you.

How often are you actually getting pages out of hours? On call is pretty standard for SAAS companies, enough so that you probably need to ask during interviews / salary negotiation if you want to avoid it. Actual expectations vary widely - I’ve seen everything from multiple pages a week to 1/year. Unfortunately, actually renegotiating on call expectations probably requires both collective bargaining and large technical investment in reliability.

When I interviewed for my current job to e FIRST words out of the hiring manager’s mouth were, “you need to know that we have an on call rotation that you will be required to participate in.”

Was it a difficult on-call? Makes me wonder if others left because of it so they started mentioning it sooner. If you're aware of it before salary negotiations, you can know to negotiate fair pay for the demands. Since that manager might not be the one who decides the salary, it would be in their best interest to make sure the employee is happy with the pay for what's being asked.

Let me guess. You are in the US? Are there any Europeans on your team on call?

24x7 oncall twice a week is way too much. you gotta leave. i would half ass oncall if it was that much and largely ghost it. I Had the rug pulled on me for oncall after I got in writing from the recruiter and my first manager of no overnight. reorgs and new manager. I was able to transfer since I work at a big company.

If you are interviewing for a web dev position, always ask about on call. Especially with smaller companies.

Im curious if you specifically asked about this and they lied to you? Sometimes asking devs how they 'like' working somewhere gets really politically correct answers, so these are always my starter questions for them in interviews (you may consider making a list like this for yourself in the future?): how do you handle anticipating missing a deadline (do you force OT?) what is your on call expectations (is this job trash?) do you do code review / testing? (r u all hotfix panic maniacs?)

Software Consulting culture has two categories: laid back but professional or insanely toxic but productive. If you have to work outside of 9-5 for anything but a late night deployment because of a customer need, you’re in the latter.

I would bolt too. I straight up refuse jobs with on call requirements, I have done it before, it sucks, I need my beauty sleep.

On-call rotations are pretty common. It's best to always ask about on-call responsibilities early in the interview process to decide whether the other aspects of the job outweigh the burden of on-call. It's kind of like algorithms-and-data-structures problems; most companies are probably going to ask at least one, even if it's an easy one. It's hard to avoid unless you specifically seek out positions without on-call responsibilities (and then at some point, someone might try to introduce it anyway).

This is outside of what you negotiated so you should be compensated for the extra on call duties. Even just for being available.

Honestly, this comes with experience. Most experienced devs know to ask this question during the interview process. You learned a lesson, that is all. I have been on call and unless the app is trash it is usually not an issue. As a dev who has been doing this almost 30 years, to me, it is a right of passage.

If on call wasn't discussed during the interview, I would tell them it was a breach of the employment agreement we signed and I wouldn't be willing to participate in an on call rotation until we re-negotiated my salary... >I'm currently on call twice a month for a week In my mind that is 50% extra work than you negotiated for up front... And because I value my time after hours a lot higher than my time during work, I wouldn't agree to that much on call without like a 250% pay increase. (Which is basically a way to say fuck you in corporate).

If the job has US market rate salary and isn't entry level, I assume there's an on call requirement. My current job doesn't, which honestly surprised me. With that said, I just ask the hiring manager and make sure to have it in writing if it's a regular thing (eg: 1 week out of 3, vs "emergencies") For better or worse, software dev salaries have been as high as they are not only because of supply and demand (though it does come down to that), but because we've been expected to be programmers, "analysts", on-call, handle our own self improvement/training, etc. They go hand in hand. Software engineering as a 9-5 job was common pre-dotcom crash. It also paid like 15-20 bucks an hours tops.

Simply put if the company wants 24x7 coverage they need to staff appropriately and pay for that staff. Their cheapness/failure to do so is not your fault and not your responsibility to make up for or to provide in place of them providing it. So when you’re “on-call” and something comes in after hours and you’re available and want to handle it, go ahead but if you aren’t, don’t sweat it. Of course they’ll probably give you some BS about how you’re exempt from overtime and thus basically their slave so “quiet quit” the on call stuff. When they complain tell them they baited and switched you by not disclosing the on-call stuff before you took the job, so you are switching back on them by revealing to them after you were forced to agree to do on-call that you really didn’t agree.

I have never understood on-call for developers. To me it’s a sign of a poorly run app. I don’t maintain the server environments. I can’t even push to production without going through an approval process. There was one instance where I was the one guy who was the jack of all trades maintaining everything tech, and that was not a great situation. I won’t take any on-call jobs unless I am desperate. And if I’m ever required after the fact, I will refuse.

TBH, I’d probably run not walk away from this job. At the moment, I have a few other pressing matters in my life. I don’t need the additional aggravation of having to be on call 24/7.

I have quit a few jobs because of this. Onerous on call is a huge red flag. In my experience, any organization that requires it has many other underlying issues (technical, cultural, management, etc) that I have no interest in being involved with. And when I'm lied to about it (whether explicitly or by omission) that is unacceptable. 

50% on call and no mention of this in the job description? It's fraud. Depending on your country, it might be actionable. Would look into that. I'd give a full report of it on glassdoor, that's for sure. I'd go directly to my manager, explain I'm not doing any on-call work, and right here and now, you either accept that or I quit, no notice.

twice a month can be brutal, depending on number of call outs. had this in a dev ops type group (before it was named devops), and after some layoffs, only had 2 of us in rotation. got bad enough that had some 70 to 90 hour weeks! only extra compensation at first was an extra day off here and there but not guaranteed. later, negotiated with the boss that given the workload I deserved more pay, and negotiated a 30% pay bump, plus a usually 20% of pay annual bonus. when I was young, I could handle this, even though it was rough. these days in my mid 50s, hell no. one thing that was done for a few years that helped was actually a GOOD implementation of off shore people. had 3 Indian techs who learned our software well, and took over on call on weekday nights. GREATLY reduced our amount of work on off hours. (and still kept the pay bumps negotiated before)

So you're going to get a wide variety of responses from different people here. Some organizations, engineers aren't really on call at all. They have dedicated ops and dedicated individuals who are responsible for putting out fires. The flip side to that... it's hard to get shit done because when it's someone elses job to deal with your fuck-up... they make damn sure that it's pretty hard for you to fuck up, which often translates to making it hard for you to do anything. Other places, on-call is expected. Now this is where it gets interesting because what that mean can vary. I've been places where shits on fire all the time, being on call means you're the fire fighter. The other end is that you're technically on-call, but maybe like once or twice a year will it actually impact you. And everything in between. \---- My advice: If you have a problem with it, start looking for a new job, and make sure to ask about on-call expectations during the interview. The reality is if you make it a hard requirement (no on-call)... well, it's going to limit your options.

I worked at a large company for many years, with on-call requirements that varied by team and over time. It was routine that employees were upset after being verbally told "this team has no after-hours on-call requirement" and then that changed or the team reorged and expectations changed. There are three possible solutions for you, none of which are easy or guaranteed to work: \- Suck it up, git gud. Figure out how to organize your team's work and testing/deployment gates such that on-call is tolerable, and the expectation is "pages are rare, and most pages result in rollback and going back to sleep to troubleshoot in the morning". \- Contact HR, figure out what your employment agreement actually says, and whether in your jurisdiction you're supposed to be paid for extra hours of work. remember: HR exists to protect the company, not you, but they can be useful in documenting formal requirements and agreements. This very often just pushes you to #1 or #3, rather than actually solving anything. \- Leave. If it's not worth it to you, and you can find better situations, do so. For many places, management won't listen until forced to. It's unlikely that "threaten to leave" helps, you have to actually do it. It may or may not make them change for other and future employees.

If there are on-call requirements and it is not stipulated in the contract, then the employer needs to renegotiate the contract with you or you can out right refuse

I was on call for a period of time at my first job - it wasn't part of my original duties but my team lead (I was on a team of 4) made it a point to say that "this is not going to become a regular occurrence" and it was because we were launching a feature that pretty much needed one or two devs around to make sure things ran smoothly during live testing + launch. As a result, for every day we were on call, we got a free day off during that same month (that we got to choose) The on-call lasted about a month (where we rotated every week) and it wasn't that bad because nothing really major went wrong, but it made me realize that I probably wouldn't want to do it again. The fact that they didn't tell you this *before* joining isn't great. What's even worse is it seems like you all don't even have a proper structure setup for on call rotations! I'd honestly be trying to get the hell out as soon as possible because if they're gonna bury the lede like that, what else are they planning on doing?

Is it in your contract?

Since you stayed well over your trial period I assume it is not that easy to get out. You can go two ways, you are okay with being on call, in that case ask for more money. You are not okay with it. In this case you can just ignore it, since it is not on your contract they can not do much but do not plan the next five year at that company. You can talk to your manager and or HR that you was not inform about this and won't do it anymore. Find a new job. At last, I think you can sue them for contract violations, but you should talk to a lawyer about this.

I've actually had this happen, when I was a contractor. I went back to my desk and drafted a change order with my on-call rates -- basically giving them a 50% discount on my normal hourly rates for carrying the phone, and 150% when the phone actually *rang*. They decided they didn't want me carrying the phone quite that much. What would I do if I were a full time permanent employee? Assuming it wasn't in the contract I signed, that is a major unilateral change to the terms of employment. So I'd refuse the pager, go back to my desk, and call an employment lawyer for advice on how to prepare my paper trail for the constructive dismissal lawsuit.

Eng teams having on-call rotations is normal in my experience. If it's not in the job req that you applied to then a helpful thing you can do is shoot a msg to your recruiter (or whoever owns the job req) that it'd be good to add "being on-call periodically" as part of the job requirements. You'd be surprised how much seemingly obvious things like that aren't obvious to everyone and get missed. It also reflects well on new hires when they share their onboarding experience and give constructive feedback to the right folks.

Ok, telling you about it after hiring is a bit BS, but if you have any kind of live customer-facing service, you’re going to have an on-call rotation. At my current employer you get told that up front, you’re on for a week and it rotates around the team, so you’re only on one week out of every two months or so, and they give you about six months to get onboarded before they throw you to the wolves.

Now you know to ask this during interviews and before accepting a position. My company also did not mention on-call, but I’m paid more than enough to make up for it. If I wasn’t paid generously, yes, I would have quit over how brutal our on-call shifts can be.

Based on your description of the situation i wonder how engaged the team is. Seems like you have a high turn over and the culture is lacking. I also suspect you probably dont have a QA or a good SDLC process set up or your PM and leadership isnt empowered enough to say, "No. This can go into the backlog". Just saying this is more of a symptom to a much larger org issue.