Senior Site Reliability Engineer Interview Preparation Guide - Spotify

Direct answer

Moving off sticky sessions means moving the session state somewhere every backend can reach, so the LB no longer needs to remember which instance served a user. The three options, an external store (Redis or DynamoDB), a signed JWT, or a client-encrypted cookie, trade off differently on latency, revocation, and operational complexity, and the safest rollout treats this as a staged migration with a working rollback at every step, not a single cutover.

Comparing the three approaches

A common pattern that resolves the tension: short-lived JWTs (or encrypted cookies) for the common case, backed by a lightweight server-side store used only for the sessions that actually need early revocation (a logout, a compromised-account response), instead of paying store latency and store operational cost on every single request.

Worked example: capacity planning for the store option

If the API currently handles $5{,}000$ requests per second at peak and every one of them will look up session state after migration, the session store has to sustain at least that read rate. Provisioning with headroom (a common starting point is 50%) gives a capacity target of:

That is the number to load-test the store against before cutover, not the number you discover you needed during the first real traffic spike after migration.

Rollout plan

1. Dual-write, keep stickiness on. Introduce the new session store (or start issuing tokens) alongside the existing sticky-session behavior, so nothing user-facing changes yet, but you can validate correctness (does the store have what the in-memory session had) and measure latency and store load under real traffic.
2. Canary read path. Route a small percentage of traffic (start around 1%, a percentage you can quickly widen or zero out) to read from the new session mechanism instead of relying on affinity, while stickiness stays on as a safety net for everyone else. Compare error rates and session-consistency between the canary cohort and the control group.
3. Widen gradually. Step the canary percentage up (1% to 10% to 50% to 100%) only after each step holds steady, with an explicit rollback trigger: if the canary cohort's error rate or session-mismatch rate exceeds the control group's by a meaningful margin, drop back to the previous percentage immediately rather than investigating first.
4. Disable stickiness. Once 100% of traffic is confirmed reading correctly from the new mechanism, turn off session affinity at the LB. Keep the old in-memory session path dark (deployed but unused) for one more cycle so it's a one-line revert, not a redeploy, if something surfaces late.
5. Remove the old path. Only after that final safety window, delete the in-memory session code so there's no drift between what's live and what's supported.

Throughout, connection draining matters more, not less: once affinity is off, any instance can be taken out of rotation for a deploy at any time, so graceful shutdown (finish in-flight requests, stop accepting new ones) has to be solid before you rely on it as the normal operating mode instead of an edge case.

Trade-offs and pitfalls

The most common mistake is cutting over all at once because the change "looks simple" (swap a cookie mechanism), which skips the chance to catch a subtle bug, like a field that existed in the in-memory session but was never migrated to the new store's schema, before it affects 100% of users. Another pitfall specific to the token-based paths: teams discover mid-migration that a session held more state than fits comfortably in a JWT or encrypted cookie (shopping cart contents, multi-step form progress), at which point the honest fix is usually to keep that specific state server-side (the external-store option) rather than growing the token past a size where it adds real latency and cookie-size problems. Revocation is the other recurring gap: if the product needs "log out everywhere" or a fast response to a compromised session, a pure JWT approach without any server-side tracking cannot deliver that without a redesign.

Direct answer

Maintain an inclusive range [lo, hi] that is the only place the target could still be. At each step, compare the target to the middle element and shrink the range to whichever half could still contain it. The loop ends when lo > hi, at which point the target is not present, so return a sentinel (commonly -1). This runs in $O(\log n)$ time and $O(1)$ space.

Structured elaboration

The loop invariant. Before every iteration, "if the target is present in the array, its index lies within [lo, hi]" holds. Each iteration either returns immediately (found it) or moves lo past mid, or hi before mid, which strictly shrinks the range while preserving the invariant.

Why it terminates. Every iteration where the target is not found at mid removes at least the midpoint from consideration, so hi - lo at least halves (roughly) each time; the range cannot shrink forever without becoming empty, so the loop reaches lo > hi within $O(\log n)$ steps.

Why it never reads out of bounds. mid is always computed strictly between the current lo and hi, both of which start as, and remain, valid indices into the array (or the empty range lo > hi, which the loop condition catches before computing mid at all).

The overflow bug (reviewing someone else's code). Suppose a colleague wrote mid = (lo + hi) // 2. In Python this is safe because integers have arbitrary precision, but in a fixed-width-integer language such as Java or C++, lo + hi can exceed the maximum representable value for a very large array and silently wrap around, producing a corrupted mid that can throw the search out of bounds or into an infinite loop. Writing mid = lo + (hi - lo) // 2 avoids this because hi - lo never exceeds the array's size, so the sum can never overflow the way lo + hi can.

Worked example

def binary_search(nums: list[int], target: int) -> int:
    lo, hi = 0, len(nums) - 1
    while lo <= hi:
        mid = lo + (hi - lo) // 2  # avoids the lo + hi overflow above
        if nums[mid] == target:
            return mid
        elif nums[mid] < target:
            lo = mid + 1
        else:
            hi = mid - 1
    return -1


if __name__ == "__main__":
    nums = [1, 3, 5, 7, 9, 11]
    print(binary_search(nums, 7), binary_search(nums, 4))

Running this prints 3 -1. For target 7: lo=0, hi=5, mid=2 (value 5, too small, lo becomes 3); lo=3, hi=5, mid=4 (value 9, too big, hi becomes 3); lo=3, hi=3, mid=3 (value 7, match, return 3). For target 4: the range keeps shrinking until lo exceeds hi without ever matching, returning -1.

Complexity

Time: $O(\log n)$, since each iteration discards at least half of the remaining [lo, hi] range.
Space: $O(1)$ for this iterative version, since only a fixed number of index variables (lo, hi, mid) are held regardless of the array's size.

Edge cases

• Empty array (len(nums) == 0): lo = 0 and hi = -1 start with lo > hi, so the loop body never runs and the sentinel -1 is returned immediately.
• Target smaller than every element or larger than every element: the range shrinks to empty without ever matching, again returning the sentinel.
• Array with duplicate values: this exact routine returns the index of some matching element, not necessarily the first or last one; that is a distinct, slightly more involved variant.

Trade-offs & pitfalls

A recursive version expresses the same logic but spends $O(\log n)$ call-stack space doing so, where this iterative version uses $O(1)$. The other classic source of infinite loops or off-by-one errors is mixing bound conventions, for example initializing hi = len(nums) (a half-open convention) while writing the rest of the loop as if hi were an inclusive index; pick one convention and keep it consistent throughout.

A runbook being written isn't the same as it being trustworthy under pressure: writing tests whether the author understood the system, while readiness tests whether someone else, half-awake at 3am, can follow it and get the right outcome. Check readiness by having someone who didn't write it actually execute it against a real (or realistic) system, not by reading it for completeness.

What to check before trusting a runbook

• Has anyone other than the author run it? A runbook the author has never handed to someone else is unverified by definition; the author's own mental model fills gaps a stranger will trip on (an assumed tool is installed, an assumed permission is already granted, a step that says "check the dashboard" without saying which one).
• Are the steps executable as written, not just described? "Restart the service" is a description; "run systemctl restart payments-api on each of the 3 hosts listed in the service registry" is executable. If a step requires judgment the runbook doesn't supply (how do you know which hosts?), that's a gap, not an acceptable level of abstraction.
• Does it state what success looks like? A remediation step without a stated verification step (what metric or log line confirms this worked) leaves the responder guessing whether to move to the next step or escalate.
• Is it safe to run when the diagnosis is wrong? Incident responders under pressure sometimes run the wrong runbook, or run the right one when the actual cause differs from what it assumes. Check whether each destructive step is reversible, and whether the runbook states a precondition to verify before acting ("only run this if X").
• Is it current? Check for an owner and a last-verified date; a runbook referencing a deprecated tool, an old cluster name, or a rotation that no longer exists is worse than no runbook, because it costs time before the responder realizes it's wrong.

How to actually verify these, not just check for their presence

1. Tabletop walkthrough: someone unfamiliar with the runbook reads it aloud, step by step, without help from the author, narrating what they'd actually type or click. Gaps surface immediately as "wait, what do I do here?" moments.
2. Staging or canary drill: run the actual remediation against a staging environment or a single canary instance, and time it. This catches steps that look right on paper but fail against the real system (a command with an outdated flag, a permission the on-call role doesn't actually have).
3. Cold-open test: hand it to someone with zero context on this specific service (not zero context on the systems generally) and see if they can act on it in under a target time, without pinging the original author. If they can't, the runbook is only usable by the person who wrote it, which defeats the point.

Worked example

A runbook for "database replica lag alert" says: "Check replica lag, if high, failover to standby." A cold-open drill immediately exposes three gaps: no link to where replica lag is displayed, no threshold for what counts as "high" (the alert already fired, so this should already be answered, but the runbook re-asks the question), and "failover to standby" doesn't say which standby if there are multiple, or what to verify afterward to confirm the failover succeeded rather than made things worse. Fixing it: link the specific dashboard panel, state the alert's own threshold so the runbook doesn't require re-deciding it, name the failover command with the specific standby-selection logic, and add a verification step ("confirm write latency on the new primary is under 50ms and replica lag on remaining replicas is decreasing"). Re-running the cold-open drill after the fix, the same tester completes it without asking a clarifying question, which is the actual pass condition.

Trade-offs and pitfalls

Running live drills has a real cost in engineering time and, for staging drills, some risk if the environment isn't well isolated from production; the return is worth it for any runbook covering a high-severity or destructive action, and can be scaled down to tabletop-only for low-risk, easily reversible ones. A common wrong turn is treating runbook review as a documentation-quality pass (is it well written, does it have headers) rather than an execution test; a beautifully formatted runbook that's never been run by anyone but its author is still unverified.

Framing

The core tension is that provisioning for the sum of every tenant's individual peak wastes money, since tenants rarely peak at the same moment, but provisioning only for the average starves whichever tenant happens to be bursting at any given time. The fix is a two-tier capacity model: pool most tenants together to take advantage of the fact that their peaks do not line up, and give the few tenants whose scale or contract demands it their own dedicated, isolated capacity.

Tiering tenants by usage pattern

• Long-tail tenants (the majority by count, small individually): share a common autoscaled pool. Statistical multiplexing means the pool only needs to be sized for the aggregate's observed peak, not the sum of every tenant's own peak, since it is unlikely that all of them burst at once.
• Top tenants (by volume or by a contractual SLO, service-level objective): move to dedicated, reserved capacity (paying upfront, or committing to a usage volume for a set term, in exchange for a lower per-unit rate than paying on demand), sized to their own historical peak. Since their usage is large and comparatively predictable, this is also where a reserved or committed-use purchasing discount pays off, since there is little guesswork about whether the capacity will be used.
• The line between shared and dedicated is not fixed; a tenant graduates to dedicated capacity once their marginal cost of staying in the shared pool, including the risk they periodically starve everyone else, exceeds the cost of a small dedicated reservation.

Autoscaling and isolation

• The shared pool autoscales on aggregate demand, with headroom sized from the observed combined peak, not the sum of individual peaks, plus a buffer for the rare case where several mid-size tenants do burst together.
• To stop one tenant from starving another inside the shared pool (the noisy-neighbor problem), enforce per-tenant rate limits or resource quotas (requests per second, concurrent connections, or CPU/memory quotas if tenants share compute), so a single tenant's burst is capped well below the pool's total capacity rather than able to consume all of it.
• Dedicated tenants get real isolation, not just a quota: separate compute (their own node pool or instances), so their traffic pattern cannot affect the shared pool or other dedicated tenants at all.

Cost allocation and chargeback (the practice of billing a shared resource's cost back to whichever team or tenant actually used it)

Track actual per-tenant consumption (requests served, CPU-seconds, bytes processed) even for tenants in the shared pool, both to fairly attribute the pool's cost across tenants and to have the data that triggers the graduate-to-dedicated decision above. Without this, right-sizing spend to actual usage is a slogan, not something you can act on.

Worked example (illustrative)

Say there are 200 tenants collectively averaging 1,000 requests/sec, but individual tenant peaks summed together would call for provisioning 5,000 requests/sec of capacity if sized for the worst case per tenant. Because those individual peaks do not happen simultaneously, the observed combined peak across all 200 tenants might only be around 1,800 requests/sec. Provisioning the shared pool for roughly 1,800 requests/sec plus a 20% buffer (about 2,200 requests/sec) captures nearly all of that combined peak at under half the cost of provisioning for the sum of individual peaks, with the rare simultaneous-peak edge case absorbed by autoscaling headroom and per-tenant rate limits rather than by permanently over-provisioned capacity. The 5 largest tenants, representing maybe 40% of total load, are pulled out into dedicated reserved capacity so their own peaks never compete with the shared pool at all.

Trade-offs

The shared pool is cheaper per unit of capacity but couples tenants' performance together; get the isolation quotas wrong and one tenant's incident becomes everyone's incident. Dedicated capacity is safer for the tenants that need it but is only cost-effective for tenants large and predictable enough to keep it well utilized; putting a small tenant on dedicated capacity wastes money the same way sizing for the sum of peaks does.

First 0–5 minutes (kickoff)

• Open a single war-room (Zoom / Meet) and a dedicated incident Slack channel. Trigger PagerDuty/OpsGenie to gather on-call.
• Create a one-page incident doc (Google Doc or Confluence) as the single source of truth (SoT): timeline, hypothesis, actions, owners, status.

Role assignments (immediate)

• Incident Commander (IC) — you: run the room, prioritize, make decisions.
• Scribe — writes in SoT and records timestamps.
• Lead Engineers (Infra, Network, App, DB) — own diagnosis & fixes for their domain.
• Triage/Mitigation engineers — implement fixes or rollbacks.
• Communicator/Liaison — updates execs/customers and controls external comms.
• QA/Verification — validates mitigations in staging/production.

Ground rules

• Voice is authoritative for decisions; Slack used for logs/links only.
• One active action per owner; declare ETA and expected outcome.
• No side-chats that impact decisions; mute non-essential alerts.
• Timebox discussion to keep momentum.

Prioritization method

• Use impact × urgency: number of users/services affected, SLO breach risk, revenue/customer-facing impact, and blast radius. Triage highest-impact items first. If multiple critical paths, work them in parallel with clear owners.

Preventing information overload

• Enforce the SoT as single truth; pin key dashboards (Grafana), logs (Kibana/ELK), and runbooks.
• Use a brief cadence: IC gives 2-minute status every 10–15 minutes; leads post 1–2 line updates to SoT.
• Funnel telemetry: only post summarized alerts; mute noisy alerts and create filtered views.
• Use an action board (Trello/Jira): To Do / In Progress / Verifying / Done, with owners and ETAs.

Keeping progress visible

• Scribe maintains timeline and action board; IC posts a short public update every 15 minutes (what we tried, next steps, ETA).
• Mark resolved sub-incidents and update customers via status page or comms owner.
• At 60 minutes: IC assesses whether to escalate response level or declare containment and move to detailed RCA planning.

Why this works

• Single SoT + clear roles prevents duplication and confusion. Timeboxed cadence keeps focus and reduces noise. Explicit ownership and visible boards ensure progress and accountability while enabling parallel work on multiple critical paths.

Direct answer

Translate the same underlying numbers into the currency each side actually spends: dollars and payback timing for the CFO, customer impact and mitigation for the customer success leader. Never invent a rosier set of facts for one room and a grimmer set for the other, that gap is what gets you caught later.

Structured elaboration

• Find the audience's real currency. The CFO spends in dollars, timelines, and risk-adjusted return. The customer success leader spends in churn risk, commitment exposure, and what they can tell a customer who asks "why is X delayed."
• State the trade-off once, plainly, before either framing. "Cutting cloud spend 15% costs us about a quarter of our normal feature throughput for one quarter." Say that sentence to both rooms; only what comes after it changes.
• Pair every ask with a mitigation, not just a number. Which features are protected, what customer success can say to a customer waiting on something specific.
• The same move generalizes. This exact discipline, name the technical mechanism once in plain words, then answer what it costs, saves, or risks in the listener's own terms, is what's behind a wide range of asks: a circuit-breaker elevator pitch, eventual consistency versus strong consistency explained in a sales conversation with a customer, defending a message-queue decision to a CTO, walking a buyer through your benchmarking methodology without the underlying statistics, a latency-versus-cost trade-off for a CFO, capability-versus-business-outcome framing, and translating a model's fairness or bias risk into business and legal-risk language for Legal and HR. All of them are the same two sentences: here's the mechanism in plain words, here's what it costs or saves you.

Worked example

Assume the team's cloud spend on this service is $200k/month ($2.4M/year). A 15% reduction saves $360k a year in recurring cost (2,400,000 x 0.15 = 360,000), and it keeps saving every year after, not just this quarter.

Assume the team normally ships about 20 story points per sprint, 6 sprints in a quarter, 120 points a quarter. A 25% velocity cut for one quarter means roughly 90 points shipped instead of 120, a 30-point gap that recovers once the quarter ends.

To the CFO: "This gets us $360k a year in recurring savings, an engineering change that effectively pays for itself within the first quarter. The cost is temporary: this quarter we ship about 30 story points less than our usual 120, then throughput returns to normal."

To the customer success leader: "For one quarter we're shipping roughly a quarter less feature work. Nothing customer-committed or SLA-bound moves, we're deferring lower-priority backlog items instead. Here's the specific list of what's protected, so if a customer asks about something they were promised, you have a direct answer."

Trade-offs & pitfalls

Don't let the CFO conversation slide from legibility into a persuasion pitch ("this is obviously worth it"). Your job here is to give them the real number and the real timeline and let them own the decision, not to sell it. Don't let the customer success framing hide the size of the cut behind vague reassurance ("don't worry, it'll be fine"), a specific list of what's protected and what's deferred is what actually reduces their anxiety, vagueness increases it. And watch the subtler trap: quoting a bigger savings number to the CFO than the actual velocity hit implies, or a smaller velocity hit to customer success than the CFO conversation implies, that inconsistency costs you credibility with both rooms the moment they compare notes.

Direct answer

The plan that avoids quietly breaking consumers treats deprecation as a product launch in reverse: know exactly who depends on the thing, prove the replacement is equivalent before asking anyone to move, make moving cheaper than staying, and only enforce a hard cutoff once support and time have genuinely been offered, not as the first move.

Structured elaboration

• Inventory consumers before touching anything, ranked by criticality and how hard they are to reach. An internal dashboard owner you can message directly is a different problem from an external, third-party client integrated against a public API, where you may not even have contact details. External consumers change the plan: they need a versioned interface and a public migration guide, not an internal announcement, because you cannot force their hand the way you can an internal team's.
• Prove equivalence before asking anyone to move, with an automated comparison between old and new outputs running continuously, not a one-time spot check, so drift between the two systems surfaces before a consumer hits it in production.
• Make migration cheap. A working reference implementation, sample code, and dedicated support time lower the activation energy far more than a deadline does on its own.
• Roll out in stages gated by evidence: shadow mode first, where the new path runs but nothing depends on it yet, then opt-in migration for lower-risk consumers, then the highest-criticality consumers last, and only once earlier stages show clean parity.
• Set a real enforcement mechanism for the deadline. A deprecation date with no consequence attached to missing it is a suggestion, not a plan: after genuine support has been offered and warnings given, the old path actually gets disabled, with a narrow, time-boxed compatibility adapter as the last resort for a documented exception, not the default path for anyone who is slow to move.
• The same playbook covers consolidation, not just deprecation. Several near-duplicate pipelines maintained by different teams get inventoried and equivalence-tested exactly the same way; they converge into a single new destination instead of retiring entirely.

Worked example

An internal event that product and analytics teams both read from needs to be replaced, and separately, a public API built on top of the same underlying system has real external, third-party clients on multiple client software development kit (SDK) versions who are much harder to reach and coordinate than an internal team. For the internal consumers, a working session with the two teams to agree the new event's shape, plus a short overlap window where both events fire, is enough. For the external clients the plan has to be slower and more conservative: a new API version ships alongside the old one, both run in production for an extended, published window, the SDK is updated to support both, and only after the published window closes, and only for accounts that were reachable and warned, does the old version actually stop working. Running both consumer groups on the same timeline would either rush the internal migration unnecessarily or leave the riskier external cutover under-supported, so keeping the enforcement dates independent per consumer class is the point, not an inconsistency.

Trade-offs and pitfalls

The main failure is treating every consumer identically: an aggressive timeline that is fine for an internal team you can walk over to is reckless for external clients you have no direct channel to. The second is offering support and incentives indefinitely without ever enforcing the cutoff, which trains consumers that deprecation dates are negotiable and the old system never actually gets decommissioned, quietly becoming permanent maintenance burden. The third is skipping the continuous output comparison and relying on manual testing, which reliably misses the slow-drift case where both systems look fine individually but disagree on edge cases nobody thought to check.

Direct answer

kubectl describe pod gives the immediate cause, OOMKilled, but distinguishing a leak from an undersized limit needs the memory trend over time. A leak climbs roughly monotonically regardless of load, while an undersized limit hits the ceiling fast and stays pinned even under light traffic.

Structured elaboration

• Confirm the reason via kubectl describe pod and check kubectl logs --previous.
• Graph RSS (Resident Set Size, the process's actual physical memory usage) over time; a third case, node-level memory pressure, shows the pod evicted despite flat usage because the node itself is starved.
• If it's node pressure, kubectl describe node shows pressure conditions and multiple unrelated pods affected together.
• Confirm a real leak by checking growth persists during low-traffic windows, ruling out "proportional to load."

Worked example

Suppose kubectl top pod (or your metrics) shows RSS grew from 100 MiB to 500 MiB over the last 10 hours, and the pod's memory limit is 512 MiB:

$\frac{500 - 100}{10} = 40 \text{ MiB/hour}, \quad \frac{512 - 100}{40} \approx 10.3 \text{ hours to OOM}$

A load-independent climb hitting the limit on that schedule regardless of traffic is the leak signature; a pod that jumps to the limit in 5 minutes and stays flat instead points at an undersized limit.

Trade-offs and pitfalls

Raising the limit "fixes" either case, which is exactly why it's a dangerous default: it delays a true leak while wasting cluster capacity, but is correct for an undersized limit. Watch the requests/limits gap for node-level competition disguised as one pod's problem.

What the interviewer probes next

How you'd use a runtime-specific heap profiler to pinpoint a confirmed leak, and how to set requests versus limits to avoid node-level pressure.

Direct answer
Put the ask, the essential context, and the next step in the first two sentences, so a busy reader can act on the email even if they only read the opening before deciding whether to reply now or later.

Structured elaboration

1. State the ask as the first sentence, not buried after several paragraphs of context: "I'd like to request temporary access to X" or "Could you approve Y by Thursday?"
2. Give only the essential context, one or two sentences of why this ask exists, not the full backstory. Include it because it makes the ask easier to say yes to quickly, not because it's interesting.
3. State the next step explicitly: what you need them to do, and by when, so they don't have to infer the deadline or the required action.
4. Use the subject line to state the ask, not just the topic: "Approval needed by Thursday: Q3 budget line" tells the reader more than "Budget question."
5. Keep the whole email short. If the request genuinely needs more context, put the essential ask up top and the detail below it, rather than making the reader wade through detail to find the ask.

Worked example
Subject: "Access request: prod DB read access, needed by Wednesday"

Body: "Could you grant me temporary read access to the orders table in prod? I'm investigating a customer-reported data discrepancy (ticket #4821) and need to check actual row values, which I can't do in staging since the issue only reproduces with real production data. Happy to have this access time-boxed to a few days and revoked afterward if that's easier to approve."

The ask (temporary read access) and the deadline context (needed by Wednesday) are in the subject line alone; the body confirms the specific ask, gives the minimum context needed to approve it, and proactively offers a constraint (time-boxed) that makes approval easier.

Trade-offs and pitfalls

• Leading with a long justification before the ask is the single most common failure; a reader has to hold the whole paragraph in their head waiting to find out what you actually want.
• Too little context can also fail: an ask with zero justification can force the reader to ask a clarifying question back, which is slower than including the one sentence of context that would have let them approve it immediately.
• For sensitive or high-stakes asks (a large budget approval, access to something risky), a slightly longer, more carefully justified email is worth the extra length; the "front-load the ask" principle still applies, it just means front-loading a well-justified ask rather than skipping justification entirely.

Direct answer

If every element is guaranteed non-negative, a sliding window works: grow the window's sum, and shrink from the left whenever the sum overshoots the target, because adding a non-negative element can only increase or hold the sum, so shrinking is guaranteed to monotonically decrease it. Once negative numbers are allowed, that monotonicity breaks, so the general solution instead tracks prefix sums in a hash map: if prefix[i] - prefix[j] == target, the subarray from j+1 to i sums to target, so scanning once while checking whether running_sum - target has been seen before as an earlier prefix sum finds the answer in O(n) time and O(n) space.

Positive-only case: sliding window

def subarray_indices_positive_only(nums, target):
    left = 0
    running = 0
    for right, val in enumerate(nums):
        running += val
        while running > target and left <= right:
            running -= nums[left]
            left += 1
        if running == target:
            return (left, right)
    return None

This relies entirely on non-negativity: shrinking the window (removing nums[left]) can only decrease running, so the while running > target loop is guaranteed to terminate at a sum that is <= target, and if it lands exactly on target, that's a valid answer. With negative numbers present, removing an element from the left could just as easily increase the running sum as decrease it, so there is no longer a reliable direction to shrink in.

General case (including negatives): prefix sum plus hash map

def subarray_indices_prefix_hashmap(nums, target):
    prefix_to_index = {0: -1}   # empty prefix (before index 0) sums to 0
    running = 0
    for i, val in enumerate(nums):
        running += val
        needed = running - target
        if needed in prefix_to_index:
            return (prefix_to_index[needed] + 1, i)
        if running not in prefix_to_index:
            prefix_to_index[running] = i
    return None

The {0: -1} seed entry is what lets a subarray starting at index 0 be found correctly: it represents "the prefix sum before any elements have been added is 0," so if running itself ever equals target, needed = running - target = 0 is already in the map, pointing to index -1, giving a correct start index of 0. The if running not in prefix_to_index guard only stores the first occurrence of each prefix sum, which is what guarantees the returned subarray is as long as possible from that starting point rather than an arbitrarily chosen one (though any correct pair satisfies "sums to target"; the problem only asks for existence, not the shortest or longest one).

Worked example

def brute_force_subarray_indices(nums, target):
    n = len(nums)
    for i in range(n):
        s = 0
        for j in range(i, n):
            s += nums[j]
            if s == target:
                return (i, j)
    return None

r1 = subarray_indices_positive_only([1, 2, 3, 4, 5], 9)
r2 = subarray_indices_prefix_hashmap([1, -1, 5, -2, 3], 3)
print(r1, " (brute-force cross-check:", brute_force_subarray_indices([1, 2, 3, 4, 5], 9), ")")
print(r2, " (brute-force cross-check:", brute_force_subarray_indices([1, -1, 5, -2, 3], 3), ")")

Output (verified by execution, both cross-checked against an O(n^2) brute-force reference that tries every contiguous subarray directly):

(1, 3)  (brute-force cross-check: (1, 3) )
(0, 3)  (brute-force cross-check: (0, 3) )

For [1, 2, 3, 4, 5], target 9: the window grows through [1], [1,2], [1,2,3] to [1,2,3,4] (sum 10), which overshoots; one shrink step drops the leading 1, bringing the sum to exactly 9 with the window now [2,3,4] (indices 1-3), which matches immediately, returning (1, 3). For [1, -1, 5, -2, 3], target 3: the running prefix sums as the scan proceeds are 1, 0, 5, 3 (indices 0-3), with needed = running - target at each step -2, -3, 2, 0. At i=3, needed = 0, which IS in the map, but crucially it maps to index -1 (the seed entry), not index 1 (where prefix sum 0 also occurs, at i=1, from 1 + -1 = 0): the if running not in prefix_to_index guard means that once index -1 claims prefix-sum 0, the later occurrence at index 1 is never allowed to overwrite it. So the match resolves to (-1 + 1, 3) = (0, 3), i.e., the subarray [1, -1, 5, -2], which does sum to 1 + -1 + 5 + -2 = 3.

Trade-offs and pitfalls

• The sliding window is NOT a valid fallback once any negative number can appear, even a single one. A frequent mistake is applying the two-pointer shrink logic to "mostly positive" data and only breaking on adversarial inputs; the moment even one negative value is possible, the general prefix-sum-plus-hashmap approach is required for correctness, not just performance.
• The {0: -1} seed entry is the single most commonly dropped detail. Without it, any subarray that must start at index 0 is silently missed, because there is no recorded "prefix sum before the array starts" to subtract against.
• Storing only the first occurrence of each prefix sum (via the if running not in prefix_to_index guard) is a deliberate choice, not an accident: if the problem instead asked for the shortest subarray summing to target, this is exactly right; if it asked for the count of subarrays summing to target (a related but different problem), the correct approach is to track counts, not indices, and accumulate every match rather than returning early on the first one.
• Return-value ambiguity: this implementation returns any one valid subarray's indices (existence), which matches what the question asks; a caller wanting all valid subarrays, or the shortest, or the count, needs a variant of this same prefix-sum idea, not a fundamentally different algorithm.