Google Site Reliability Engineer (Mid-Level) Interview Preparation Guide

Cloud and network-backed storage for Kubernetes splits into two families: block storage (AWS EBS, GCE PD, Azure Disk), which is fast and durable but normally attachable to only one node at a time, and network filesystems (AWS EFS, Azure Files, self-managed NFS), which are shareable across many nodes at once but pay a latency and throughput cost for that flexibility. Picking between them is really picking whether the workload needs raw single-writer performance or multi-node shared access.

Comparison

How to choose

• Single-writer, latency-sensitive, durable (a relational database's primary, a message queue's log): block storage (EBS, GCE PD, Azure Disk). Access mode ReadWriteOnce, sized and provisioned for the IOPS the workload actually needs.
• Shared, multi-reader-or-writer, latency-tolerant (shared configuration, static assets, a CI build cache used by many concurrent jobs): a managed network filesystem (EFS, Azure Files) if available on your cloud, or self-managed NFS if not, understanding that NFS's durability and availability are now your responsibility to engineer.
• Regional or multi-zone resilience for a block-storage workload: look at the provider's own cross-zone replication option (GCE's regional Persistent Disk is the clearest example) rather than assuming ordinary zonal block storage survives a zone failure; ordinary zonal EBS/PD/Azure Disk does not.

Worked example

A team needs (a) a primary Postgres (Postgres) volume and (b) a shared directory of report templates read by 20 replica Pods across multiple nodes.

• (a) is single-writer and latency-sensitive: provision an EBS/GCE PD/Azure Disk volume through a StorageClass with ReadWriteOnce, sized for the database's IOPS profile.
• (b) needs concurrent multi-node reads: provision an EFS/Azure Files/NFS volume through a StorageClass supporting ReadWriteMany, since a block-storage volume cannot satisfy that access pattern at all, regardless of performance tier.

Trade-offs and pitfalls

• Don't reach for a network filesystem by default "to be safe" for multi-node access; if the workload is genuinely single-writer, block storage's lower latency is the better fit and the shared-filesystem's variability is pure downside.
• Zonal block storage (the common case for EBS/GCE PD/Azure Disk) does not survive the loss of its Availability Zone; if that's a real requirement, either use the provider's cross-zone replicated variant where one exists, or handle replication at the application layer (e.g., a database's own streaming replication to a replica in another zone) rather than assuming the storage layer covers it.
• A "multi-writer" flag on a block-storage product is not the same guarantee as a real shared filesystem: it typically still requires a cluster-aware filesystem and application-level write coordination, so verify exactly what's supported for your disk type before relying on it, rather than assuming ReadWriteMany-equivalent behavior.

Direct answer
Running a blameless postmortem meeting well is mostly about preparation and framing, not clever facilitation tricks in the room. Before the meeting: assemble a factual, timestamped timeline from logs, dashboards, and deploy history, invite the people who were actually involved plus anyone who owns a system in the causal chain, and share a draft timeline in advance so the meeting starts from shared facts instead of competing memories. In the meeting: state the ground rules explicitly (we are here to understand the system, not to find who to blame), walk the timeline together, surface root cause and contributing factors as a group, and end with specific, owned, dated action items written down before people leave.

Structured elaboration

• Before: Pull raw evidence (metrics, logs, traces, deploy and change history) into a draft timeline. Doing this before the meeting, rather than reconstructing it live, keeps the discussion from turning into a memory-recall exercise, which is exactly where blame tends to creep in.
• Framing at the start: Explicitly name the ground rule. A single leading question like 'someone must have known this was a problem, why didn't anyone raise it?' is enough to make people defensive within seconds and shut down honest disclosure for the rest of the meeting, so the facilitator has to actively watch for and redirect that kind of framing, not just hope it doesn't come up.
• During: Walk the timeline chronologically, ask 'what made this possible' rather than 'who did this,' and treat 'human error' as the start of an investigation rather than its conclusion, since a person's reasonable action being unsafe is itself evidence of a system gap.
• Assigning action items: Every action item gets a single named owner and a date before the meeting ends. 'The team will look into X' produces nothing; 'Priya will add schema validation to the deploy pipeline by the 15th' produces something trackable.
• After: Circulate the finished writeup, and treat the meeting output as a living document only until the action items are confirmed done, not indefinitely.

This same structure holds even when the failure being reviewed is not a software outage. A postmortem for a failed partnership launch or a research study that led to a wrong product decision follows the identical discipline: timeline, impact, root cause versus contributing factors, and owned action items, adapted to a business rather than a technical vocabulary.

Worked example
A production incident: a deploy caused a spike in checkout failures. A poorly-run version of this meeting opens with 'who approved this deploy?' and spends 20 minutes on defensive explanations. A well-run version opens with a shared timeline already on screen, the facilitator asks 'what in our deploy process let a change with this blast radius reach 100% of traffic without a canary stage,' the group identifies that canary deployment was skipped because the on-call playbook doesn't clearly require it for config-only changes, and the meeting ends with two action items: update the playbook to require canary for all changes touching this service, owner and date named, and add an automated gate that blocks a full rollout if canary metrics haven't been checked, owner and date named.

Trade-offs and pitfalls
The most common failure mode is drifting from 'what happened' into 'who is responsible' the moment the timeline reaches a specific person's action. The facilitator's job is to notice that drift in real time and redirect toward the system gap that let the action cause harm. A second failure is ending the meeting with vague, unowned action items that read like good intentions rather than commitments; if nobody can point to a name and a date, the item will not get done.

p50 (median) shows the latency experienced by the “typical” request, but it ignores the tail — the small fraction of requests that are much slower and often drive user dissatisfaction and SLO breaches. For user-facing services the tail matters because a few slow requests can ruin perceived performance (page jank, timeouts, retries).

Example:

• p50 = 100 ms (half of requests <=100 ms)
• p90 = 300 ms
• p99 = 2,000 ms
  These numbers tell two stories: p50 suggests excellent performance, but p99 reveals that 1% of users wait 2 seconds — long enough to trigger timeouts or abandonment.

Practical consequence of relying only on p50:

• You may miss degrading tail behavior and fail to alert until customer complaints or SLO breaches occur. That leads to surprise incidents, missed SLAs, and higher user churn.

Best practice: track multiple percentiles (p50, p90, p95, p99), distributions/histograms, and define SLIs/SLOs focused on relevant tails.

Direct answer

The strongest version of this story shows a blocker noticed before it became someone else's emergency, an action matched to how much authority you actually had over what you changed (fixing it directly if it was fully yours, coordinating if it touched shared infrastructure, escalating only if it was genuinely outside your reach), and a real, specific before-and-after change in the delivery timeline, not a general sense that things felt smoother.

Structured elaboration

1. Spotting it: point to a concrete detection signal, not a vague feeling, for example a recurring delay pattern that showed up in the same way across the last several delivery cycles, or a piece of infrastructure that everyone quietly routes around because nobody actually owns fixing it.
2. Matching the action to your authority: a fix fully within your own control (your own code, your own team's process) can be built and shipped directly. Something that touches shared infrastructure or another team's system calls for coordinating with the right people first, rather than unilaterally changing something you do not own.
3. When to loop others in: loop in the owner of anything outside your own immediate scope before changing it, not after, and loop in your manager or affected stakeholders whenever the fix will visibly shift timeline expectations, even a positive shift, so nobody is caught by surprise either way.
4. Measuring the result: close with an honest, specific before-and-after comparison of the exact thing that changed, a step in a process, a recurring wait time, a manual task that used to eat calendar time, described plainly rather than with inflated precision.

Worked example

Across the last four release cycles, a manual, ticket-based approval step to provision a test environment consistently cost the team roughly half a day of waiting each time, even though the criteria for approval had become entirely mechanical, the same three checks every time, with no real judgment call left in it. The fix: a small self-service script that ran those same three checks automatically and auto-approved when they passed, falling back to the manual ticket only when a check actually failed. Because the change touched a provisioning system owned by another team, its lead was looped in before anything shipped, rather than deploying a workaround directly into a system this person did not own, and sign-off came quickly since the change only automated a decision that was already mechanical, not a judgment call being taken away from anyone. Result: the environment-provisioning wait dropped from roughly half a day to about 15 minutes for the common case, recovering close to half a day of calendar time per release cycle, and across the next four releases where the team used it, this removed what had been the single largest scheduled delay in the release checklist.

Trade-offs and pitfalls

Unilaterally changing shared infrastructure without looping in its owner, even with good intentions, erodes trust and risks breaking something not fully understood. Choosing a blocker that is satisfying to fix but not actually on the delivery-critical path does not move the timeline at all, no matter how good the fix feels. And closing with a vague claim that things felt smoother afterward, instead of naming the one specific thing that got measurably faster, is the difference between a story that demonstrates ownership and one that only asserts it.

Direct answer
A boundary check catches a specific class of bug (accessing an index, offset, or value outside the range the code actually handles correctly) at the moment it happens, instead of letting it silently produce wrong output or crash somewhere unrelated later; three concrete examples: array/list indexing, pagination offsets, and numeric limits.

Structured elaboration and worked examples

• Array indexing: the bug is an off-by-one or attacker-controlled index reading past the end of a buffer or list. The defensive check: validate 0 <= index < len(array) before accessing, raising a clear IndexError/custom exception instead of either crashing with a cryptic native error or, in an unsafe language, reading adjacent memory. A unit test: assert_raises(IndexError, get_item, [1,2,3], 5).
• Pagination offsets: the bug is a negative or absurdly large offset/limit from a client, which can either error confusingly deep in a SQL driver or, worse, silently return zero rows and look like 'no data' rather than 'bad request'. The defensive check: clamp or reject offset < 0 and cap limit to a sane maximum (say 1000) before it reaches the query layer. A unit test: assert paginate(items, offset=-5, limit=10) raises ValueError.
• Numeric limits: the bug is an integer overflow or an out-of-domain value (a negative quantity in an order, a percentage over 100) silently producing a nonsensical result instead of an error. The defensive check: validate the value's range explicitly before using it in a calculation. A unit test: assert_raises(ValueError, apply_discount, price=100, percent=150).

Trade-offs and pitfalls
Each of these checks is cheap individually, but the value comes from applying them CONSISTENTLY at every place the boundary is actually crossed (every array access from external input, not just the ones you happen to remember); a single unguarded pagination endpoint added six months later by someone who didn't see this pattern reintroduces the exact bug class. Treat these as patterns to lint for or wrap in a shared utility function, not as one-off checks to remember individually.

Direct answer

I see ability as something built through effort and specific feedback, not a trait I either have or don't. The practical difference between that and a fixed outlook shows up in the first few seconds after something goes wrong, because that's before there's time to perform the socially correct answer.

Structured elaboration

The contrast is clearest in three recurring situations:

• An experiment or change that doesn't work. A fixed reaction treats the negative result as a verdict on competence and looks for reasons the setup was unfair. A growth reaction treats it as one data point and asks what it rules out.
• A critical review. A fixed reaction defends the original decision, sometimes relitigating context nobody asked for. A growth reaction isolates the single most specific, actionable point raised and changes that one thing next time, even when the feedback stings.
• An unfamiliar tool or an unclear brief. A fixed mindset avoids volunteering, because failing at something new feels riskier to the self-image than staying in safe territory. A growth mindset treats "I don't know this yet" as a normal, temporary state.

What the fixed pattern costs a team: velocity drops because people route around unfamiliar work instead of through it, quality suffers because problems get relitigated instead of fixed, people stop raising issues early because raising one risks being blamed for it, and morale erodes because the same few people end up carrying anything ambiguous.

Worked example

In a design review, a reviewer was blunt about a flaw in an approach I'd already committed time to. My first instinct was defensive: I started explaining the constraints that led me there. I caught myself mid-sentence, asked one specific question instead ("is the concern the failure mode when input is empty, or the overall structure?"), and it turned out to be the narrower issue. I fixed that one thing and confirmed with the reviewer it addressed the concern, rather than reworking everything out of general anxiety.

Being honest about the flip side matters more than the tidy version of this story: I am still more fixed-mindset than I'd like about unscripted public communication, like presenting unfinished work live to a large group. I know it because I over-prepare for it and get visibly rattled if the plan changes mid-presentation, which is exactly the "competence is on trial" reaction I described above, just in a different context.

Trade-offs and pitfalls

A common wrong turn here is giving the scripted, socially correct version of this answer with no concrete instance behind it. What makes it credible is naming an actual moment the reaction was tested, and being willing to name a domain where the fixed pattern still shows up, since nobody is growth-minded everywhere at once.

Direct answer
When a client keeps retransmitting its SYN and never sends the final ACK (while the server's SYN-ACK is only retransmitted once before the connection times out), the most likely causes are that the client's connect timeout hasn't fired yet, that something between the two hosts is dropping the ACK specifically (an asymmetric path or a stateful device confused about direction), or that the client-side application itself never actually attempted the ACK due to a bug. A different failure shape, the server sends SYN-ACK and the client immediately sends RST, points to a different family of causes entirely: the client rejecting the connection outright.

Structured elaboration
For the "client retransmits SYN, no final ACK" pattern, work through causes in order of likelihood:

1. Asymmetric routing dropping only the return-to-forward-direction ACK path. If the SYN-ACK reaches the client (we know it does, since the client keeps retransmitting new SYNs rather than giving up, meaning it IS getting a response of some kind) but the client's ACK can't get back to the server along some other path, a stateful firewall or NAT device on that asymmetric path may be dropping the ACK because it doesn't recognize the connection's state in that direction.
2. A middlebox is rewriting or dropping specific TCP options in the SYN-ACK that the client's stack doesn't handle gracefully, causing it to silently discard the SYN-ACK and retry instead of ACKing it.
3. Client-side firewall or security policy is specifically blocking outbound ACKs to that destination while permitting the outbound SYNs, an unusual but real misconfiguration.
4. MTU (Maximum Transmission Unit)-related silent packet loss on the SYN-ACK's return path if it happens to be an unusually large segment (rare for a SYN-ACK specifically, since it typically carries little payload, but worth ruling out if other symptoms point that way).

For the different shape (SYN-ACK followed by an IMMEDIATE client RST): this usually means the client-side application decided, upon establishing the connection, that it doesn't actually want it, for example an application-level timeout that already expired while the handshake was in flight, a client-side connection pool that raced two connection attempts and is aborting the loser, or a security tool on the client actively resetting connections that don't match an expected certificate or policy.

Worked example
To distinguish these hypotheses in practice, compare timestamps and evidence on BOTH ends: if the server's capture shows the SYN-ACK leaving on time but the client's capture never shows it arriving, the problem is in the path (asymmetric routing, a device eating it). If the client's capture shows the SYN-ACK arriving cleanly but no ACK is ever generated by the client's own stack, the bug is on the client host itself (application logic, local firewall) rather than the network path.

Trade-offs & pitfalls
A common mistake is assuming a stuck handshake is always a network problem; a client-side timeout race (the application gives up right as the handshake completes) produces an outwardly identical-looking symptom to a network drop and is only distinguishable by comparing what each side's own capture actually shows, not by reasoning about the network path alone.

Direct answer

Don't force one team's cadence onto the other. Design a policy that separates what must be shared (the guardrails that protect everyone) from what can stay team-specific (how fast a given team is allowed to move within those guardrails), then negotiate the guardrails, not the cadence itself. That reframing turns "fast team vs. cautious team" into a joint design problem both sides can own.

Structured elaboration

1. Split invariant from flexible. List what truly must be uniform across teams (a working rollback path, a minimum test bar, an incident-response process) versus what can legitimately vary (deploy frequency, staging gate count, review depth). Most conflicts collapse once you see that only a small slice actually needs to be shared.
2. Reframe cadence as risk exposure. Ask each side what they're protecting (customer trust, an SLA, a compliance obligation) versus what they want (velocity). Convert both into measurable guardrails: blast radius limits (how much of the system or traffic a change could affect if it goes wrong), an automated rollback trigger (a rule that reverts the change automatically once a threshold is crossed, without waiting for a human to notice), a minimum observation window before a change is considered "safe."
3. Build a tiered policy, not a single rule. Changes that touch a small blast radius and have a fast, automatic rollback can move on the fast-moving team's cadence. Changes that touch shared, hard-to-reverse surfaces get the slower team's gates, regardless of which team wrote the change. The tiering criteria, not the team identity, decides the process.
4. Add an explicit exception path. Either side can request a deviation (ship something in a higher tier faster, or hold something in a lower tier longer) with a documented reason and a named approver, so departures from the policy are visible instead of quiet workarounds.
5. Time-box a trial and revisit with real data. Don't debate the policy hypothetically forever. Run it for a fixed period, then bring incident counts and delivery-time data back to the table instead of re-litigating the original positions.

The same negotiation pattern applies beyond deploy-frequency disputes: whenever two functions have structurally different operating rhythms, the fix is a shared cadence at the boundary, not a winner. As a concrete cross-team cadence clash from the machine-learning world: a feature store (the shared system that stores and serves the data used to train and run machine-learning models) team can only refresh labels every two weeks, while the product team needs weekly model retraining (rerunning the training process on newer data so the model's predictions stay current). That isn't a risk-tolerance disagreement at all. It's a hard technical constraint on one side meeting a business cadence need on the other, and it gets negotiated the same way: agree what must move on the constrained cadence (the underlying label refresh) versus what can be decoupled (the product team retrains weekly on the two most recent completed label batches, accepting known staleness, rather than blocking on a refresh that can't happen faster).

Worked example

Team A ships to production many times a day behind feature flags. Team B owns a regulated, customer-facing billing surface and wants a weekly release train. Instead of debating "how often should we deploy," the negotiated policy ties process to blast radius: any change gated behind a flag to less than 1% of traffic can auto-promote if the error rate stays under 2x the pre-change baseline for a 30-minute observation window (a policy parameter both sides agreed to, not a claimed result). Changes that touch the billing ledger directly, regardless of author, require the slower manual review and a scheduled release window. Team A keeps most of its velocity because most of its changes are low blast radius; Team B keeps its protection because the surface it cares about is gated the same way no matter who wrote the change.

For the cadence-mismatch variant: the feature store team commits to publishing a refreshed label snapshot every two weeks, on a fixed schedule the product team can plan around. The product team's weekly retraining job consumes the most recent snapshot plus a lightweight, clearly-labeled interim signal for the intervening week, rather than either side pretending the refresh can happen weekly or the product team silently retraining on stale labels without acknowledging it.

Trade-offs & pitfalls

• Pitfall: writing a single global policy. It's either too loose for the regulated team or too strict for the fast-moving one, and both sides end up circumventing it.
• Pitfall: treating this as a one-time meeting. Without a scheduled revisit, the policy calcifies around the political balance of the original conversation instead of actual incident/velocity data.
• Pitfall: hiding exceptions. If deviations aren't logged and visible, the "shared" part of the policy erodes silently and trust breaks down the next time there's an incident.
• Senior differentiator: designing the guardrail so it's parameterized by risk (or, in the cadence case, by the actual constraint) rather than by team identity. That's what lets both sides keep their operating model instead of one side losing the negotiation.

Direct answer

Detecting a directed cycle with depth-first search (DFS) and a recursion stack means maintaining two boolean arrays: visited (has this node been explored at all, ever) and inStack (is this node on the CURRENT recursion path right now). An edge into a node that is visited but no longer inStack is harmless, that node was already fully explored via some other path; an edge into a node that IS inStack is a back edge into a live ancestor, a genuine cycle. This runs in $O(V+E)$.

Structured elaboration

visited[u] and inStack[u] are both set the moment DFS enters u. inStack[u] is reset to false the moment DFS finishes exploring everything reachable from u (on backtrack), while visited[u] stays true forever once set. This is what lets the algorithm tell "already explored, but not currently an ancestor" (visited, not inStack, safe) apart from "currently an ancestor on my path" (both visited and inStack, a cycle if reached again).

Worked example

import java.util.*;

public class DirectedCycle {

    public boolean hasCycle(int n, List<List<Integer>> graph) {
        boolean[] visited = new boolean[n];
        boolean[] inStack = new boolean[n];
        for (int v = 0; v < n; v++) {
            if (!visited[v]) {
                if (dfs(v, graph, visited, inStack)) return true;
            }
        }
        return false;
    }

    private boolean dfs(int u, List<List<Integer>> g, boolean[] visited, boolean[] inStack) {
        visited[u] = true;
        inStack[u] = true;
        for (int v : g.get(u)) {
            if (!visited[v]) {
                if (dfs(v, g, visited, inStack)) return true;
            } else if (inStack[v]) {
                return true; // back edge into a live ancestor
            }
        }
        inStack[u] = false; // backtrack: u is no longer on the active path
        return false;
    }

    // Also returns one concrete cycle as a list of node ids, or an empty list if none exists.
    public List<Integer> findCycle(int n, List<List<Integer>> graph) {
        boolean[] visited = new boolean[n];
        boolean[] inStack = new boolean[n];
        int[] parent = new int[n];
        Arrays.fill(parent, -1);
        for (int v = 0; v < n; v++) {
            if (!visited[v]) {
                int[] cycleStart = new int[]{-1};
                if (dfsFind(v, graph, visited, inStack, parent, cycleStart)) {
                    List<Integer> cycle = new ArrayList<>();
                    int cur = cycleStart[0];
                    int start = cur;
                    do {
                        cycle.add(cur);
                        cur = parent[cur];
                    } while (cur != start && cur != -1);
                    cycle.add(start);
                    Collections.reverse(cycle);
                    return cycle;
                }
            }
        }
        return Collections.emptyList();
    }

    private boolean dfsFind(int u, List<List<Integer>> g, boolean[] visited, boolean[] inStack, int[] parent, int[] cycleStart) {
        visited[u] = true;
        inStack[u] = true;
        for (int v : g.get(u)) {
            if (!visited[v]) {
                parent[v] = u;
                if (dfsFind(v, g, visited, inStack, parent, cycleStart)) return true;
            } else if (inStack[v]) {
                parent[v] = u;
                cycleStart[0] = v;
                return true;
            }
        }
        inStack[u] = false;
        return false;
    }

    public static void main(String[] args) {
        DirectedCycle dc = new DirectedCycle();

        List<List<Integer>> acyclic = new ArrayList<>();
        acyclic.add(Arrays.asList(1, 2));
        acyclic.add(Arrays.asList(2));
        acyclic.add(Collections.emptyList());
        System.out.println("Acyclic graph hasCycle: " + dc.hasCycle(3, acyclic));

        List<List<Integer>> cyclic = new ArrayList<>();
        cyclic.add(Arrays.asList(1));
        cyclic.add(Arrays.asList(2));
        cyclic.add(Arrays.asList(0));
        System.out.println("Cyclic graph hasCycle: " + dc.hasCycle(3, cyclic));
        System.out.println("Reconstructed cycle: " + dc.findCycle(3, cyclic));

        List<List<Integer>> disconnected = new ArrayList<>();
        disconnected.add(Arrays.asList(1));
        disconnected.add(Collections.emptyList());
        disconnected.add(Arrays.asList(3));
        disconnected.add(Arrays.asList(2));
        System.out.println("Disconnected graph (cycle in 2nd component) hasCycle: " + dc.hasCycle(4, disconnected));

        List<List<Integer>> selfLoop = new ArrayList<>();
        selfLoop.add(Arrays.asList(0));
        System.out.println("Self-loop hasCycle: " + dc.hasCycle(1, selfLoop));
    }
}

Output (actually compiled and run with javac/java):

Acyclic graph hasCycle: false
Cyclic graph hasCycle: true
Reconstructed cycle: [0, 1, 2, 0]
Disconnected graph (cycle in 2nd component) hasCycle: true
Self-loop hasCycle: true

The disconnected test graph (0 -> 1, no cycle in that component; 2 -> 3 -> 2, a genuine cycle in the second component) confirms the outer loop's for (int v = 0; v < n; v++) if (!visited[v]) correctly restarts DFS from every unvisited node, so a cycle anywhere in the graph is found even if it is not reachable from node 0.

A few points worth naming explicitly about how the two functions above work:

• inStack[u] = true on entry, inStack[u] = false on backtrack: this reset is what makes the distinction between "ancestor, still active" and "already finished elsewhere" possible; forgetting the reset would make every previously-visited node look like a live ancestor forever, turning any two paths into the same node into a false cycle report.
• The single-array visited check alone (without inStack) is exactly what a plain reachability check needs; inStack is the ONLY addition cycle detection requires on top of ordinary DFS.
• findCycle reuses the identical traversal shape, adding only a parent array (set on first discovery) and a cycleStart marker (set the moment a back edge is found), then reconstructs the path by walking parent from the back edge's source back up to the ancestor it points into.

Complexity

Time $O(V+E)$: each vertex is visited once (the visited guard), and each edge is examined exactly once, when its source vertex is processed. Space $O(V)$ for the recursion stack in the worst case (a graph that is one long chain), plus $O(V)$ for the visited, inStack, and (for findCycle) parent arrays.

Edge cases

• Self-loop (a node with an edge to itself): caught immediately, since the node is still inStack (it just entered) when its own edge is examined.
• Disconnected graph with a cycle only in one component: handled correctly by the outer loop restarting DFS from every unvisited node, as demonstrated above.
• Empty graph (n = 0): the outer loop never executes, hasCycle returns false immediately.
• A DAG with a shared descendant (multiple parents pointing to the same child, no actual cycle): correctly reported as no cycle, since by the time the second parent reaches the shared child, that child is visited but no longer inStack (already backtracked out of by the first parent's exploration).

Trade-offs and pitfalls

• Common mistake: forgetting to reset inStack[u] = false on backtrack. Without it, every node ever visited stays permanently marked as "on the stack," and the very next edge into any previously-visited node, cycle or not, would be misreported as a back edge.
• Common mistake: using only visited without inStack and expecting it to work for directed cycle detection; a plain visited check cannot distinguish a live ancestor from an already-finished, unrelated branch, which is exactly the diamond-shaped-DAG false positive this pattern is known to produce.
• Deep, chain-like graphs risk a stack overflow in the recursive Java implementation shown, the same risk an iterative, explicit-stack version avoids; worth naming as a follow-up concern for production code handling untrusted or very deep graphs, distinct from the correctness question this answer is scoped to.
• The findCycle reconstruction variant, returning the actual cycle path rather than a bare boolean, is a natural and common follow-up once the boolean version is understood; it changes nothing about the core traversal logic, only adds the parent/cycleStart bookkeeping needed to recover the path after detection.

Situation: PID 4321 is at 100% CPU and top says it's in userspace. I want to know whether it's spinning in user code or repeatedly making syscalls (which points to different root causes). I would use strace carefully to avoid making the problem worse.

Step-by-step with exact commands

1. Quick thread check (do this first):

• sudo top -H -p 4321
  • shows per-thread CPU to see if one thread is hot.

2. Attach strace to the running process and write output to a file, following threads:

• sudo strace -f -p 4321 -o /tmp/strace_4321.log
  • -p 4321 : attach to process
  • -f : follow forks/threads
  • -o file : write trace to file (avoid filling console or TTY)

Let it run for a short controlled interval (e.g., 5–10s), then stop strace (CTRL-C on the strace process) so you capture a sample without huge overhead.

3. Capture a syscall summary (low-noise):

• sudo strace -f -p 4321 -c -o /tmp/strace_4321_summary.log
  • -c : print counts/time per syscall (good to see which syscalls dominate)
  • Use this for quick aggregation instead of full trace when in production.

4. Reduce overhead / filter syscalls:

• sudo strace -f -p 4321 -o /tmp/strace_filtered.log -e trace=network,desc,read,write -s 64
  • -e trace=... : only trace selected categories or syscalls
  • -s 64 : limit string sizes to avoid huge logs
  • Run only briefly; prefer -c + -e for production sampling.

5. If you need a timed capture:

• sudo timeout 5s strace -f -p 4321 -o /tmp/strace_4321.log
  • automatically stops after 5 seconds.

How to interpret common syscalls in the trace

• read(...) / write(...):

  • Frequent short reads/writes (many small I/O syscalls) can mean busy polling I/O, line-buffered logging, or tight I/O loop.
  • Blocking read that returns data rarely suggests normal I/O; a read that returns 0 or -EAGAIN may indicate EOF or nonblocking socket behavior.
  • If CPU is high yet you see lots of read/write syscalls, the process could be processing each syscall heavily in userspace.

• futex(...):

  • futex is used for user-space locking; many FUTEX_WAIT/FUTEX_WAKE calls suggest threads are contending on a mutex or condition variable.
  • High futex wake/wait rates with spinning (FUTEX_WAIT repeatedly) can indicate lock contention or a poor spin/timeout policy. If futex calls are rare/absent but CPU is high, the process is likely pure user-space busy loop.

• poll()/ppoll()/epoll_wait():

  • poll/epoll_wait that blocks (long timeout) indicates the thread is waiting on I/O — CPU should be low.
  • Very frequent poll with zero timeout or with immediate returns implies busy polling (spin-loops), which explains CPU usage.
  • poll returning events repeatedly with subsequent heavy processing suggests the event loop is CPU-bound.

Diagnosis pattern

• If strace shows almost no syscalls while CPU is 100%: confirm it's busy looping in user code (use perf or gdb to get stack traces).
• If strace shows lots of futex activity: inspect threading model, look for hotspot lock, and consider lock contention fixes.
• If strace shows frequent poll/read/write: investigate event loop or blocking I/O handling and batching.
• Use -c to quickly see which syscalls dominate (counts & total time).

Minimizing production impact

• Prefer short-duration traces and -c summary.
• Filter syscalls with -e to only what you need.
• Limit string capture with -s.
• Write to disk (-o), not console.
• Consider lower-overhead tools (perf, bpftrace, eBPF) for longer sampling.
• Always test commands on staging if possible.

If strace is inconclusive, get a user-space stack sample quickly:

• sudo gdb -p 4321 --batch -ex "thread apply all bt" > /tmp/backtraces.log
  or use perf top/perf record for sampling.

This approach gives a focused, low-overhead way to see whether the process is syscall-bound (and which syscalls) or spinning in userspace so you can pick the right remediation.