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

Measure: expose a gauge of "process_open_fds" (current FD count) and optionally "process_max_fds" (soft limit) and "process_fd_pct = process_open_fds / process_max_fds".

Scrape frequency: 15s for services with fast growth risk, 30–60s otherwise. Shorter scrapes detect slope earlier but increase load.

Aggregation & labels: keep instance-level label (instance, job, zone) but avoid high-cardinality labels (user, pod-id) in long-term metrics. Store raw per-instance series short-term (retention 7d) and roll up to lower-cardinality series for longer retention: e.g., fd_count_by_service = max(process_open_fds) by (service, environment).

Alert rule (balance sensitivity/noise):

• Use a rate-of-change check plus threshold:
  • short-term slope: increase over 1h: increase >= 15% of baseline AND absolute growth >= 50 FDs
  • sustained: fd_pct >= 80% for 10m OR linear regression slope over 6h > 10 FDs/hour
    Prometheus-ish rule (concept):
• alert if (increase_1h >= 0.15 * avg_7d_baseline AND increase_1h >= 50) OR (avg_over_10m(fd_pct) > 0.80)

Reducing alerts across many instances: deduplicate using grouping by service; fire one alert per service with "top N affected instances" in annotations. Implement detection: compute per-instance increases with PromQL, then aggregate using max() or count_over_time to produce a single low-cardinality alerting series by (service, environment). Use Silence/auto-close if growth stops. Add runbook: investigate leaking components, restart policy, heap of affected instances.

Race conditions and concurrency bugs leave a distinct fingerprint that a deterministic logic bug doesn't: they are inconsistent under identical-looking conditions.

Signs and the diagnostic for each

• Fails intermittently on the same input/code path. A deterministic bug fails every time given the same input; a race fails only sometimes. Diagnostic: rerun the exact same case N times and check the failure rate is neither 0% nor 100%.
• Fails more often under load or parallelism, passes when run alone. Diagnostic: run the same test serially vs. in parallel and compare failure rates.
• Disappears or changes when you add logging or attach a debugger (a heisenbug symptom). Diagnostic: this itself is evidence of timing sensitivity, since instrumentation changes the exact interleaving.
• Values that look "impossible" given the code's logic (a counter lower than the number of increments performed, a list missing an entry that was definitely inserted). Diagnostic: instrument the shared state with fine-grained before/after logging and check whether two threads' logged operations interleave in an order the code never anticipated.
• Different results across repeated runs of the identical binary/input. Diagnostic: run twice, diff the outputs; a deterministic bug produces identical (wrong) output both times.

Trade-offs and pitfalls

The trap is treating a low reproduction rate as "rare enough to ignore"; a race with a 1-in-10,000 trigger rate in a test can be a 1-in-a-minute event at production scale, so the diagnostic above should be run at a scale proportional to production traffic, not just a handful of manual retries.

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
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.

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
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

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.

With 60% of the monthly error budget already spent by day ten and a feature rollout scheduled for day eleven, the decision should not be an automatic freeze or an automatic green light; it should weigh how much budget is genuinely left, whether the rollout itself is a meaningful new source of risk, and who needs to be in the room before deciding. A service-level objective (SLO) of 99.95% over 30 days leaves an error budget of 0.05% of requests for the month; having burned 60% of it in the first third of the month is a real signal, but the right response depends on what caused the burn and what the rollout would add on top of it.

Working through the decision

1. Understand the cause of the burn before deciding anything else. If the 60% came from a single, already-resolved incident (a bad deploy that's been rolled back), the ongoing risk profile for the rest of the month is different than if it's an unresolved, intermittent issue that's still actively burning budget; the second case argues much more strongly against adding a new source of risk on top of it.
2. Estimate the rollout's own risk contribution, not just its existence. A well-tested, low-blast-radius change behind a feature flag is a different risk than a large, untested change touching the same code path as the current instability.
3. Decide among proceed, delay, or modify, with the default leaning toward caution given 60% is already spent with two-thirds of the month remaining: proceed only with extra safeguards, delay until the underlying issue is understood or resolved, or modify the rollout to reduce its own risk contribution (a smaller canary percentage, an easier automated rollback path, tighter feature-flag gating so it can be turned off instantly without a redeploy).
4. Involve the right stakeholders before deciding, not after: the engineering lead who understands the ongoing burn, the product owner who owns the rollout's business urgency, and, if the budget is this depleted, whoever owns the team's error-budget policy (often an SRE lead), since a policy freeze may already be triggered independent of this specific rollout.

Worked example of "proceed, with controls"

The team determines the 60% burn came from a resolved, one-time incident rather than an ongoing issue, and the planned rollout is a well-tested change behind a feature flag. Decision: proceed, but with a small initial canary (1% of traffic instead of the originally planned 10%), automated rollback wired to the same error-rate alert that would page on-call, and an explicit go/no-go check with the product owner and on-call lead 24 hours after the canary starts before expanding further. If the remaining 40% of budget were instead being burned by an ongoing, unresolved issue, the more defensible call would be to delay the rollout until that issue is fixed, since proceeding would be adding new risk on top of an already-active problem rather than a resolved one.

Trade-offs and pitfalls

Treating the error-budget percentage as a mechanical stop light (over 50% burned means automatic freeze, regardless of cause) is simpler to apply consistently but ignores real information about whether the remaining risk is active or already resolved, and can block genuinely low-risk, valuable work unnecessarily. The opposite failure, treating the number as advisory and rolling out anyway without adjusting the rollout's own risk profile, undermines the entire point of having an error budget as a real decision input rather than a dashboard nobody acts on. The healthiest version of this decision is fast (it should not take days to resolve) and transparent (the reasoning and the people consulted are visible after the fact, especially if the call turns out to be wrong).

Direct answer

Confirm it is actually a shared-tenancy problem, not your own workload or a real storage-side outage, by correlating your VM's iowait (the percentage of CPU time spent waiting on outstanding disk I/O) and latency against the cloud provider's own per-volume metrics; if your own I/O pattern and volume-level IOPS (input/output operations per second) and throughput look flat while latency still spikes, the delay is happening upstream of your VM, which is the noisy-neighbor signature. Mitigate by moving to a storage tier with dedicated (not shared) capacity, or by shaping your own demand so it fits inside whatever guaranteed floor the provider does offer.

Detection steps

Inside the VM, run iostat -x 1 and watch %util, await (average wait time per I/O, including queueing), and svctm/service time if available; a rising await with a %util well under 100% and no corresponding rise in your own request rate is the first sign something outside your control is adding latency. Check vmstat 1 for wa (iowait) climbing without a matching climb in your application's own disk read/write volume. Cross-reference against the cloud provider's own console or API metrics for the specific volume (e.g. VolumeQueueLength, VolumeReadOps, burst-balance/credit metrics on burstable volume types, a burstable volume banks I/O credit while idle and spends it to exceed its baseline IOPS temporarily, then throttles once credits run out): if the provider reports the volume's IOPS or throughput is below its provisioned ceiling, but your in-VM latency is still elevated, that gap is strong evidence of contention on the shared physical medium underneath your logical volume, not a problem with your own configuration.

Confirming noisy-neighbor behavior

Correlate the timing of latency spikes against anything periodic: many noisy-neighbor incidents track a schedule (another tenant's batch job, backup window, or scaling event) rather than being random, so plot the spikes against time of day over several days. If available, ask the provider for host-level or hypervisor-level contention metrics (some providers expose a "storage IOPS/throughput headroom" or burst-credit metric that surfaces exactly this). The strongest confirmation is a controlled test: run a fixed synthetic I/O load (e.g. fio, a synthetic disk-benchmarking tool, with a pinned queue depth and block size) at a fixed rate over time and watch whether its completion latency varies even though your synthetic load itself never changes; variance with a constant offered load is the signature of contention rather than your own demand.

Mitigations

Changing instance type or volume type to one with dedicated, provisioned IOPS/throughput (rather than a shared, best-effort or burst-credit-based tier) removes the shared-tenancy exposure directly, at higher cost. Enabling or raising provisioned IOPS limits on the volume itself guarantees a floor regardless of what neighbors are doing, though it does not help if the physical medium underneath is genuinely saturated across all tenants. Moving to dedicated hosts (a whole physical machine, or a storage tier reserved to a single tenant) eliminates the noisy-neighbor mechanism entirely, at the highest cost and least elasticity. Throttling your own I/O rate (via the same cgroup io.max/io.weight mechanism used on-host) can smooth self-inflicted spikes that make you a worse citizen even if you are not the primary cause, and can also protect latency-sensitive parts of your own workload from your own bursty parts. Request shaping, batching small writes, using write-behind buffering, or spreading a large sequential job over a longer window, reduces how hard you push a shared resource and can keep you comfortably inside whatever guaranteed floor exists.

Trade-offs and pitfalls

Dedicated hosts and dedicated storage tiers are the most reliable fix but the most expensive, and they give up the elasticity that made cloud storage attractive in the first place; use them only after detection has actually confirmed contention, not as a first reflex. Provisioned IOPS floors help against most noisy-neighbor scenarios but not a genuinely saturated underlying medium, so they are not a substitute for confirming root cause. The most common mistake is blaming noisy neighbors before ruling out a self-inflicted cause, such as your own application issuing far more small random I/O than expected (check your own request rate and block size distribution before escalating to the provider).

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.