Google Software Engineer (Mid-Level L4) Interview Preparation Guide 2026

Direct answer
A thorough is_prime(n) test suite needs at least: a negative number, the two special small values 0 and 1 (neither prime nor composite by definition), the only even prime (2), an ordinary odd prime, an ordinary composite, and a large input that exercises the algorithm's actual loop bound rather than a value small enough that a broken implementation would pass by coincidence; each of these targets a distinct, plausible off-by-one or definitional bug in a typical trial-division implementation.

Structured elaboration

• Negative numbers: primality is only defined for positive integers greater than 1; a common bug is a modulo-based check that doesn't special-case negatives and returns a wrong answer instead of False.
• 0 and 1: both are explicitly NOT prime by the mathematical definition (a prime must have exactly two distinct positive divisors), but a naive "no divisors found" loop can accidentally return True for both, because a loop like for i in range(2, n) never executes for n < 2 and falls through to a default True.
• 2: the only even prime; a very common bug is an implementation that starts checking divisibility from 2 and then also SKIPS even numbers in its loop for performance, incorrectly excluding 2 itself before the loop even gets a chance to confirm it.
• A small odd prime and a small composite: baseline correctness on the values the function will overwhelmingly see in normal use.
• A large prime and a large composite with a large prime factor: this is the case that actually tests the algorithm's LOOP BOUND, not just its correctness. A correct trial-division implementation only needs to check divisors up to $\sqrt{n}$, because if $n = a \times b$ with both $a, b > \sqrt{n}$, then $a \times b > n$, a contradiction; testing a large composite whose smallest prime factor is itself large (so the loop must run nearly to $\sqrt{n}$ before finding it) is what actually exercises that bound, whereas a small composite like 9 would pass even with a badly wrong loop bound.

Worked example (executed)

def is_prime(n):
    if n < 2:
        return False
    if n in (2, 3):
        return True
    if n % 2 == 0:
        return False
    i = 3
    while i * i <= n:
        if n % i == 0:
            return False
        i += 2
    return True

Five (plus two extra) pytest tests were written and executed, covering exactly the cases above:

test_negative_number_is_not_prime        is_prime(-7) is False
test_zero_and_one_are_not_prime          is_prime(0) is False, is_prime(1) is False
test_two_is_prime_and_only_even_prime    is_prime(2) is True
test_small_known_primes                  is_prime(3) is True, is_prime(13) is True
test_small_known_composite               is_prime(9) is False, is_prime(100) is False
test_large_prime_performance             is_prime(999983) is True
test_large_composite_with_large_prime_factor   is_prime(999983 * 2) is False

Executed with pytest: 7 passed. The large-input test uses 999983 (a genuine prime, confirmed by the passing assertion) specifically because its smallest divisor other than 1 is itself, so the loop runs all the way to $\sqrt{999983} \approx 1000$ without finding a factor, exercising the loop-bound logic in a way that a small composite like 9 (whose smallest factor 3 is found almost immediately) does not. Per house rule, wall-clock timing was measured out of curiosity during this run but is deliberately NOT reported here, since timing is environment-dependent and unverifiable by a reader re-running the suite; the correctness assertion (is_prime(999983) is True) is what the test actually proves.

Trade-offs and pitfalls
The most common wrong turn is treating "performance considerations" as a wall-clock timing assertion (assert elapsed < 0.01), which is banned as a test design because it is flaky across machines and CI runners; the correct way to test performance-relevant behavior without asserting timing is to test the ALGORITHMIC boundary directly, as the large-prime test does here, by choosing an input specifically engineered to force the loop to its true upper bound rather than exit early. A second pitfall is conflating "large" with "slow": for trial division, a large NUMBER that happens to have a small factor (e.g. 999983 * 2, which is even) is fast to reject, while a large PRIME is the actually expensive case, so test data must be chosen by factorization structure, not just magnitude.

Approach: create a debounce that returns a wrapped function and exposes a cancel method. Use a timer for delaying invocation and support immediate (leading) option and proper typing. Cancellation clears pending timer and prevents the scheduled call.

type Fn<T extends any[]> = (...args: T) => void;

function debounce<T extends any[]>(
  fn: Fn<T>,
  wait = 300,
  options: { leading?: boolean } = {}
) {
  let timer: ReturnType<typeof setTimeout> | null = null;
  let lastArgs: T | null = null;
  let calledLeading = false;

  const invoke = () => {
    if (lastArgs) fn(...lastArgs);
    lastArgs = null;
    timer = null;
    calledLeading = false;
  };

  const debounced = (...args: T) => {
    lastArgs = args;

    if (options.leading && !calledLeading) {
      fn(...args);
      calledLeading = true;
      // still start a timer to block trailing immediate repeat
      timer = setTimeout(() => {
        timer = null;
        calledLeading = false;
        lastArgs = null;
      }, wait);
      return;
    }

    if (timer) clearTimeout(timer);
    timer = setTimeout(invoke, wait);
  };

  debounced.cancel = () => {
    if (timer) {
      clearTimeout(timer);
      timer = null;
    }
    lastArgs = null;
    calledLeading = false;
  };

  return debounced as typeof debounced & { cancel: () => void };
}

Usage example (React-style input handler):

const fetchSuggestions = async (q: string) => { /* call API */ };

const debouncedFetch = debounce(([q]: [string]) => fetchSuggestions(q), 250);

function onInputChange(e: React.ChangeEvent<HTMLInputElement>) {
  debouncedFetch(e.target.value);
}

// To cancel (e.g., on unmount)
debouncedFetch.cancel();

Key points:

• Prevents excessive API calls by batching rapid events.
• cancel() avoids stale calls during unmount/navigation.
• Time complexity: O(1) per event; space: O(1).
  Edge cases: ensure cancellation on component unmount, handle leading vs trailing behavior, and pass latest args for trailing invocation.

Direct answer
Most large employers that codify their interview values name broadly similar underlying traits, even when their specific vocabulary differs: a customer or user-first orientation, taking ownership beyond a narrow scope, moving with appropriate urgency, holding a high quality bar, and being trustworthy and transparent recur across nearly every published framework, just under different labels.

Structured elaboration

Worked example
The table above is itself the worked example. A strong candidate should be able to reproduce a table like this from memory for whichever specific company's list they are asked about, translating each of that company's named principles onto one of these five underlying traits, rather than treating an unfamiliar company's vocabulary as an entirely new set of ideas to learn from scratch.

Trade-offs and pitfalls
Treating every company's list as identical is itself a mistake; the values differ in emphasis, and in what is explicitly left off the list. A company whose published list omits any explicit ownership language may culturally deprioritize individual initiative in favor of process, for example, and that is worth noticing rather than flattening away. A candidate who can only speak the vocabulary of one company, fluent in one set of terms but unable to translate the same underlying trait into a different company's language, reads as having memorized rather than internalized the competencies involved.

Direct answer
A short executive postmortem summary should fit in roughly 150 to 200 words and cover exactly four things: impact, root cause in one sentence, key corrective actions, and the expected timeline for completing them. Everything else belongs in the linked full postmortem, not the summary.

Structured elaboration
The discipline here is compression without losing the load-bearing facts: an executive reading this in thirty seconds should know what happened, how bad it was, why, and what's being done, without needing to ask a single follow-up question about the basics.

Worked example
"On [date], an autoscaling policy misconfiguration caused the checkout service to under-provision during a traffic spike, resulting in a three-hour partial outage. Approximately 15% of checkout attempts failed or timed out during the peak of the incident, affecting an estimated 40,000 orders; no customer data was exposed. Root cause: a recent change to the autoscaling policy set a maximum instance count too low for current traffic levels, and no alert existed to catch an autoscaling ceiling being reached. Immediate mitigation: on-call manually scaled the service within 12 minutes of detection, and full service was restored within three hours as the traffic spike subsided. Corrective actions: (1) raise the autoscaling ceiling to match current capacity planning, completed same day; (2) add an alert that fires when autoscaling hits its configured ceiling, targeted for completion within one week; (3) add autoscaling ceiling review to the quarterly capacity-planning process, targeted for next quarter. We expect all three actions complete within 30 days and will confirm the new alert has been validated against a synthetic test before considering this closed."

That's roughly 180 words and answers all four required elements without technical jargon an executive would need explained.

Trade-offs and pitfalls
The most common mistake is trying to also explain the full technical mechanism (why the specific autoscaling algorithm behaved this way) inside the short summary, which blows past the word budget and buries the four things that actually matter to this audience. A second is omitting a concrete timeline and just saying 'we are addressing this,' which reads as less credible than named actions with dates, even when the actions themselves are modest.

Situation: I needed the Support team to invest time in a new escalation process, but I had no formal authority over them.

Task: My job was to earn their support instead of asking for compliance.

Action: I started by learning what mattered to them. I met with the support manager and a few frontline agents to understand their pain points. The main issue was that they were already overloaded, so any new process had to save time, not add work. I then reframed my initiative in their language. Instead of talking about my project milestones, I showed how the change would reduce repeat tickets and make it easier to resolve customer issues on the first contact. I also offered a small pilot so they could test the idea before committing fully.

Result: Because I tied the request to their goals and reduced the burden, they agreed to participate and became active partners in the rollout.

What I learned is that influence comes from understanding the other function’s priorities, showing respect for their constraints, and making the benefit concrete.

Direct answer

Python computes MRO (Method Resolution Order), the linear order in which base classes are searched for an attribute or method, using the C3 linearization algorithm. For class A, class B(A), class C(A), class D(B, C), the MRO is [D, B, C, A, object]: D first, then its bases left to right (B before C, matching the declared order in class D(B, C)), with A appearing only once, after both of its subclasses, never before either of them. This matters for super() because super() doesn't mean "my direct parent"; it means "whatever comes next in the MRO," so the MRO is what actually determines which implementation a chain of super() calls reaches at each step.

Structured elaboration

Why not just "depth-first, left to right" (Python 2's old classic-class behavior)? That naive rule would visit D, B, A, C, A, walking through A twice and, worse, visiting it in an order that puts it before C gets a chance to run first. C3 linearization fixes this with three constraints simultaneously:

1. A class always appears before its own base classes (local precedence).
2. The order bases were listed in a class definition is preserved (B before C in D(B, C)).
3. Any given class appears in the final MRO exactly once, at the position where all of the above constraints are still satisfiable (monotonicity).

Applied to the diamond A / B(A) / C(A) / D(B, C): D must come first (constraint 1). B must come before C (constraint 2, from D's base list). A must come after both B and C because it's a base of both, and neither B nor C can be reordered relative to each other or to A without violating a constraint. The unique linearization satisfying all of that is [D, B, C, A, object]. If the constraints were unsatisfiable (a genuinely contradictory base ordering across the hierarchy), Python raises TypeError: Cannot create a consistent method resolution order at class-definition time rather than picking an arbitrary order.

Why this matters for super() specifically: super() inside a method looks up "the next class after the current one in the instance's MRO," not "my declared parent class." In cooperative multiple inheritance (several mixins each calling super().__init__(...) to chain to the next one), the actual chain that executes depends entirely on the concrete class's MRO, which can differ from what any single class in isolation would suggest. This is what makes mixin-based designs (logging mixins, serialization mixins, resource-management mixins) predictable: as long as every class cooperates via super() rather than naming a base class directly, the MRO guarantees each one runs exactly once, in a well-defined order, regardless of how deep or diamond-shaped the hierarchy gets.

Worked example

class A:
    def foo(self):
        return "A"

class B(A):
    def foo(self):
        return "B"

class C(A):
    def foo(self):
        return "C"

class D(B, C):
    pass

print([c.__name__ for c in D.mro()])   # ['D', 'B', 'C', 'A', 'object']
print(D().foo())                       # B

D doesn't define foo itself, so attribute lookup walks the MRO starting right after D: B is the first class in that list that defines foo, so D().foo() returns "B", never reaching C.foo or A.foo at all for this particular call.

Trade-offs & pitfalls

• If B and C both call super().foo() instead of returning directly, the MRO is what makes D().foo() walk through B.foo() -> super().foo() reaching C.foo() next (not A.foo() directly), because C is the next entry after B in D's MRO. This cooperative-chaining behavior is easy to get backwards if you assume super() means "go to my own declared parent," since B's declared parent is A, but B's super() in an instance of D resolves to C.
• Declaration order in the base-class list is a real, load-bearing design decision, not an arbitrary detail: class D(B, C) and class D(C, B) produce different MROs ([D, B, C, A, object] vs. [D, C, B, A, object]) and therefore different behavior for both plain method lookup and super() chains, even though the two class hierarchies "look the same" if you only read class B(A) and class C(A) in isolation.
• A common wrong turn: assuming multiple inheritance always "just works" by mentally picking whichever base's method feels intended, and only inspecting Class.mro() after something behaves unexpectedly. Since MRO is computable and inspectable (D.mro() or D.__mro__) before you ever run the code, checking it up front for any non-trivial mixin hierarchy is cheap and removes the guesswork entirely.
• Not every base-class ordering is linearizable. A contradictory set of base classes (for example, inheriting from two classes that each demand a different relative order for a shared ancestor) causes Python to refuse to create the class at all, raising TypeError rather than silently picking an inconsistent order.

Direct answer

When speed and a longer-term investment conflict, I don't treat it as a binary between shipping fast and doing it right. I pick one of defer, reduce, or accept deliberately, write down which one and why, and attach a concrete trigger for when we repay it, so the debt is a tracked decision instead of something that quietly accumulates. The story below is one where I reduced scope rather than deferring or fully accepting, and the repayment schedule I set is what actually paid off later.

Structured elaboration

The three options are genuinely different commitments, not synonyms:

• Defer: do the full, correct thing later, untouched, once time allows. Appropriate when the shortcut has no partial version worth building now.
• Reduce: ship a smaller, real version now that deliberately leaves an extension seam, so the eventual full version doesn't require ripping out what shipped. Appropriate when a thin slice actually satisfies the urgent need.
• Accept: this is genuinely good enough long-term, not just for now; there is no debt to repay.

Whichever I pick, I document it as a short decision record: the situation, the option chosen and why, the estimated cost to repay if it isn't "accept," and who signed off. That sign-off matters, buy-in from whoever actually owns the downstream risk (an engineering lead, a product lead, sometimes compliance) turns a private engineering call into a decision the organization actually made.

For tracking repayment, a ticket alone isn't enough; I attach it to a concrete trigger, not just a calendar date, so it survives the next deadline crunch: "revisit when event X happens, or by date Y, whichever comes first." That gets it onto a recurring planning review instead of living only in one person's memory.

Worked example

Situation: I owned a checkout service's integration with a payments provider. The existing provider's certification was expiring in six weeks, and the proper long-term answer was a provider-agnostic adapter layer so we could plug in additional providers later without touching checkout code again.

Task: build an adapter layer in six weeks was not realistic alongside everything else already committed that quarter, but missing the certification deadline meant losing the ability to process new customer payments entirely.

Action: I chose reduce, not defer or accept. I shipped a direct, hardcoded integration to the new provider's API in three weeks, inside the six-week window, but deliberately isolated all provider-specific calls behind a single internal function boundary instead of scattering them through checkout code, so a future adapter layer could replace that one function without touching the rest of the system. I wrote a one-page decision doc: the certification deadline, why a full adapter layer wasn't in scope now, the roughly two-week estimate to build it properly later, and the extension seam I'd left. My engineering lead and product lead both signed off in writing. I filed a ticket tagged as tracked debt, owned by me, with the trigger "revisit when a second payment provider is needed, or by the end of next quarter, whichever comes first," and added it to the quarterly roadmap review.

Result: we hit the certification deadline and kept checkout running with no interruption. Two quarters later the business added a second regional payment provider, which triggered the repayment exactly as planned rather than as a surprise. Building the adapter layer took about two weeks, matching the original estimate, and integrating the second provider on top of it took about one week, roughly a third of the three weeks the first, hardcoded integration had taken. The measurable outcome was that reduced-scope decision: it protected the compliance deadline immediately, and the documented seam meant the second integration was three times faster than the first, because the debt had been paid down exactly when its own trigger said it should be.

Trade-offs and pitfalls

• Reducing scope only stays honest if you actually design the extension seam; skip that step and "reduce" quietly becomes "defer with extra steps," because nothing is easier to plug in later.
• Getting sign-off matters most when the risk being accepted isn't purely technical; here compliance exposure meant a product lead's buy-in, not just an engineering lead's, was the right bar.
• Tying repayment to a trigger event as well as a date protects against the same deadline pressure that created the debt in the first place quietly pushing the calendar date out again.
• The honest measurable outcome here is a relative speedup (about three times faster second integration) and an avoided compliance/outage risk, not a precise revenue figure I can't actually derive; resist the pull to inflate a STAR result with a number you can't substantiate.
• The riskiest failure mode in this pattern is letting "reduce" scope creep back toward the full original ask under deadline pressure; explicitly separating what's being cut now from what's being preserved is what keeps the smaller version real.

Approach: Use a doubly-linked list for recency (head = MRU, tail = LRU) and a hashmap key->node for O(1) lookup. Each node stores key, value, and size_bytes. Maintain current_bytes; capacity_bytes is the approximate max. On put, if new item causes current_bytes>capacity, evict from tail until under capacity (or until only the new item if it itself exceeds capacity — handle per policy).

class Node:
    def __init__(self, key, value, size):
        self.key = key
        self.value = value
        self.size = size
        self.prev = None
        self.next = None

class LRUCacheByBytes:
    def __init__(self, capacity_bytes):
        self.cap = capacity_bytes
        self.curr = 0
        self.map = {}           # key -> Node
        self.head = None        # MRU
        self.tail = None        # LRU

    def _remove_node(self, node):
        # unlink node
        if node.prev: node.prev.next = node.next
        else: self.head = node.next
        if node.next: node.next.prev = node.prev
        else: self.tail = node.prev
        node.prev = node.next = None
        self.curr -= node.size
        del self.map[node.key]

    def _add_to_head(self, node):
        node.next = self.head
        if self.head: self.head.prev = node
        self.head = node
        if not self.tail: self.tail = node
        self.map[node.key] = node
        self.curr += node.size

    def get(self, key):
        node = self.map.get(key)
        if not node: return None
        # move to head (MRU)
        self._remove_node(node)        # removal updates curr & map
        self._add_to_head(node)        # re-add updates curr & map
        return node.value

    def put(self, key, value, size):
        # If exists, remove old instance first
        if key in self.map:
            self._remove_node(self.map[key])
        node = Node(key, value, size)
        # Evict until there is room. Policy: allow storing item even if bigger than capacity by evicting all others;
        # alternatively, skip insertion if size > cap (choose based on requirements).
        while self.curr + size > self.cap and self.tail:
            self._remove_node(self.tail)
        # If still doesn't fit (item > cap and cache empty), decide: store single large item or reject.
        self._add_to_head(node)

Key points:

• get/put are O(1) average: hashmap ops + constant pointer updates.
• Memory accounting: each node tracks size; curr is adjusted on add/remove.
• Eviction behavior: when sizes vary, a single very large item may evict many small ones. Choose policy:
  • Accept large item by evicting all others (simple, ensures insertion succeeds).
  • Reject items larger than cap (prevents cache pollution).
  • Use admission policies (e.g., only admit if larger than some hit-rate threshold).
• Edge cases: concurrent access (use locks), approximate size estimation for complex values, fragmentation when sizes change on update.

Direct answer

Break the estimate into three buckets, compute, storage, and network egress, state a small number of explicit assumptions for each (traffic shape, cache hit ratio, unit prices), and multiply through. For this workload, 1,000,000 requests/day and 10 TB of outbound data/month, the arithmetic below lands around 1,246 dollars/month using illustrative unit rates, with network egress the dominant line item. The one sanity check worth doing at the end is dividing total outbound data by total requests: it implies each request carries roughly 333 KB on average, which is large for a "simple web app" and should prompt asking whether the two given numbers actually describe the same traffic.

Structured elaboration

Why three buckets, always kept separate
Compute, storage, and network egress scale with different things (request rate, data volume at rest, data volume transferred), so lumping them together hides which one actually drives the bill. For a workload described mainly by a request count and an outbound-data figure, network egress is very often the surprise line item, since it scales with bytes moved, not with request count.

Stated assumptions (illustrative unit rates, not any specific vendor's current list price, so the arithmetic below is fully reproducible from these inputs alone):

• 1 TB = 1,000 GB for this estimate (a decimal convention, kept simple and stated once; real billing sometimes uses the binary definition instead).
• A 5x peak-to-average traffic ratio, a common assumption absent a stated diurnal profile.
• Compute: $0.10 per instance-hour; a minimum of 3 instances regardless of load, for basic redundancy and zero-downtime deploys.
• Storage: a flat $20/month (small, since a "simple web app" is not primarily a database- and storage-heavy workload).
• Network: 60% of requests served from a content delivery network (CDN) cache; origin egress (cache misses only) at $0.09/GB; CDN edge egress (all bytes delivered to users) at $0.06/GB.
• Miscellaneous (load balancer, monitoring, DNS): $50/month.

Worked example

Compute.

$\text{avg RPS (requests per second)} = \frac{1{,}000{,}000}{86{,}400} \approx 11.6, \qquad \text{peak RPS} \approx 11.6 \times 5 \approx 58$

Even one modest instance clears 58 req/s comfortably for a typical stateless web app, so the instance count here is driven by redundancy, not raw capacity: 3 instances.

$\text{compute} = 3 \times \$0.10/\text{hr} \times 24 \times 30 = \$216/\text{month}$

Network egress, the dominant cost for this workload. Two separate legs, both real: the cache-miss traffic the CDN pulls from the origin (pricier), and the full volume the CDN delivers to end users regardless of hit or miss (cheaper, volume-discounted).

$\text{miss traffic} = 10{,}000 \text{ GB} \times (1 - 0.6) = 4{,}000 \text{ GB}$

$\text{origin cost} = 4{,}000 \text{ GB} \times \$0.09/\text{GB} = \$360$

$\text{CDN cost (all delivered bytes)} = 10{,}000 \text{ GB} \times \$0.06/\text{GB} = \$600$

Total.

$\text{total} \approx \$216 + \$20 + \$360 + \$600 + \$50 = \$1{,}246/\text{month}$

Sanity check, the part the question explicitly asks for. Cross-check the two given numbers against each other, not just against the chosen unit prices:

$\text{requests/month} = 1{,}000{,}000 \times 30 = 30{,}000{,}000$

$\text{avg payload} = \frac{10{,}000 \text{ GB} \times 1000 \text{ MB/GB}}{30{,}000{,}000} \approx 0.33 \text{ MB} \approx 333 \text{ KB per request}$

A typical JSON API response is a few KB, not a third of a megabyte. A 333 KB average suggests this "simple web app" is actually serving images, downloads, or media, not just API calls, or that the two input numbers don't describe the same traffic, for instance if the 10 TB includes a batch export job outside the 1,000,000 daily request count. That is the real value of this sanity check: it isn't re-verifying the arithmetic, it's confronting whether the two numbers handed to you are internally consistent with the story you were told, before handing a stakeholder a dollar figure built on an unstated contradiction.

Trade-offs & pitfalls

• Pricing only one leg of egress (origin-to-CDN or CDN-to-user) and treating the network line item as done.
• Skipping the sanity check and presenting the total as precise when the underlying assumptions (cache hit ratio, peak ratio) were guesses; state which input the total is most sensitive to.
• Sizing compute purely off average load; for small-to-medium workloads, redundancy and deploy safety often set the compute line, not raw throughput math.
• What separates a senior answer: showing the arithmetic and stating which two given numbers were cross-checked at the end, and why, rather than presenting a total as if it fell out of a spreadsheet with no further scrutiny.

Approach (high-level): treat this as an incident—stabilize user impact, collect data, form hypotheses, test/mitigate, find root cause, fix and document. Work in short iterations and communicate frequently.

Initial hypotheses (prioritized):

• Memory leak in recent deploy (new code or library)
• Increased traffic or workload pattern causing caches/buffers to grow
• Retention in background jobs or goroutines/threads
• GC pressure or native memory (JNI, C extensions)
• Configuration change (cache size, pooling) or resource regression

What I’d check first (metrics/logs/traces):

• Service metrics: RSS, heap usage, GC pause time, allocation rate, number of threads/processes (Prometheus/Grafana).
• Latency metrics: p95/p99, error rate, QPS correlated with memory.
• Recent deploys/rollouts and config changes (CI/CD, git history).
• Application logs around high memory events and OOMs.
• Traces (Jaeger/Zipkin) to see slow endpoints or long-lived spans.
• Host metrics: swap, disk, kernel OOM logs.
• JVM/CPython/Go profilers: heap dumps, pprof, allocation flamegraphs.

Experiments & mitigations (safe, incremental):

• Roll back recent deploy to confirm hypothesis.
• Reproduce on staging with increased load and profiling enabled.
• Take heap dump / pprof at multiple points; generate flamegraphs to find retaining objects.
• Temporarily restart service or scale up replicas as emergency mitigation (document and automate).
• Add rate-limiting or disable risky feature behind a feature flag.
• Tune GC or reduce cache sizes as short-term.
• If native memory, check native allocation stacks.

Validation & fix:

• Patch the code (e.g., fix retained references, close resources), add unit/integration tests, and re-run load tests with profiler.
• Deploy canary, monitor memory and latency before full rollout.

Communication:

• First 15 min: acknowledge, severity, who’s responding, immediate mitigation being applied.
• Every 30–60 min: short status updates (current p95, memory trend, actions taken, next steps).
• Post-mortem within 48 hrs with root cause, timeline, remediation, and follow-ups (monitoring dashboards, alerts, test coverage).

This approach balances user impact, data-driven diagnosis, safe experimentation, and clear stakeholder updates.