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.

Direct answer

In forty-eight hours I am not trying to understand the technology, I am trying to deliver one narrow, correctly-working slice of it and be honest about everything I did not verify. I spend the first couple of hours scoping exactly what "real" has to mean for the deliverable, deliberately decide what to fake, stub, or hard-code outside that slice, and I protect the work by verifying the riskiest part by hand rather than trusting untested intuition, then naming the residual risk explicitly to whoever receives the work.

Structured elaboration

• Scope ruthlessly from the actual deliverable backward: what is the smallest real thing that satisfies the ask, and what can be stubbed, mocked, hard-coded, or simply omitted for now.
• Name out loud what is being skipped and why: edge cases, error handling for paths not exercised, configuration options, anything the tool offers that this specific window does not need.
• For the part that has to be real, verify by hand what you cannot yet trust your own understanding to catch: manually walk a request through, check a response against documentation line by line, rather than relying on "it looked right" for the piece that matters most.
• Where existing knowledge partly maps from something familiar, be explicit with yourself about which parts of that intuition are actually being verified and which are just being trusted, since a partial map is exactly where false confidence creeps in.
• Flag residual risk explicitly to whoever receives the work: what was not verified, what could break outside the narrow case tested, and what should be checked next if this needs to become durable.

Worked example

With about forty-eight hours' notice, I was asked to integrate a third-party payment provider's webhook into a live service for a stakeholder demo the next day, having never touched that provider's interface before. I scoped the real slice tightly: handle exactly one webhook event type correctly, with real signature verification, since faking that would be dangerous even in a demo, and hard-coded a canned response for every other event type in the provider's catalog rather than trying to handle all of them. I verified the signature-verification code by hand against the provider's documented example payload and hash, byte by byte, rather than trusting that it compiled and ran without error, since that was exactly the part I could not yet trust my own instincts on. I left retry and duplicate-delivery handling explicitly out of scope, wrote that down in the change description, and told the person receiving the work directly that a duplicate webhook delivery would currently be processed twice, so it was not safe to treat as production-ready before that gap closed.

Trade-offs and pitfalls

• The biggest failure mode under this kind of compression is quietly treating "it ran once without an error" as proof of correctness; hand-verifying the riskiest slice is exactly what prevents that.
• Skipping too aggressively can produce a demo that looks complete and creates false confidence that the hard part is done, when the hard part was actually the part left out; naming what was skipped, out loud, is what prevents that.
• Leaning on knowledge that only partly maps from a familiar tool is efficient but dangerous if the transferable parts are not separated from the parts that merely look similar.

Situation: At a previous company we experienced a global, high-severity outage affecting our main API and web users across regions during peak hours.

Task: As the on-call SRE lead, I had to set up and run a clear incident communication plan so technical teams, product, support, execs, and external customers stayed informed and aligned.

Action:

• Stakeholder mapping & responsibilities
  • Engineering (on-call, incident commander, SWAT): triage, mitigation, RCA artifacts.
  • Product: prioritize user-facing work, customer impact assessment.
  • Support/CS: customer-facing answers, FAQs, backlog routing.
  • Executives: business impact, decision authority, stakeholder escalation.
  • Legal/PR: review external messaging if data exposure or major market impact.
• Cadence of updates
  • Initial: immediate acknowledgement within 5–10 min.
  • Rapid cadence: every 15 min for first hour (or until a working mitigation).
  • Stabilize: every 30–60 min while degraded.
  • Resolution: final update within 30 min of full recovery, followed by postmortem timeline within 72 hours.
• Channels & formats
  • Bridge (video/voice + chat): primary coordination for responders.
  • Status page: public incident banner + timeline updates.
  • Social/Email: customer-facing updates (sent when confirmed facts change).
  • Internal Slack/channel: running log, timelines, decisions.
• Templated messages (short, consistent)
  • Initial: “We are aware of a service outage impacting [scope]. Investigating. ETA: TBC. Next update: +15m.”
  • Progress: “Root cause: [high-level]. Mitigation in progress: [actions]. Impact: [scope]. Next update: +30m.”
  • Resolution: “Service restored at [time]. Cause: [brief]. Next: postmortem by [date].”
• Escalation criteria
  • Execs: sustained outage >30–60 min affecting >X% revenue/traffic or key customers, or when action requires business trade-offs.
  • Legal/PR: confirmed or suspected data breach, regulated-data exposure, or negative press/social amplification above threshold.
  • Immediate paging if incident affects payments, compliance, or critical SLAs.

Result: This structured plan kept teams aligned, reduced redundant work, enabled clear customer communication, and allowed leadership to make timely trade-offs. Postmortem showed faster time-to-mitigation and positive stakeholder feedback. Learned to codify thresholds and automate status-page pushes to remove human delay.

Requirements & constraints:

• Enable gzip for API responses safely for large user base.
• Measure latency, CPU, memory, and network egress savings.
• Support gradual rollout, A/B (or ABBA) testing, regression detection, and fast rollback.
• Keep SLOs (p95 latency, error rate, CPU utilization) intact.

High-level strategy:

1. Feature flag + rollout cohorts: implement gzip behind a feature flag at the edge/load-balancer or service layer. Use percentage-based cohorts (0%, 1%, 5%, 25%, 50%, 100%) and canary by region/tenant.
2. ABBA testing: maintain two groups A (no gzip) and B (gzip) balanced by traffic, client type, and region to avoid bias. Rotate cohorts if needed to detect time-of-day effects.

Implementation details:

• Server-side: enable gzip via middleware that checks Accept-Encoding and feature flag. Respect small payload threshold (e.g., >1KB) and content types (JSON, text).
• Edge compression alternative: do at CDN/edge if supported (less backend CPU).
• Sampling: log both compressed and uncompressed sizes, serve-time, CPU time per request (e.g., using process CPU counters or histogram of request CPU).

Metrics to collect:

• Network: bytes_out per request and total egress.
• Performance: request latency (p50/p95/p99), tail latency, time-to-first-byte.
• Resource: per-host CPU utilization, request CPU time, memory.
• Errors: 4xx/5xx rates, client decompression errors (Content-Encoding mismatches).
• Business: user-visible errors, support tickets.

Experimentation & analysis:

• Run A/B for at least one traffic cycle per cohort. Use statistical tests (t-test or bootstrap) on:
  • Egress reduction (% bytes saved) and cost projection.
  • CPU overhead per request and aggregate CPU delta.
  • Latency change (p95/p99).
• Define success thresholds: e.g., >20% egress reduction with <5% relative CPU increase and <2% relative p95 latency increase and no error-rate increase beyond alert thresholds.

Regression detection & alerts:

• Automated anomaly detection comparing B to A (rolling windows). Alert on:
  • p95 latency increase > threshold or absolute exceed SLO.
  • Error rate increase > X (e.g., 0.5% absolute).
  • Per-host CPU > 80% or > historical + 20%.
  • Unexpected high compression ratio variance (could indicate corrupted content).
• Dashboards: compare cohorts side-by-side; surface cost savings projection.

Rollback criteria & runbook:

• Immediate rollback if:
  • Error rate spike > allowed (e.g., doubled or > SLO breach).
  • p95 latency > SLO breach for 5+ minutes.
  • Per-host CPU saturates causing degraded availability.
• Gradual rollback: reduce cohort percentage stepwise if marginal metrics borderline.
• Automate rollback via feature-flag toggles; include automated circuit-breaker that disables gzip when thresholds hit.

Operational considerations:

• Warm-up: run small cohort longer to observe rare errors and client compatibility.
• Client compatibility: log Accept-Encoding and handle proxies that mis-handle gzip.
• Cost-benefit: compute egress $ savings vs CPU cost (on-prem CPU or cloud VM cost); only roll to 100% if net positive and within capacity.
• Testing: unit/integration tests for headers; chaos tests for edge cases.

This approach ensures measurable benefits, controlled risk, automated detection, and fast rollback capabilities aligned with SRE principles.

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.