Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Handle On-Call Rotations Without Burning Out
Transcript
- Lucas: Alright, I want to talk about something that every FAANG engineer secretly dreads — but rarely talks about in job interviews: the on-call rotation. Luna: The weekly pager duty. I've heard stories of people getting woken up at 3 AM for a service that's been flaky for months. Lucas: Exactly. And the thing is, on-call is unavoidable in most engineering roles at scale. But there's a huge gap between companies that handle it well — like Google or Netflix — and places where it becomes a burnout machine. Luna: And speaking of avoiding burnout — Lucas, we deliberately keep this podcast ad-free for exactly this reason. No interruptions, no sponsors trying to sell you the latest cloud monitoring tool. Lucas: Yeah, that matters to us. If today's tech conversation gave you something usable, the best way to support that is at buy me a coffee dot com slash fexingo. Keeps the show independent and zero-ads forever. Luna: Exactly. Now back to on-call — what's the first thing that separates a good rotation from a brutal one? Lucas: I'd say it's the incident severity classification system. At Google, for example, they have a very clear SEV definitions. SEV-1 is a customer-facing outage affecting a major product — you get a call at any hour. SEV-2 is a degraded feature — you get a page but it can wait 30 minutes. SEV-3 and below are daytime issues handled during business hours. Luna: Right, so the key is not treating every alert like a emergency. But I've been at places where every page is a SEV-1 because nobody wants to get blamed for ignoring it. Lucas: That's the cultural problem. Let's talk about Amazon, which has a reputation for on-call intensity. They use a system called 'pager rotation' where each team has a primary and secondary. The primary gets the page, and if they don't acknowledge within 15 minutes, it escalates to the secondary. The expectation is to respond within five minutes for critical issues. Luna: Five minutes? That means you can't even take a shower without your phone. Lucas: It's brutal. And at Amazon, the on-call engineer is also the one who writes the postmortem and faces the 'correction of errors' review. So the pressure is real. But then at Netflix — they're famously different. They have almost no on-call because they've invested massively in automated chaos engineering and self-healing systems. Luna: I've heard that Netflix engineers basically never get paged unless something truly catastrophic happens. What's their secret? Lucas: It's a combination of things. First, they use a practice called 'chaos engineering' — tools like Chaos Monkey randomly kill instances in production to ensure the system can survive failures. Second, they have very mature runbooks and automated remediation. When a service fails, a system tries to fix it first, and only pages a human if the automated fix fails. Luna: So the goal is to reduce noise. That makes sense. But for most engineers at Google or Meta, you're going to have some on-call. What's the actual playbook for surviving it? Lucas: I think there are three concrete things. First: negotiate the rotation structure upfront. Before you join a team, ask how many engineers are in the rotation and how often you're on-call. A team of six means one week every six weeks — manageable. A team of three means one week every three weeks — that's burnout territory. Luna: And be suspicious if they say 'we're hiring more people soon'. Lucas: Exactly. Second: invest in your runbooks and dashboards. Every time you get paged for something, document the exact steps you took. Within a few rotations, you'll have a playbook that covers 90% of common incidents. At that point, the pages become almost trivial. Luna: But that assumes the team culture supports documenting. I've seen teams where the senior engineer hoards knowledge because it gives them job security. Lucas: That's a red flag. And it leads to the third point: push for blameless postmortems. If your team's culture is 'who broke this?' rather than 'what broke and how do we prevent it?', on-call becomes a blame game. A 2025 study from the USENIX conference found that teams with blameless postmortem practices had 38% lower burnout rates among on-call engineers. Luna: 38% — that's significant. So the playbook is: negotiate rotation size, build runbooks, and demand blameless culture. What about the actual week itself — any tips for managing sleep? Lucas: For sleep, the best practice I've seen is the 'follow-the-sun' model. Google's SRE teams use this: when you're on-call, you hand off to a team on the other side of the world at the end of your workday. You're only expected to be available during your local daytime hours. At night, the other team handles pages. Luna: That requires global team distribution, which not every company has. Lucas: Right. If you don't have that, the next best thing is a clear escalation policy. Set a rule: if you get paged between 10 PM and 7 AM, you're allowed to acknowledge, do a quick assessment, and then escalate to the secondary if it's not a true SEV-1. Many teams allow you to 'snooze' non-critical pages until morning. Luna: I've also seen engineers use a 'do not disturb' mode on their phones except for pages from a specific number. But that requires discipline. Lucas: And it only works if your pager system is reliable. A lot of companies use PagerDuty, which has a mobile app that can bypass Do Not Disturb. I'd set that up. Also, some teams have a policy of no on-call shaming — if someone misses a page at 2 AM, it's not a personal failure. You just have a conversation about whether the paging threshold is too sensitive. Luna: We should mention that on-call also affects your career trajectory. At Amazon, unusually strong on-call performance is explicitly called out in promotion documents as a sign of 'ownership'. Lucas: That's true. But it cuts both ways. If you're on-call too often, you don't have time to work on project features, which hurts your promo chances. So there's a tension. The engineers who succeed are the ones who reduce their team's on-call burden by automating away the top sources of pages. Luna: Which loops back to the runbook point. If you spend your first few rotations identifying the top five alert types and writing automation to resolve them automatically, you're not only helping yourself — you're becoming a hero. Lucas: Exactly. And that's the kind of work that gets noticed for promotion. I've seen engineers go from dreading on-call to actually volunteering for it because they've turned their rotation into a low-effort, high-visibility project. Luna: Any final advice for someone about to start their first on-call rotation at a FAANG? Lucas: Be prepared. Before your first day on-call, read through the top five recent incidents. Understand the most common failure modes. Set up your pager and test it. And if you feel overwhelmed, ask for help — the secondary is there for a reason. Nobody expects you to know everything. Luna: I like that. It's not about being superhuman — it's about having a system. Lucas: Exactly. And remember, the goal of great on-call isn't to be always awake — it's to build systems that rarely need waking you in the first place.