Meta Staff Software Engineer Interview Preparation Guide

Direct answer. Design the API around a small, stable resource shape (an enrichment request/result pair), make writes idempotent from day one (idempotent meaning a retried request produces the exact same end result as the original one, so a client's automatic retry after a timeout never re-runs the enrichment or double-counts a record) given the explicit retry-heavy, multi-consumer context, and version the response schema separately from the endpoint path so downstream teams can adopt schema changes on their own timeline rather than a coordinated flag day.

Endpoints and contract.

• POST /enrichments accepts a batch of input records (bounded batch size, say up to 500 per call, to keep P95 latency achievable — P95 latency is the response time under which 95% of requests finish; the slowest 5% are allowed to take longer, which is a stricter bar than an average, since an average can look fine even while a meaningful tail of requests runs long) and an Idempotency-Key header; returns 202 Accepted with a Location pointing at a status resource, since enrichment at this volume is realistically an asynchronous operation even if individual small batches complete quickly.
• GET /enrichments/{batchId} returns the batch's status and, once complete, the enriched results, or partial results with per-item status if some items in the batch succeeded and others failed.
• The RESPONSE schema carries an explicit schema_version field, separate from any URL versioning, so a downstream team's parser can check it and know exactly which fields to expect, without every consumer needing to move in lockstep with every schema change.

Idempotency approach. The Idempotency-Key on the batch submission covers the whole batch as a unit, the same design as a bulk-write endpoint: a retried submission with the same key replays the original batch's result rather than re-running the enrichment (which may call expensive downstream data sources) or double-counting records in whatever aggregate the enrichment service maintains. Given multiple downstream teams calling this service, each team's own key generation needs to be genuinely unique per LOGICAL batch, not accidentally shared across teams; namespacing the key by caller (or requiring the caller's own service identity as part of the key) prevents one team's retries from ever colliding with another's.

Error model. A per-item error structure (not just a single batch-level error) is essential here, since a batch of 500 enrichment requests failing entirely because ONE input record was malformed would be a poor contract for downstream teams; each item's result reports its own success/failure independently, with a batch-level summary count.

Schema versioning as the volume grows. Since "downstream teams" implies multiple independent consumers evolving at different speeds, prefer additive-only changes to the response schema (new optional fields) over breaking ones whenever possible, and reserve an actual version bump for the rare case an existing field's meaning or type must change; this keeps most schema evolution invisible to consumers who do not care about the new field, rather than forcing every consumer to move in lockstep.

Validating the design can sustain 1,000 requests per second at P95 200ms. At a high level: load-test the actual enrichment path (not just the API's own request handling) against realistic downstream-dependency latency, since the enrichment logic calling external or internal data sources is very likely the true bottleneck, not the HTTP layer itself; confirm the idempotency-key storage lookup (a single indexed read per batch) stays cheap under this load, since that lookup sits on every request's critical path; and measure P95, not average latency, specifically, since an average can look fine while a meaningful tail of requests blows past the 200ms target.

Trade-offs and pitfalls. The most common mistake at this specific intersection (idempotency plus versioning plus multiple independent consumers) is designing the idempotency key and the schema-versioning strategy in isolation from each other; a schema change that alters what a stored (already-completed) idempotency result even MEANS can make an old cached response invalid for a client expecting the new schema, which needs an explicit policy (does an idempotency-key replay always return the schema version it was originally created under, or the current one?) rather than being left to accident.

Assumptions (explicit):

• Single sprint (1–2 weeks), small team (2–4 engineers).
• Existing auth system and basic user DB present.
• Web or mobile frontend with simple UI components available.
• No need for image moderation, social graph beyond following topics, or advanced feed ranking — feed is deterministic.

Minimum viable scope (MVP):

• New user flow: onboarding -> upload profile photo -> follow 5 topics -> show personalized feed.
• Backend endpoints for uploading avatar, listing topics, following topics, and returning feed items filtered by followed topics.
• Simple feed generation: return latest N posts tagged with user's followed topics.
• Basic UI screens and success/error states.
• Unit tests + 1 end-to-end smoke test.

Prioritized technical requirements & acceptance criteria (ranked):

1. Onboarding completion flag

• Req: Store onboarding_completed boolean per user.
• Acceptance: After completing steps, API sets flag true; GET /user returns true.

2. Upload profile photo

• Req: Endpoint to accept image, store in S3 (or local storage), save URL on user profile; preview in UI.
• Acceptance: Uploading JPEG/PNG <=5MB returns 200 and profile shows new photo within 2s.

3. Topic selection (follow 5)

• Req: Endpoint GET /topics (seeded list), POST /user/topics to follow/unfollow; enforce max 5 follows in API.
• Acceptance: User can follow up to 5; attempting 6 returns 400 with message. UI shows selected count.

4. Personalized feed

• Req: GET /feed returns up to 20 most recent posts where post.topics ∩ user.topics != ∅, sorted by created_at desc.
• Acceptance: For a user following topics A,B, feed only contains posts tagged A or B; returned within 500ms for 1k posts.

5. UX flow & validation

• Req: Frontend enforces required steps: must upload photo and choose at least 1 topic (recommended 5) before finishing onboarding; show progress.
• Acceptance: Cannot mark onboarding complete without photo + at least 1 followed topic; error messages are clear.

6. Tests & monitoring

• Req: Unit tests for endpoints, one E2E test for full journey, basic logging for errors.
• Acceptance: All tests pass in CI; errors are logged to console/monitor.

Implementation notes / trade-offs:

• Use simple deterministic feed to save time; replace later with ranking.
• Use local storage for images in sprint if S3 integration is blocked.
• Seed topics in DB rather than building CMS.
• Keep schema changes minimal: add profile_photo_url, onboarding_completed, user_topics table.

Deliverables for sprint:

• API endpoints, DB migrations, frontend screens for onboarding/photo/topics/feed, tests, deployment to staging.

Direct answer

The content doesn't change across audiences, it's the same system either way, what changes is which layer of consequence you lead with: business outcome for an executive, product and user impact for a product manager, and operational mechanics for a junior engineer. Below is the same web frontend, API gateway, microservices, database, and cache, presented three ways, plus what stays flexible if you had two or four audiences instead of three.

Deciding what changes per audience

• Ask "what does this person need to be able to DO after this conversation" for each audience, approve a budget, plan a feature, operate and debug the system, and let that answer set both the top points and the detail level, rather than applying a fixed template.
• Keep every audience's version factually consistent. That's the real skill being tested: three explanations of the same architecture must never contradict each other even though they emphasize different things, because these audiences do talk to each other afterward.
• Detail level isn't a dial from less to more, it's a different SET of details. An executive gets less of everything except cost and risk; a junior engineer gets less business framing and far more failure-mode and operational detail.
• The same three-tier split generalizes to other pairings: explaining latency versus throughput to a product manager and a CFO in the same meeting, choosing a different detail level for a C-level executive versus an eng-lead versus someone from procurement, choosing different terminology for a DBA versus a frontend engineer, presenting a model's result to executives versus a PM versus an ML engineer, describing a model's architecture to executives on one call and backend engineers on the next, or setting a different tone for an outage update with engineering peers than with product. The technique scales to 2, 3, or 4 audiences by repeating the same "what do they need to do with this" question for each one.

Worked example

Executive. Top points: what the system lets the business do (serve customers reliably at scale), the cost profile, and the biggest risk if something fails. Detail level: no component names beyond "our systems," outcomes stated in business terms only. Opening line: "This is how our product stays fast and available for customers, and where the main cost and risk sit."

Product manager. Top points: how a user's action flows through the system (a click hits the frontend, which asks a gateway, which asks the right service, which reads from cache or the database), where a feature change would need coordination across services, and what the cache means for how fresh data looks to users. Detail level: names the pieces and their roles, not their internals. Opening line: "Here's what actually happens between a user clicking a button and seeing a result, and where feature changes get expensive."

Junior engineer. Top points: each component's responsibility, the request path with protocols, what the cache invalidation policy is and what breaks if it's wrong, and where to look first when something fails. Detail level: full, including specific technologies and failure modes. Opening line: "Here's the request path end to end, and here's what you check first when something in it breaks."

Trade-offs and pitfalls

The biggest risk isn't detail level, it's drift: giving the product manager a slightly different causal story than the one given to engineering creates a credibility problem the moment they compare notes. Write down the one or two facts that must stay identical across all versions before tailoring anything else. The second pitfall is treating "executive" as a synonym for "shallow." An executive audience still needs the real trade-off, what the caching layer saves and what it risks, just stated in business units instead of technical ones, not a story with the substance removed.

Direct answer
An edge case (or corner case, when two or more boundary conditions intersect) is an input, state, or condition at the extreme or unusual end of what a system is expected to handle, distinct from the 'happy path' of typical, well-formed usage; systematically identifying them matters because production traffic and adversarial users reliably generate exactly these unusual conditions, while happy-path testing alone only proves the system works when everything goes as expected, which is rarely where real defects live.

Structured elaboration: eight categories, spanning multiple domains

1. Empty/null: an empty list, a null field, a zero-length string. Example (general software): a search function called with an empty query string.
2. Boundary/max-min: values exactly at, or one step past, a defined limit. Example (backend): a pagination page_size parameter at exactly the server-enforced maximum.
3. Zero/negative: values a numeric field technically accepts as a type but that may be nonsensical for the domain. Example (SRE/production): a negative value in a counter that should only ever increase, signaling either overflow or a bug in the decrement logic.
4. Duplicate: repeated values where uniqueness might be silently assumed. Example (general software): two items with the same ID in a list a system expects to be de-duplicated upstream.
5. Malformed/invalid type: input that is the wrong shape or type entirely. Example (backend): a JSON field expected to be an integer arriving as a string or an array.
6. Out-of-order/concurrent: events or requests arriving in an unexpected sequence, or overlapping in time. Example (SRE/production): a delivery-confirmation event for a message arriving before the message-sent event, due to network reordering.
7. Very large/very small scale: inputs at a magnitude far outside typical testing. Example (data/ML pipeline): a categorical feature with hundreds of millions of unique values (e.g. a raw user ID) fed into a one-hot encoder, which can silently exhaust memory.
8. Environment/locale-specific: behavior that only manifests under a specific timezone, locale, or platform. Example (general software): a date-parsing function that behaves correctly in the US locale but misinterprets day/month order elsewhere.

Worked example: why happy-path testing alone misses these
A login form tested only with a valid, well-formed email and a correct password will pass every happy-path test while shipping with a null-pointer crash on an empty password field, an infinite spinner on a 10,000-character email, or a silent security bypass on a SQL-injection-shaped username, none of which a happy-path suite would ever exercise, because by construction happy-path tests only feed the system inputs the developer already expected to work.

Trade-offs & pitfalls
Treating 'edge case' as synonymous with 'rare' is a common misconception: an empty list or a zero value is often one of the MOST common real-world inputs (a brand-new user's empty cart, a freshly-created account with no activity yet), not a rare corner case, which is exactly why the empty/null category above is listed first, not last; conflating 'edge case' with 'unlikely' leads teams to systematically under-test the cases that actually occur most often in a real user base's earliest interactions with a feature.

Direct answer: For a single dynamic dataset needing insert, delete, find-min, AND find-the-kth-smallest all reasonably fast, an order-statistics tree (a balanced BST augmented with subtree-size counters) is the right structure, giving O(log n) for all four operations. A plain heap gives O(log n) insert/delete and O(1) find-min, but CANNOT support find-kth efficiently (it only guarantees the root is the min - the kth-smallest element could be anywhere in the heap's structure, requiring an O(n) or worse traversal to locate).

Structured elaboration

• Plain heap: optimized for repeatedly extracting the single minimum (or maximum) - excellent for that one operation, but the heap property only orders parent-child pairs, not siblings or cross-subtree relationships, so there's no efficient way to find "the 7th smallest element currently in the heap" without effectively doing 7 extract-mins (destructive, and O(k log n) rather than O(log n)).
• Balanced BST (e.g. red-black tree): gives O(log n) insert/delete/find-min (leftmost node) naturally, but ALSO has no built-in way to answer "what's the kth smallest" without an in-order traversal (O(n)) - UNLESS augmented.
• Order-statistics tree: a balanced BST where every node additionally stores the SIZE of its subtree. Finding the kth-smallest becomes a single O(log n) descent: at each node, compare k against the left subtree's size to decide whether the answer is in the left subtree, is the current node itself, or is in the right subtree (adjusting k accordingly). Insert/delete must additionally maintain the subtree-size counters during rotations, but this adds only O(1) work per rotation, so the overall O(log n) bound for insert/delete is preserved.

Worked example

Given a balanced order-statistics tree with subtree sizes annotated, finding the 3rd-smallest element: start at the root, say its left subtree has size 5. Since $3 \le 5$, the 3rd-smallest is somewhere in the left subtree - recurse into it with the same target rank 3. If instead the left subtree had size 2, the root itself would be the 3rd-smallest (rank 2+1=3). If the left subtree had size 1, you'd recurse into the right subtree looking for the (3-1-1)=1st-smallest element there. Each step is O(1) work (a size comparison) and the descent is bounded by the tree's height, O(log n) for a balanced tree - this is directly analogous to how binary search narrows a range, but using subtree SIZE instead of value comparison to decide direction.

Trade-offs & pitfalls

• Don't reach for a heap when find-kth (for varying k, not just k=1) is a real requirement - it's a genuinely different capability the heap's invariant doesn't provide, not just a missing convenience method.
• If k is FIXED and known in advance (always "give me the median," for instance) rather than arbitrary, a two-heap structure (a max-heap for the lower half, a min-heap for the upper half) can support that specific fixed-rank query in O(log n) per insert with O(1) query - a lighter-weight alternative to a full order-statistics tree when you don't need arbitrary k.
• Implementing the subtree-size maintenance correctly during tree rotations is a common source of subtle bugs - it's worth being explicit in an interview about which rotations need size updates and why.

Direct answer
Speaking up when you notice leadership or business behavior running against a stated principle, or discovering a values-violating practice yourself, is a career-risk-aware judgment call. The strongest answers show that you assessed the risk of speaking up honestly, chose a channel and framing proportionate to the issue, and can describe a concrete outcome, even a partial or mixed one.

Structured elaboration

• Assessing: what made you decide this was worth raising rather than letting go, whether it was a one-off or a pattern, and how material the impact was.
• Channel: who you raised it with first, and why (a direct manager rather than jumping straight to a skip-level or a formal channel, unless the severity warranted it).
• Framing: leading with concrete impact or evidence rather than an accusation, which is what makes an objection hearable rather than confrontational.
• Outcome: what actually changed, or didn't. An honest "it partially worked" or "nothing changed and here is what I did next" is a legitimate and often more credible answer than a perfectly clean resolution.
• The self-discovered variant: if you found the issue yourself, in your own work rather than someone else's, the same shape applies, but the story should show you didn't just quietly fix it and move on. Escalating a self-discovered gap through the proper channel, rather than silently patching it, is the part that demonstrates the competency.

Worked example
While reviewing a data-handling process they had built, a candidate noticed it retained a category of information longer than the stated retention policy required. Rather than quietly deleting the excess and saying nothing, they flagged the specific gap to their manager and the relevant policy owner along with a proposed fix, since a silent fix would have hidden that the gap had existed and might recur elsewhere. The fix was implemented, and the review also surfaced one other process with the same gap that would not have been found otherwise.

Trade-offs and pitfalls
Escalating everything regardless of materiality can read as poor judgment rather than integrity; the strongest answers show calibration about what is worth raising. An outcome of "nothing changed" is realistic and acceptable, but the answer should still show a proportionate attempt, not that you gave up after one try or escalated aggressively without cause. Framing a self-discovered gap as "I caught someone doing something wrong" when the honest version is closer to "I found a gap in a process I owned" overstates the story; the self-discovered version is common and doesn't need to be dressed up as catching someone else.

Requirements & constraints:

• Reduce cross-region egress costs for frequently-read content
• Preserve low read latency for global users (<= current SLA)
• Allow writes/updates to propagate with acceptable eventual consistency
• Minimize complexity and operational cost

High-level architecture:

• Global origin in primary region (authoritative store)
• CDN (edge PoPs) in front for public/static content (e.g., CloudFront, Fastly)
• Regional read cache clusters (regional cache nodes / read replicas or regional object stores) per major geography (US-EAST, EU, APAC)
• Pub/sub change propagation from origin -> regional caches (push) with batched diffs
• Fallback: CDN/edge fetches from regional cache; regional cache fetches from origin only on miss

Components & responsibilities:

1. CDN (Edge PoPs): serve most reads, cache-control, configurable origin groups to prefer nearest regional cache.
2. Regional caches: long-lived object store (e.g., regional S3, Redis/memcached for hot items, or regional read replicas of DB) to serve cacheable content and reduce inter-region egress.
3. Origin write service: accepts updates, writes authoritative data, publishes change events (Kafka, SNS).
4. Propagation layer: event consumers that apply updates to regional caches (near real-time) with batching, rate-limiting, and size-aware replication.
5. Consistency/versioning: include object version/timestamp and use conditional requests; provide read-after-write options by routing writer to origin or nearest regional cache that has applied the update.

Data flow:

• Read: user -> CDN edge -> if hit, return. Miss -> CDN configured to fetch from regional cache (not origin). Regional cache hit -> return. Miss -> regional cache pulls from origin (incurs egress once, then cached).
• Write: client -> origin -> persist -> publish event -> propagation to regional caches -> caches update and CDN invalidates/purges or updates TTL.

Consistency & correctness:

• Use versioned objects and ETag semantics; clients may get slightly stale data until propagation completes.
• For critical reads requiring strong consistency, offer read-from-origin API or synchronous replication to a small subset of regions.
• Use tombstones and idempotent update handlers to avoid re-ordering issues.
• Consider CRDTs for mergeable state (counters/sets) where concurrent writes occur.

Egress cost optimizations:

• Prefer regional caches as CDN origins to avoid origin-to-edge cross-region pulls.
• Batch and compress replication events; replicate only diffs for large objects.
• Apply smart TTLs, cache warming for hot objects, and popularity-based pinning to keep high-demand items regional.
• Use analytics to promote frequently-read items to permanent regional storage.

Scalability & trade-offs:

• Trade-off: eventual consistency vs lower egress and latency; mitigate with versioning and optional strong-read path.
• Complexity: propagation pipelines add operational overhead; start with CDN + regional object storage + event-driven invalidation, iterate to per-item diffing and CRDTs if needed.
• Monitoring: instrument cache-hit ratios, inter-region egress, replication lag, and offer dashboards/alerts.

This design reduces cross-region egress by serving most traffic from CDN + nearest regional cache, preserves low latency for users, and provides controlled eventual consistency with clear fallbacks for strong-read requirements.

Direct answer

Instrument the client itself (the mobile app), not just the servers, because server metrics only see requests that actually reach the server: a client stuck in a retry loop, on a degraded network, or crashing before it can even send a request is invisible server-side. Collect a small set of client signals, aggregate and anonymize them centrally, and feed the aggregate (never a single user's raw trace) into the same automated-response path your server-side detection already uses.

Structured elaboration

Signals to collect on the client. Three categories cover most real client-side degradation: (1) latency histograms per API call, bucketed client-side so you get percentile shape, not just an average that a few slow devices can hide; (2) error events, both network-layer (timeout, connection reset, DNS failure) and application-layer (a 5xx, a malformed response the app failed to parse); (3) UI-hang telemetry, specifically the main-thread-blocked duration, since a slow backend and a slow render both feel like "the app froze" to a user even though only one of them is your server's fault.

Aggregation and anonymization. Never ship raw per-request client traces to a central collector at full fidelity; that is both a privacy problem (device identifiers, precise timestamps, and location can re-identify a user) and a cost problem (mobile telemetry at scale is enormous). Aggregate on-device first: roll each signal into a small periodic summary (e.g., a histogram of the last N latencies, a count of each error type) keyed by coarse dimensions (app version, OS version, region, not device ID), and only ship the summary. Strip or hash anything that could identify an individual user before it leaves the device, and apply k-anonymity style suppression server-side (do not surface a metric bucket with too few contributing devices, since a bucket of size 1 is effectively a single user's data).

Triggering automated responses. The value of client signals is that they can detect a problem servers cannot see at all (a broken CDN edge node serving one region, a client library bug shipped in the latest release) or detect it faster (client error rate spiking before server-side alerting has enough samples). Feed the aggregated client signal into the same decision layer as server signals, with two safeguards: (a) require the signal to be corroborated by a minimum number of distinct devices/regions before it can trigger anything, so one user's flaky home wifi never fires a global rollback; (b) prefer client-triggerable actions that are inherently safe to invoke speculatively, such as a feature-flag rollback (turns off a recently shipped client feature) or server-side throttling of a specific endpoint, over anything destructive, since client signals are noisier than server signals and a false trigger should be cheap to undo.

Worked example

Suppose the last app release shipped a client bug that causes a new checkout screen to hang the main thread for 2+ seconds on older Android devices. Server-side, nothing looks wrong: requests that do get sent complete normally, so server p99 latency and error rate stay flat. Client telemetry aggregated by app version shows: version 4.2.0, Android, UI-hang-duration p95 jumps from 180ms (baseline, previous version) to 2400ms, corroborated across 340 distinct devices in the first 10 minutes post-release across 6 regions. That crosses the minimum-corroboration bar (multiple regions, hundreds of devices, not a handful), so it triggers a feature-flag rollback of the new checkout screen for version 4.2.0 specifically, while a server-only detection system would not have flagged anything at all.

Trade-offs and pitfalls

The central trade-off is signal richness versus privacy and bandwidth: every additional client signal you collect is both a detection improvement and a privacy/cost liability, so default to aggregates and only add a new raw-event type when you have a concrete detection gap it closes. A common pitfall is treating client-reported errors with the same trust as server-reported ones; client environments are wildly heterogeneous (old devices, bad networks, ad blockers, corporate proxies), so a spike that looks alarming in raw client error counts is often just noise from one device class, which is why the region/device-count corroboration threshold above is not optional scaffolding, it is the mechanism that keeps this system from paging on individual users' bad wifi.

Situation: At my last company we were rewriting a core payment service. The team and product favored a quick lift-and-shift to a managed monolith in AWS to meet a tight release date; I recommended redesigning it as small, well-defined microservices to reduce blast radius and enable independent scaling.

Task: Convince engineers and stakeholders who were worried about schedule, operational overhead, and unfamiliarity with microservices.

Action:

• Evidence: I prepared a one-page comparison with concrete data (expected QPS, latency budgets, estimated fault domains) and a cost/benefit table including long-term maintenance, deployment velocity, and incident impact (MTTR estimates).
• Structured debate: Ran a 45-minute focused design review with an agenda, timeboxed pros/cons, and a decision matrix scoring each option against criteria (time-to-market, reliability, developer velocity, cost).
• Handled pushback: Acknowledged valid concerns, proposed mitigations (incremental rollout, service templates, shared observability library), and offered a pilot: extract one non-critical capability into a microservice in the next sprint.
• Negotiation techniques: Used data-driven tradeoffs, offered to own the pilot and mentoring, and aligned the pilot with a stakeholder KPI (reduced incidents for that capability).

Result: Pilot succeeded—deploys became independent and incident impact dropped by 60% for that feature. Stakeholders approved a phased microservice migration, delivered with no missed deadlines. The approach improved developer velocity and reduced incident scope.

This reinforced using measured experiments, clear criteria, and ownership to get buy-in for technically riskier but higher-value directions.

Overview: Goal is high reliability with sustainable human load. Policy splits org into ~20 service teams (avg 10 engineers/team) with shared on-call responsibilities and centralized SRE support for critical infra.

Rotation frequency & shift length:

• Primary on-call rotates weekly per engineer (7-day rotation) with 1-week follow-up overlap (hand-off) and minimum 4 weeks between shifts for any engineer.
• Secondary/backup rotates monthly; SRE escalation rotates fortnightly.
• Shifts: responsibility spans 7 days but daytime incident work limited to defined hours (8am–8pm local). Nights/weekends handled asynchronously with clear SLAs; onsite or active monitoring only when required.

Compensation & recognition:

• Base on-call stipend + per-page credit tiers (e.g., $X/week + $Y per high-severity page beyond threshold) or equivalent time-off credit (1 hour per page -> comp time bank).
• Quarterly on-call excellence awards and inclusion in performance reviews for sustained reliable support and runbook contributions.

Mandatory training:

• 8-hour on-call bootcamp (triage, paging etiquette, escalation, postmortems) for new on-call engineers; annual 2-hour refresh and simulation drills (tabletops/chaos days) per team.

Runbook quality standards:

• Every service must maintain runbooks with: detection symptoms, immediate triage steps, rollback/playbook, key contacts, postmortem link. Runbooks reviewed monthly; 95% of pages must include a runbook entry; automated tests validate runbook applicability.

Paging thresholds & routing:

• Tiered pages: SEV1 (pager, phone call, immediate escalation), SEV2 (pager + Slack), SEV3 (digest email). Use monitoring thresholds tuned to reduce noise: require 2 correlated signals or sustained anomaly for >5 minutes before SEV2, and human-verified alert suppression windows.

Burnout detection & response:

• Metrics: on-call frequency per engineer, page volume, median time-to-ack, after-hours work hours (integrated from calendar/clock-in), PTO utilization, anonymous wellbeing surveys.
• Team-level: weekly lightweight retros for on-call, mandatory recovery day(s) within 72 hours after a SEV1, and enforced no-on-call during approved leave.
• Org-level: quarterly review of metrics by People + EngOps; if thresholds breached (e.g., >15% engineers with >2 SEV1s/month or median sleep loss >2 nights/week), trigger remediation: hire contractors, redistribute ownership, increase automation, or reduce release cadence.
• Psychological safety: blameless postmortems, access to counseling, and manager 1:1 check-ins focused on workload.

Trade-offs: weekly rotations give predictability but require strong handoffs; compensation + recovery days mitigate burden. Prioritize automation and SRE partnership to reduce human toil.