DoorDash Site Reliability Engineer (Entry Level) - Comprehensive Interview Preparation Guide

Direct answer

Prioritize by expected business impact combined with how quickly the failure mode compounds if unaddressed: a region outage first, because it's a full-availability event with no partial-degradation option; a sudden 10x traffic spike second, because it threatens availability but usually has partial mitigations (throttling, degraded modes) available immediately; and an upstream schema change third, because it's typically detectable and containable with fast rollback before it causes user-facing damage, even though it can silently corrupt data if left uncaught.

Structured elaboration

For each curveball, separate the immediate runbook response from the longer-term architectural change it justifies.

Region outage. Immediate: fail over reads and writes to a secondary region using health-checked traffic routing, and pause non-essential batch work to reduce write pressure during the transition. Architectural change: multi-region active-passive (or active-active) replication for the data layer, with regularly rehearsed failover drills; a design that was never built to fail over won't fail over correctly under real pressure, only under a rehearsed one.

Sudden 10x traffic spike. Immediate: autoscale the serving tier, shed or degrade non-critical functionality (serve cached or slightly stale results rather than fail outright), and throttle low-priority background jobs to protect the real-time path. Architectural change: pre-warmed capacity headroom, adaptive rate limiting, and a defined degraded mode that's tested before it's needed, not designed during the incident.

Upstream schema change breaking the data pipeline. Immediate: fail fast on schema-validation errors at ingestion rather than let malformed data propagate, quarantine the bad batch, and roll the downstream transform back to the last known-good schema. Architectural change: enforce a schema contract at the pipeline boundary (a strongly typed serialization format with a compatibility check, such as Avro or Protocol Buffers) so a breaking upstream change is caught at ingestion rather than discovered downstream after it has already corrupted derived data.

Worked example

An illustrative prioritization exercise, scoring each curveball on business impact (1 low to 5 high) and detectability/containability (1 hard to 5 easy) to make the ranking auditable rather than a gut call: region outage scores high impact (5/5: full outage, all users) and moderate containability (3/5: requires a rehearsed failover, not just a code fix); 10x traffic spike scores high impact if unmitigated (4/5) but higher containability (4/5: autoscaling and shedding are standard, fast-acting levers); schema break scores lower immediate user-facing impact (2/5: the pipeline can often keep serving stale-but-correct data while paused) but containability that depends entirely on whether validation exists at the ingestion boundary (2/5 without it), if it doesn't, undetected corruption can silently spread for a long time before anyone notices, which is exactly why validation is the priority architectural investment for that curveball specifically, even though it's ranked last for immediate response.

Trade-offs & pitfalls

• Ranking these purely by which is scariest in the abstract, rather than by business impact and how fast each compounds if left unaddressed, produces a plausible-sounding but ungrounded priority order; tie the ranking to a concrete criterion.
• A schema break that lacks ingestion-time validation is deceptively low-priority in the short term and highest-priority for silent, compounding damage; don't let "least immediately visible" become "least urgent to architect for."
• Building all three mitigations simultaneously from scratch during a single design pass is rarely realistic; sequence the architectural investments and say explicitly which curveball's mitigation ships first and why.
• Rehearsing failure (game days, chaos testing, restore drills) is what turns a runbook from theory into something that actually works under pressure; a runbook that has never been executed is a plan, not a capability.

Direct answer. Good version-control hygiene means every commit and PR tells a clear, minimal, reviewable story: small commits with messages that explain WHY, PRs scoped to one reviewable change, and a branching approach the whole team actually follows consistently.

Commit granularity and messages

• Each commit should represent ONE logical change that could, in principle, be reverted independently without breaking something unrelated -- a commit that mixes a bug fix with an unrelated formatting sweep makes both harder to review and harder to revert cleanly later.
• Good message: Fix race condition in order total calculation (see INC-204)\n\nTwo concurrent requests could both read the stale total before either\nwrite committed. Wrap the read-modify-write in a transaction. -- explains WHY (the bug, the mechanism) not just WHAT (which is visible in the diff already).
• Bad message: fix bug -- tells a future reader (including git blame six months from now) nothing they couldn't already see from the diff itself, and gives zero context for WHY this change was needed.

PR size and branch/PR conventions

• Smaller PRs get reviewed faster and more thoroughly -- a reviewer can hold a 100-line diff in their head; a 2,000-line diff gets a rubber-stamp approval because nobody can meaningfully review it in one sitting.
• A consistent branch-naming convention (fix/order-total-race, feature/bulk-export) makes it easy to scan open branches and understand what's in flight without opening each one.
• Rebasing versus merging is a team-level convention choice (rebase keeps history linear and easier to bisect; merge preserves the exact chronological record) -- the specific choice matters less than the TEAM actually agreeing on and following one consistently, so history reads predictably regardless of who wrote it.

Handling large binary or generated files

• Committing large binaries (design assets, model weights, video fixtures) directly into a normal git history bloats every future clone and slows down operations like git log and git blame for the whole team, forever, even after the file is deleted, since git history keeps every version.
• Use Git LFS (or an equivalent large-file extension) for binaries that genuinely need to be version-controlled alongside code, so the main repository only stores a lightweight pointer.
• For anything that can be REGENERATED from source (build output, compiled assets, lockfile-derived artifacts), keep it out of version control entirely via .gitignore rather than committing it and then fighting merge conflicts on a file nobody hand-edits.
• If large files were already committed by mistake, history-rewriting tools (git filter-repo) can remove them retroactively, but that rewrites shared history and needs the same coordination caution as any other history rewrite on a branch others have pulled.

Why this matters for maintainability specifically

Git history is a maintainability tool in its own right: git blame and git log are often the FASTEST way to understand why a confusing piece of code exists, but only if commit messages actually explain the why -- a history of 'fix bug', 'wip', 'more fixes' gives future maintainers nothing to work with when they're trying to understand a decision made months or years ago.

Trade-offs and pitfalls

• Enforcing small PRs can pressure people to under-scope a change that's genuinely indivisible (e.g., a schema migration that must ship atomically with the code that depends on it) -- the goal is REVIEWABLE size, not an arbitrary line-count limit that ignores what a change actually requires.
• Rewriting history (interactive rebase, squashing) before merging to clean up a messy WIP trail is generally good practice, but doing it on a SHARED branch others have already pulled causes real pain -- keep history rewrites scoped to your own not-yet-shared branch.

Direct answer

A good game day has a tightly bounded scope, a named set of stakeholders who signed off before the experiment starts, a real-time comparison of the system's behavior against its SLIs (service level indicators: the specific numbers you track, like latency and error rate, that tell you whether the system is healthy) during the run, and a retrospective that turns findings into tracked action items, not just a summary email. The hard part is not running the experiment; it's building the recurring program and organizational trust that lets you run harder ones over time.

Scoping the experiment

Pick a single, realistic failure mode against a bounded slice of traffic: a specific dependency (cache, database replica, a downstream API), a specific service, and ideally a canary or staging slice of load rather than 100% of production on the first run. Define upfront what "done" looks like: which SLIs you'll watch, what the abort condition is, and who has authority to hit the kill switch.

Who to involve

• Service owners and on-call engineers for the system under test, since they know the failure modes and own the runbook being validated.
• A designated incident commander for the exercise itself, separate from whoever is executing the fault injection, so there's a clear decision-maker if things go sideways.
• Product or support stakeholders when the blast radius could touch real users, so they understand what "the recommendations service is intentionally broken for 20 minutes" means for anyone who notices.
• Observability or SRE tooling owners to make sure dashboards and alerting are actually wired up to catch what you're about to do, not just to catch organic incidents.

Measuring impact against SLIs

Capture a baseline of your SLIs (latency percentiles, error rate, saturation) before injecting the fault, then watch the same SLIs in real time during the run and compare against the SLOs (service level objectives: the target values you've committed to for those same indicators, e.g. 99.9% success rate). The goal is not "did it break" (you know it will) but "did it break within the bounds you predicted, and did the defenses (timeouts, circuit breakers, autoscaling) behave the way the runbook assumes they do."

Turning findings into a recurring program

A single successful game day proves one thing worked once. Standing up a recurring practice requires a roadmap: start with low-risk, staging-only experiments to build muscle memory and trust, then progressively widen scope (larger blast radius, real production traffic, less-scripted scenarios) as the team demonstrates it can run these safely. Getting buy-in usually means showing leadership a concrete finding from an early, low-risk drill (a specific gap the exercise surfaced) rather than asking for blanket permission to break production up front. Once a cadence is established (for example, monthly), track a maturity metric across runs, such as the fraction of prior findings that were actually remediated before the next drill, so the program itself is accountable.

Worked example

Consider a payments API game day: inject 200ms of added latency into its database replica for a scoped window, on a canary slice of traffic, with a monthly error budget of 43.2 minutes at a 99.9% SLO:

During the drill, the induced latency causes synchronous retries to queue up, and the service is measurably degraded (error rate above SLO) for 12 minutes before the circuit breaker trips and the fallback path kicks in. That single test consumed:

That is a legitimate, alarming finding on its own: a single scoped drill burning over a quarter of the monthly error budget means either the blast radius needs to be tightened further (smaller canary percentage) or the circuit breaker's failure threshold needs to trip faster. Either way it's a concrete, numeric input for the retrospective and the case for continued investment in the program, rather than a vague "went well."

Trade-offs & pitfalls

Widening scope too fast is the single biggest risk to the program's survival: one game day that causes a real customer-visible incident before the team has built confidence can kill the practice for a year. The opposite failure is scoping every drill so conservatively that it never surfaces anything new, which also erodes stakeholder buy-in because the exercise starts to look like theater. The retrospective is where most of the value is either captured or lost; findings that don't get a tracked owner and a re-test in the next cycle tend to silently repeat.

Placement, by workload

Workload A, the flexible batch job. Since it has no fixed start time and can tolerate being interrupted and resumed, put nearly all of its capacity on spot/preemptible instances. This is the workload spot pricing is built for: the discount is large and the downside of a preemption is just some lost progress, not a user-facing failure. Keep only a small on-demand fallback for the case where the deadline is close and spot capacity is unavailable.

Workload B, the latency-sensitive online API. Define a critical-path floor: enough reserved or on-demand capacity to serve the service's expected steady load on its own, with no dependency on spot being available. Anything above that floor (elastic burst capacity for traffic spikes) can use spot only if the fallback mechanism below is airtight; if it isn't, keep burst capacity on-demand too. The floor is sized off of steady-state traffic, not peak, because peak is exactly when you'd rather autoscale in additional (possibly spot) capacity rather than pay for it 24/7.

Surviving sudden preemption (the mechanism, not just the placement)

• Subscribe to the cloud provider's preemption/interruption notice (commonly a couple of minutes of warning) and treat it as an active signal, not a wait-and-see one: stop routing new requests to that instance immediately and begin draining in-flight work the moment the notice arrives.
• Checkpoint frequently enough that the interval between checkpoints is meaningfully shorter than the notice window, so an in-progress unit of work (a batch chunk, or an in-flight request for the online service) can either finish or be safely resumed rather than lost. For the batch workload, this means the job framework can pick up from the last checkpoint on a new instance. For the online service, this mostly means graceful connection draining rather than data checkpointing, since requests are short-lived.
• Pre-emptively launch a replacement instance as soon as the interruption notice arrives, rather than waiting for the instance to actually terminate and then reacting, so there's no capacity dip on the critical path.
• Diversify spot capacity across multiple instance types and availability zones. A single spot pool can be reclaimed all at once (correlated preemption), which is the actual failure mode a safety floor has to survive, not just an isolated single-instance loss.
• For the online API specifically, remove a spot instance from the load balancer's healthy pool the moment the interruption notice fires, rather than waiting for a failed health check after the fact, since a health check only detects the failure after it has already dropped requests.

Justifying the split. The batch job's cost is dominated by compute-hours with no per-request SLA (service level agreement, a contractual latency/availability promise), so its risk tolerance is high and spot's savings apply almost entirely. The online API's cost is a much smaller fraction of the total bill relative to the cost of an SLA breach, so its floor stays on guaranteed capacity even though that capacity is more expensive per hour, because the failure mode (a dropped or slow user request) is far more expensive than the price difference between spot and on-demand.

Direct answer
A strong STAR answer to 'a time you found and fixed a silently-failing bug' names the concrete detection method (how you noticed something was wrong despite no error being raised), the specific fix (not just 'I added error handling' but what kind and why), and, critically, the systemic change that prevents the SAME class of silent failure from recurring, not just this one instance.

Structured elaboration

• Situation: set up the context concisely (what system, what was the user-visible or business-visible symptom that eventually surfaced, even though no exception or alert had fired).
• Task: what you were specifically responsible for or chose to investigate, and why it mattered.
• Action: the concrete detective work (how did you trace a symptom back to a swallowed exception with no log trail), the specific code change (not vague: which exception types you now catch explicitly, what you log, whether you re-raise or recover), and the systemic prevention (a new test, a new metric, a broader sweep for the same anti-pattern elsewhere in the codebase).
• Convincing others to accept the defensive change: name the actual pushback you got (a reviewer worried the extra validation would add latency, or that raising instead of swallowing would be 'too disruptive' to existing callers) and how you addressed it concretely, whether by showing the cost of NOT fixing it (the weeks of undetected bad data) outweighed the marginal slowdown, by scoping the change narrowly so the velocity cost was small, or by walking a skeptical reviewer through the actual failure mode together; 'I added the check and nobody objected' is a much weaker story than genuinely winning over a skeptical teammate.
• Result: quantify where possible (how long the bug had been silently occurring before detection, what changed after the fix, e.g. 'the equivalent class of bug now surfaces within minutes via the new metric, versus the weeks it took to notice this one').
• What you learned: a genuine, specific lesson (not a platitude), ideally one that changed how you approach code review or design going forward (e.g., 'I now specifically look for bare except blocks in review, having learned how expensive they are to debug after the fact').

Worked example (a filled skeleton, illustrating the level of specificity expected)
"S: A weekly reporting pipeline was quietly producing undercounted totals for about three weeks before a stakeholder noticed the numbers looked off. T: I was asked to investigate why the totals seemed low. A: I traced it to a try/except: pass block that had been silently swallowing a schema-validation error on about 8% of incoming records; a reviewer initially pushed back that failing loudly instead of swallowing would risk new alert noise, so I scoped the fix to log-and-continue with a metric rather than a hard failure, which addressed the concern while still surfacing the problem; I fixed the immediate bug (the schema had drifted and the validation was too strict), added a metric tracking the record-rejection rate so a spike would be visible on a dashboard going forward, and grepped the rest of the codebase for the same bare-except pattern, finding and fixing four more instances. R: the specific bug was corrected and backfilled; the new metric caught a SIMILAR issue two months later within an hour, versus the three weeks it took to notice this one. L: I learned that a swallowed exception's cost isn't the bug itself, it's the TIME TO DETECTION, and that a metric is a much more reliable detection mechanism than hoping someone notices a downstream symptom."

Trade-offs and pitfalls
The most common weakness in a real candidate's answer to this question is stopping at 'I fixed the bug' without describing the SYSTEMIC prevention step (the new metric, the codebase-wide sweep); an interviewer specifically listens for that second layer, since it's what distinguishes someone who fixes symptoms from someone who addresses root causes and prevents recurrence.

Situation: We needed a company-wide SLO/error-budget policy across many services with different owners, SLAs, and maturity levels. My goal was to protect customers while preserving team autonomy.

Clarifying questions I asked:

• Who are our primary customer journeys and their availability/performance expectations?
• Which services are customer-facing vs internal, and what are their business priorities (revenue, compliance, experimentation)?
• What current telemetry exists (latency, error rates, availability) and how reliable is it?
• What timescales matter (per-minute, hourly, daily, weekly)?
• What are SLO consumers (support, legal, execs) and required reporting cadence?
• What exceptions are allowed (maintenance windows, planned feature flags, degraded modes)?

Negotiation and design steps I took:

1. Group services into tiers (critical, important, best-effort) based on customer impact and business priority — negotiate tier placement with owners using data and business metrics.
2. Propose measurable SLO templates per tier (e.g., critical: 99.99% availability monthly + p95 latency), with clear signal definitions (what metric, label filters, cardinality limits).
3. Define error budget policy: how burn is measured, alert thresholds (soft warning at 25% burn, hard at 50%), and automated vs human actions.
4. Create exception and onboarding process: teams can request temporary SLO adjustments with a justification, rollback plan, and stakeholder sign-off.
5. Enforcement mechanisms that preserve autonomy:
   • Require standardized SLO telemetry and dashboards but allow teams to implement internal mitigations.
   • Automate guardrails (rate limiters, circuit breakers, CI gates) for hard budget breaches; soft breaches trigger collaboration (runbook, monthly review).
6. Operational processes:
   • Monthly error-budget reviews with SRE, product, and service owners.
   • Playbooks for soft/hard burns, including rollback and feature holds.
   • Post-incident reviews tied to SLO breaches and improvement tickets.
7. Pilot and iterate: run policy on a few representative services, collect feedback, and adjust templates, thresholds, and tooling.

Result / rationale: This approach balances customer protection with team autonomy by using data-driven tiers, standard telemetry, clear escalation paths, and a lightweight exception process. It enforces critical protections with automation while keeping day-to-day remediation and design ownership with service teams.

Direct answer

Run a full happy-path checkout (cart through payment confirmation) from all three regions on a tight cadence, roughly once a minute, and treat anything short of a clean success within a defined latency budget as a failure. Require repeated or cross-region failures before paging, to avoid false alarms from one bad probe, and feed every synthetic result into the same SLO (service level objective: the reliability target you've committed to, e.g. 99.9% success rate) and error budget (the small amount of allowed failure within that target that you're allowed to "spend" before it counts as a breach) you'd use for real user traffic, not a separate, ignorable dashboard.

Structured elaboration

What to run and how often

• End-to-end purchase check (add to cart through payment confirmation, using a test card), once per minute per region. Checkout is revenue-critical, so it earns a tighter cadence than a typical health check.
• A faster, narrower payment-gateway probe (auth call only, no full checkout) every 30 seconds, since the third-party payment provider is a common independent failure point worth isolating from the rest of the flow.

What counts as a failure

Define assertions explicitly instead of just "checkout worked": correct HTTP status at each step, a payment-auth response within a fixed latency budget, and a confirmation page containing a valid order-ID pattern. A single failed run isn't enough to page on; require at least two consecutive failures in one region, or simultaneous failures across two of the three regions within a couple of minutes, to filter out a single flaky probe.

Feeding into SLOs and incident response

Map every failed synthetic check to a failed sample against your availability SLO, the same way a real failed user request would count. That turns "the synthetic checks are red" into "we're burning error budget," which is what actually drives escalation and postmortems, rather than synthetic checks living in their own dashboard that nobody treats as load-bearing.

graph TD
  P1[Probe US East] --> R[Results collector]
  P2[Probe EU West] --> R
  P3[Probe AP South] --> R
  R --> J{Check passed}
  J -->|yes| K[Update SLO burn rate]
  J -->|repeated failure| L[Fire alert]
  L --> M[Page on call]
  K --> N[Checkout dashboard]

At larger scale, the same design extends to hundreds of endpoints across dozens of global probe locations; the core mechanics (tiered alerting, SLO mapping, cross-region correlation before paging) don't change, only the fan-out does. It's also worth being explicit in an interview about how this differs from a canary deployment: synthetic checks continuously validate a flow against whatever is in production right now, while a canary validates a new version against a small slice of real traffic before a full rollout. They're complementary, not substitutes for each other.

Worked example

Tie the check cadence to a concrete SLO budget instead of leaving "how bad is bad" vague. For a 99.9% monthly availability target over a 30-day window:

That's the entire allowed downtime for the month, about 43 minutes. If checkout genuinely goes down and every one-minute check fails continuously, you'd burn through that whole monthly budget in the equivalent of 43 minutes of real downtime, which is exactly why the alert threshold (two consecutive failures, roughly two minutes) has to fire an order of magnitude faster than the point at which the budget is exhausted, not wait until it's gone.

Trade-offs and pitfalls

Running checks too frequently against a real payment provider can hit third-party rate limits or, worse, create real (refunded) transactions at a cost and operational overhead that adds up; balance check frequency against that cost rather than defaulting to "as often as possible." The biggest pitfall is conflating a synthetic failure with a payment-gateway outage: if only the payment-auth probe fails while the rest of checkout is healthy, that's a signal to page the payments team specifically rather than declare a site-wide incident, so keep the two failure modes visibly separate on the dashboard. Finally, remember synthetic checks only catch what you scripted; they won't catch a novel edge case (a specific product variant, a specific promo code) that real user traffic exercises but the synthetic script never touches, so pair synthetics with real-user monitoring rather than relying on synthetics alone.

Direct answer
Give the listener a short roadmap up front (what you're about to walk through and in how many steps), narrate one idea at a time in order, and periodically restate where you are relative to that roadmap, rather than free-associating through your thought process.

Structured elaboration

1. State the roadmap before diving in: "There are two things going on here: first the root cause, then the fix I'd propose. Let me start with the root cause." This gives the listener a mental container to place what follows.
2. Narrate conclusions and reasons, not raw stream-of-consciousness. Say what you're checking and why, not just what you're doing: "I'm checking the logs because I suspect this is a timeout, not a crash," rather than silently scrolling and occasionally muttering.
3. Signal transitions explicitly: "okay, that rules out X, so now let's look at Y," so the listener can track your position in the reasoning instead of having to reconstruct it after the fact.
4. Pause at natural checkpoints to check the listener is still following, especially before switching to a new sub-problem, rather than only checking in at the very end.
5. Name your assumptions out loud as you make them, since an unstated assumption is invisible to the listener and, if wrong, can make the rest of your reasoning look wrong for a reason they can't see.

Worked example
Unstructured: "Okay so let me look at this... hmm... yeah so there's this function... wait, let me check something else... okay so actually I think the issue might be... let's see... yeah I think it's the caching."

Structured: "I'm going to check three possible causes in order of likelihood: caching, a race condition, or a bad config value. Starting with caching, since it's the most common cause of this symptom... [checks] ...that rules out caching, the values are fresh. Moving to the race condition..."

The second version gives the listener the plan up front, tells them which hypothesis is being tested and why, and explicitly states when a hypothesis is ruled out, so they can follow the reasoning instead of just watching an unexplained sequence of actions.

Trade-offs and pitfalls

• Over-narrating every micro-step can slow you down and annoy a listener who just wants the conclusion; calibrate the level of narration to whether the audience needs to follow the reasoning (an interview, a mentoring session) or just wants the answer (a peer who trusts you and is short on time).
• It's easy to silently switch approaches mid-thought without saying so; if you change direction, say so explicitly ("actually, let me back up") rather than leaving the listener to notice on their own.
• This is a skill that degrades under real pressure or unfamiliar problems; it's worth practicing the "state the roadmap first" habit specifically, since it's the cheapest part to do consistently even when the rest of your thinking is genuinely uncertain.

SLI/error-budget gaming is rarely malicious in intent, more often a well-meaning team under pressure quietly redefining what counts as a failure, so the controls need to make gaming both harder to do accidentally and easier to detect when it happens.

Structured elaboration

Metric design practices: define SLIs and their exact computation logic in a document OWNED outside the team being measured (e.g. by an SRE or platform group), so the team whose performance the metric reflects isn't also the sole author of what counts as "good"; require any change to an SLI's definition (which error codes count, which labels get filtered) to go through a review process with that same outside owner, rather than being a config change the team can make unilaterally. Review processes: periodic audits comparing a team's reported SLI against an INDEPENDENT signal (e.g. a synthetic check run by a separate team, or raw log data pulled directly rather than through the team's own dashboard), specifically looking for divergence between the two that would indicate the reported number has been quietly massaged. Detection techniques: watch for statistically suspicious patterns, like an SLI that sits suspiciously exactly at the threshold repeatedly (rather than the natural variance you'd expect from a genuinely healthy or unhealthy system), or a sudden, unexplained change in error-classification logic timed suspiciously close to a reporting period's end.

Worked example

Three concrete anti-patterns worth naming explicitly: (1) filtering out a specific error class from the SLI's denominator with a rationalized-sounding but self-serving justification (e.g. "those errors are the client's fault, not ours") applied inconsistently or only after the team started missing its target; (2) changing an instrumentation LABEL (e.g. reclassifying a genuine 5xx as a 4xx) rather than fixing the underlying issue, quietly making the SLI look healthier without the actual user experience improving at all; (3) using error budgets purely as a team-level KPI or incentive metric (bonuses, performance reviews tied directly to SLI numbers), which creates direct personal incentive to game the very metric meant to keep the team honest, and is often the ROOT CAUSE that makes patterns 1 and 2 attractive in the first place.

Trade-offs and pitfalls

The single biggest structural fix is separating "who defines and can change the metric" from "who is measured by it," since almost every gaming pattern above becomes much harder when the team being measured can't unilaterally redefine what's being measured. It's also worth being honest that SOME legitimate reasons exist to refine an SLI's definition over time (a genuine measurement bug, a legitimately mis-scoped error class), so the review process needs to distinguish a legitimate, well-justified, externally-reviewed refinement from a self-serving one, rather than treating every SLI-definition change as inherently suspicious, which would also discourage genuine, warranted improvements to measurement quality.

To view and manipulate the kernel routing table on Linux you use the iproute2 tools (ip command). The main command to inspect routes is ip route show.

Examples — viewing:

# show all routes
ip route show

# show routes for a particular table or family
ip -4 route show
ip route show table main

Add a default gateway:

# add default route via gateway 192.0.2.1 on eth0
sudo ip route add default via 192.0.2.1 dev eth0
# with a metric (lower is preferred)
sudo ip route add default via 192.0.2.1 dev eth0 metric 100

Delete a route:

# delete the exact default route
sudo ip route del default via 192.0.2.1 dev eth0

# delete a specific network route
sudo ip route del 10.0.0.0/24 dev eth1

Route metrics and preference:

• Routes are matched by longest-prefix (most specific) first. If multiple routes have identical prefix length, the kernel uses route priority based on metric (sometimes called distance) — lower metric wins.
• You can also influence selection with multiple routing tables and rules (ip rule) for policy routing.
• When equal metrics and equal specificity exist, the kernel may use multipath (load balance) if configured (nexthop entries) or deterministic tie-breakers.

Practical tips:

• Persist routes via distro network configs or /etc/netplan/systemd-networkd settings; ip route changes are transient.
• Use ip route get <dest> to see which route/kernel would choose and which interface/gateway it will use.