Organizations define “on-call” differently, based on:
- Their business model
- The volume and frequency of emergencies
- The size of their team
- The importance of reacting quickly
I’ve been on call in most companies I’ve worked for, and this is the case in DevriX at the moment.
One of them employed shifts. There was some regularity (i.e. one or two days of extra attention or overtime across the week). And some unpredictability (last-minute deployments or emergencies).
Most of the other companies delegated important activities to people who can deliver. Therefore, being an on-call software engineer usually meant evening overtime or occasional availability over the weekend after major deployments.
I’ve worked in both service- and product-facing companies.
With service-based practicing, agile regular deployments are common, and working on production projects was the norm. It is slightly different from long-term waterfall gigs that tend to be less stressful after hours.
Tackling maintenance can be really nasty, especially around the holidays, whenever a 3rd party vendor updates their API silently, or a hosting provider decides to update their hardware infrastructure “just because”.
Product-based, we used to help with 2nd and 3rd level support as needed, especially for vital issues that we’ve missed previously.
“Are you open to taking later shifts as needed or be reachable in the event of an emergency?”
It’s literally one of the first questions I ask during an interview. It’s extremely common in some companies and scarce in others.
And it’s not necessarily a bad practice. But some developers are comfortable jumping in as needed while others are really protective of their spare time.
