Microsoft Site Reliability Engineer (Junior Level) - Comprehensive Interview Preparation Guide

What "stateless" means

A service is stateless when no single instance of it holds anything in memory or on local disk that is required to correctly handle the NEXT request. Concretely, that means:

• No server-side session held in process memory. Login state, shopping-cart contents, or in-progress workflow data live in an external store (Redis, a database, a signed client-side token), not in a variable inside the running process.
• No reliance on local disk for anything that must outlive one request. Uploaded files, generated reports, and cached artifacts go to shared/object storage (S3-style), not the instance's own disk, because that instance can be replaced at any moment.
• Any instance can serve any request. There is no "the user's session is pinned to instance 7" requirement; a load balancer can route to whichever healthy instance it likes.
• Requests are self-describing. Each request carries (or references, via a token/ID) everything needed to process it, so a retry against a different instance behaves identically to the original.

A 3-tier design that maximizes autoscalability

flowchart LR
    C[Clients] --> LB["Tier 1: Load Balancer / API Gateway"]
    LB --> APP["Tier 2: Stateless App Servers<br/>(autoscaling group)"]
    APP --> DATA[("Tier 3: Shared Data Store<br/>DB + cache")]

Tier 1, load balancer / gateway. Terminates TLS, does L7 (Layer 7, the application layer, so it can route based on the actual HTTP request rather than just IP and port) routing and health checks, and is itself provided as a managed, already-redundant service (an ALB/NLB, AWS's Application Load Balancer / Network Load Balancer, or equivalent), so you generally don't hand-manage its scaling.

Tier 2, app servers. This is the tier the statelessness rules above apply to directly. Because instances are interchangeable, this tier can scale purely horizontally: add or remove identical instances behind the load balancer with zero coordination between them.

Tier 3, data store. This tier is deliberately the exception, it is where the real state lives (a relational or key-value database plus a cache like Redis for session/shared data). It does not scale the same way; it scales via read replicas, partitioning/sharding, and connection pooling rather than freely adding identical nodes.

How each tier scales, and the metrics that drive it

• Load balancer tier: scales automatically as a managed service; the metric you watch here is more about health (5xx rate, target response time) than capacity you control directly.
• App tier: scales horizontally, driven by autoscaling policies. Useful metrics, in rough order of how directly they reflect load: in-flight requests per instance / request queue depth (most direct signal of saturation), p95/p99 request latency (the latency value below which 95%/99% of requests complete, a way of watching the slow tail rather than just the average; catches saturation before CPU maxes out), CPU utilization (simple and common, but lags for I/O-heavy services), and custom requests-per-second-per-instance if you've load-tested a known safe ceiling per instance.
• Data tier: does not autoscale the same way. You scale reads by adding replicas (driven by replica CPU and replication lag metrics) and scale writes by vertical sizing or sharding (driven by connection-pool saturation and write IOPS, input/output operations per second, the rate of read/write operations a storage volume can sustain), because unlike the app tier it cannot simply spin up an identical, empty copy of itself on demand.

Worked example

Suppose peak traffic is 3,000 requests/second, and a load test shows one app-tier instance can sustainably handle 150 RPS while staying at your target CPU headroom (say 70%, leaving margin for spikes).

That 150 RPS-per-instance number is the whole point of the exercise: it only comes from load-testing this specific service, not from a generic rule of thumb, and it's what your autoscaling policy's target metric (CPU, latency, or in-flight-requests threshold) is calibrated against.

Direct answer
A strong answer to this needs to show calm, specific ownership: what you actually noticed, what you actually did in triage and containment (not a vague 'we fixed it'), how you kept people informed while you were still working the problem, and a concrete, real follow-up change that came out of it, not just a general lesson learned.

Structured elaboration
Walking through the STAR structure and what an interviewer is actually listening for at each part:

• Situation. Set up enough context to matter: what service, what kind of impact, roughly how severe. Interviewers are listening for whether you can quickly orient someone else, since that's exactly the skill needed during a real incident.
• Task. Your specific role and responsibility in that moment, not the whole team's. Were you the first responder, the person who happened to notice, someone brought in partway through? This matters because it sets the frame for whether the actions you describe next were really yours.
• Action. This is the section that carries the most weight, and it needs actual specifics: what you checked first, what hypothesis you formed and how you tested it, what mitigation you applied and why you chose it over alternatives, and specifically how you communicated (to whom, how often, what you said versus what you didn't yet know). Vague answers ('I investigated the issue and resolved it') are the single most common weakness here.
• Result. The concrete outcome: how long it took, what the actual resolution was, and critically, what changed afterward as a genuine consequence, whether that's a new test, a new alert, a runbook that didn't exist before, or a process change. A result without a real follow-up change suggests the lesson wasn't actually internalized.

Worked example
An illustrative skeleton, not a claimed real transcript: 'I was on call when an alert fired for elevated error rates on our checkout service (Situation). As the first responder, my job was to assess scope and either resolve it or escalate within the first 15 minutes (Task). I checked our error dashboard and saw it correlated closely with a deploy that had gone out about ten minutes earlier, so I rolled that deploy back rather than trying to debug it live, and posted a status update to our incident channel explaining what I'd found and what I'd done, then a follow-up once error rates had held steady for a while confirming things looked resolved (Action). The rollback resolved the issue within a few minutes, and afterward I worked with the team to add a canary step to that deploy pipeline so a similar regression would be caught on a small percentage of traffic before a full rollout next time (Result).'

Trade-offs and pitfalls
The most common weak answer stays entirely at the process level ('we followed our runbook and resolved it') without any of the actual technical or judgment specifics an interviewer is trying to assess. A second common weakness is claiming sole credit for what was clearly a team effort, which reads as either dishonest or as a poor understanding of how real incidents get resolved; naming your specific individual contribution within a team response is stronger and more credible than implying you did it all alone. A third weakness is a result with no real follow-up change, which suggests the incident was treated as a one-off rather than a source of a lasting improvement.

Direct answer

Treat the hiding behavior as a signal that the dashboard is being used, or is perceived as being used, to assign blame, not just to surface facts. The fix starts with decoupling the data from performance judgment, not with re-explaining the dashboard. Bring the teams who are hiding issues into redesigning what gets shown and how, and restore full visibility gradually once trust is demonstrated, not all at once.

Structured elaboration

1. Diagnose before redesigning. Find out whether the hiding is a reaction to an actual punitive incident (someone's numbers were cited unfavorably somewhere) or a perception problem with no real incident behind it. The fix differs: a real incident needs an explicit reversal, a perception problem needs a clearer signal from leadership.
2. Decouple the data from evaluation. State explicitly, and have leadership repeat it, that the dashboard's numbers are never cited in individual or team performance reviews. Words alone will not fix it if the incident is real; the statement has to be paired with visible follow-through.
3. Co-design the redesign. Bring the teams who are hiding issues into a working session on what gets tracked and how it is displayed. A redesign handed down without their input repeats the same trust problem in a new shape.
4. Pair exposure with a path forward. Every flagged item should carry a remediation affordance, an owner and a next step, so appearing on the dashboard reads as "here is what is being done" rather than only "you are behind."
5. Reintroduce gradually. Pilot the redesigned version with one or two teams first. Prove it is not being weaponized before rolling it back out to everyone; restoring full visibility immediately risks relapsing into the same hiding behavior before trust has actually rebuilt.

Worked example

Consider a flaky-test dashboard (the same pattern applies to an on-call load dashboard or a per-team bug-backlog view). After teams start mislabeling or hiding flaky tests, a short retro with a few team leads surfaces that two of them had their flaky-test counts cited unfavorably in a quarterly review months earlier, the actual punitive incident. Leadership issues an explicit statement that this data is excluded from reviews going forward, and the dashboard is redesigned with those teams to add a "remediation in progress" state instead of a raw open count. The redesigned dashboard is piloted with the same teams for one cycle, and only restored org-wide after that cycle shows honest reporting returning without any negative consequence.

Trade-offs & pitfalls

• Doubling down on enforcement, mandating reporting or adding compliance checks, tends to deepen the hiding rather than fix the underlying incentive.
• Quietly abandoning the dashboard rather than repairing it avoids the immediate conflict but permanently loses the transparency it was built to provide.
• Junior candidates tend to propose a better UX or better metrics for the dashboard. Senior candidates fix the trust and incentive problem first; the dashboard redesign is secondary to that.
• Restoring full visibility immediately after the fix, without a pilot, is a common pitfall: it risks a relapse into hiding before the teams have had a chance to see the new incentive hold up over time.

I'll use Go (single-file) with a simple polling watcher (safe for easy SRE tooling). It scans a directory for new/updated *.xml every 5s, parses JUnit XML for tests, failures, and time, and exposes Prometheus metrics labeled by job (from env or filename prefix) and suite (from testcase suite name).

package main

import (
	"encoding/xml"
	"flag"
	"io/ioutil"
	"log"
	"net/http"
	"os"
	"path/filepath"
	"strings"
	"sync"
	"time"

	"github.com/prometheus/client_golang/prometheus"
	"github.com/prometheus/client_golang/prometheus/promhttp"
)

type Testsuite struct {
	XMLName  xml.Name `xml:"testsuite"`
	Name     string   `xml:"name,attr"`
	Tests    int      `xml:"tests,attr"`
	Failures int      `xml:"failures,attr"`
	Time     float64  `xml:"time,attr"`
}
type Testreport struct {
	XMLName   xml.Name    `xml:"testsuites"`
	Testsuite []Testsuite `xml:"testsuite"`
}

var (
	dir     = flag.String("dir", ".", "directory to watch for junit xml files")
	period  = flag.Duration("period", 5*time.Second, "polling period")
	jobEnv  = os.Getenv("JOB") // optional
	mtx     sync.Mutex
	seen    = map[string]time.Time{}
	total   = prometheus.NewGaugeVec(prometheus.GaugeOpts{Name: "tests_total", Help: "Total tests"}, []string{"job", "suite"})
	failed  = prometheus.NewGaugeVec(prometheus.GaugeOpts{Name: "tests_failed", Help: "Failed tests"}, []string{"job", "suite"})
	seconds = prometheus.NewGaugeVec(prometheus.GaugeOpts{Name: "tests_duration_seconds", Help: "Duration seconds"}, []string{"job", "suite"})
)

func init() {
	prometheus.MustRegister(total, failed, seconds)
}

func parseFile(path string) {
	data, err := ioutil.ReadFile(path)
	if err != nil {
		log.Println("read:", err)
		return
	}
	var r Testreport
	if err := xml.Unmarshal(data, &r); err != nil {
		// try single testsuite root
		var s Testsuite
		if err2 := xml.Unmarshal(data, &s); err2 != nil {
			log.Println("xml unmarshal:", err)
			return
		}
		r.Testsuite = append(r.Testsuite, s)
	}
	job := jobEnv
	base := filepath.Base(path)
	if job == "" {
		// convention: jobname_suite.xml or job-suite-... else default "unknown"
		parts := strings.SplitN(base, "_", 2)
		if len(parts) > 1 {
			job = parts[0]
		} else {
			job = "unknown"
		}
	}
	for _, ts := range r.Testsuite {
		suite := ts.Name
		if suite == "" {
			suite = strings.TrimSuffix(base, filepath.Ext(base))
		}
		total.WithLabelValues(job, suite).Set(float64(ts.Tests))
		failed.WithLabelValues(job, suite).Set(float64(ts.Failures))
		seconds.WithLabelValues(job, suite).Set(ts.Time)
	}
}

func pollLoop() {
	for {
		filepath.Walk(*dir, func(path string, info os.FileInfo, err error) error {
			if err != nil || info.IsDir() || !strings.HasSuffix(strings.ToLower(path), ".xml") {
				return nil
			}
			mtx.Lock()
			mod := info.ModTime()
			prev, ok := seen[path]
			if !ok || mod.After(prev) {
				seen[path] = mod
				mtx.Unlock()
				parseFile(path)
			} else {
				mtx.Unlock()
			}
			return nil
		})
		time.Sleep(*period)
	}
}

func main() {
	flag.Parse()
	go pollLoop()
	http.Handle("/metrics", promhttp.Handler())
	log.Println("listening :9090")
	log.Fatal(http.ListenAndServe(":9090", nil))
}

Key points:

• Simple polling is robust on NFS/containers; replace with fsnotify for low-latency.
• Uses Prometheus GaugeVecs labeled by job and suite.
• Time complexity: O(n) per scan where n = files; space O(m) for seen map.
  Edge cases:
• Multiple testsuites in one file handled.
• Invalid XML skipped with log.
• Large directories: consider incremental processing, fsnotify, or moving processed files.

Requirements and constraints:

• Detect intermittent, config-specific infra anomalies (packet loss, CPU steal, noisy neighbors) with low false positives and actionable alerts.
• Support transient events (seconds to minutes), per-tenant/container granularity, and correlation across networking/CPU/latency.

Telemetry to collect (high-resolution + tagged):

• Host-level: per-core CPU usage, steal time, iowait, runqueue length, scheduler wakeups (bpf), CPU frequency states.
• Container/cgroup: cpuacct.stat, cpu.shares, throttling, cpuset info.
• NIC: per-queue drops, tx/rx errors, ring buffer utilization, interrupts per-CPU, ethtool stats, driver-specific metrics.
• Network path: per-interface retransmits, TCP RTOs, RTT samples, packet loss counts, queue length, TC/iptables counters.
• Latency: request latency histograms (HDR histograms) at multiple service layers (client-side, edge, backend) with p50/p95/p99/p999 and latency buckets.
• Tracing: distributed traces with tags for host/container and network interface.
• Sampling artifacts: tcpdump/pcap snippets triggered on anomalies, and eBPF summaries (lost packets per syscall).
• Synthetic: active probes (ICMP and TCP), small and large payloads, multi-path tests, application-level health checks with realistic payloads, and inter-host microbenchmarks (iperf3, latency jitter tests).

Synthetic test design:

• Run continuous low-amplitude probes (1s–10s cadence) and heavier scheduled tests to stress NIC/CPU for noisy-neighbor reproduction.
• Vary packet sizes and concurrency to expose MTU/queuing problems.
• Probe within same host, across hosts on same rack, and across racks to isolate layer (host vs network vs upstream).
• Canary pipelines: deploy canary containers with dedicated CPU/NIC isolation and compare their metrics against regular tenants.

Baselining and anomaly detection:

• Two-layer baselines: short-term rolling (5–60m) and long-term seasonal (24h, weekly) to account for diurnal patterns.
• Use distributional baselines on histograms (not just mean): track quantiles and variance. Store HDR histograms to compare distributions with statistical tests (KS test) and KL divergence.
• Multi-signal correlation: compute joint anomalies (e.g., CPU steal spike + runqueue increase + tail latency increase) using Bayesian or ML-based anomaly detectors (isolation forest, EMA z-score on quantiles) tuned with historical incidents.
• Maintain per-host and per-tenant baselines; use clustering for similar hardware classes to reduce misalerts.

Alerting strategy to reduce noise:

• Alert on correlated signatures, not single metric jumps. Example high-priority alert: sustained p99 latency increase AND >2% packet loss on path OR >5% CPU steal across >2 cores for >2 minutes.
• Use severity tiers: Info (deviation detected), Warning (impacting SLO burn), Critical (SLO breach or cascading failures).
• Dynamic thresholds: percentiles above baseline + minimum absolute delta (prevents alerts on tiny fluctuations).
• Rate-limit flapping alerts with cooldown windows and automated escalations if unresolved. Implement deduplication by topology (rack/host pool).
• Auto-triage: attach recent histograms, trace spans, synthetic probe results, and a short runbook (what to check: interrupts, NIC ring state, host migrations).
• Post-alert automation: trigger packet captures or resource capping (cpu quota) as safe mitigations for noisy neighbors.

Operational considerations:

• High-resolution retention: keep 1s–5s metrics for 1–7 days, aggregated to 1m/5m for longer-term.
• Cost/volume: use sampled tracing and aggregated histograms to limit cardinality; label cardinality hygiene.
• Runbooks and replay: store incident fingerprints to speed diagnosis; simulate anomalies during game days to validate detection and reduce false positives.

This plan prioritizes multi-signal, distribution-aware detection with synthetic verification and actionable alerts to catch hard-to-reproduce infra anomalies while minimizing noise.

Direct answer
The OSI model splits network communication into seven layers, each handing off a well-defined unit of work to the layer above and below it: Physical, Data Link, Network, Transport, Session, Presentation, and Application. Knowing which layer a protocol or symptom belongs to lets you reason about failures systematically instead of guessing.

Structured elaboration

The mnemonic that matters more than memorizing names is the DIRECTION of responsibility: each layer only needs to trust the layer directly below it to deliver its unit of data, and it only exposes a clean interface to the layer above. That's what lets a Transport-layer protocol like TCP work identically over Ethernet, Wi-Fi, or a VPN tunnel: it never needs to know which Layer 1/2 technology is underneath.

Worked example
Say a user reports "the site is down." Layer-by-layer reasoning turns that vague complaint into a specific hypothesis:

• Physical/Data Link symptom: the NIC shows no link light, or ip link reports the interface as DOWN a cable or switch-port problem.
• Network layer symptom: ping to the server's IP times out but the local gateway responds a routing problem somewhere between here and there.
• Transport layer symptom: ping succeeds but a TCP connection to the port hangs or resets a firewall, a service that isn't listening, or a transport-level issue.
• Application layer symptom: the TCP connection completes but the HTTP response is an error or garbage the service is up but misbehaving.

Each of these is a different team, a different fix, and a different urgency. That's the actual payoff of the model: it turns "the site is down" into "which layer, which evidence."

Trade-offs & pitfalls
The OSI model is a teaching and troubleshooting framework, not how real stacks are literally implemented. Session and Presentation are rarely separate pieces of code in modern systems; TLS, for instance, is commonly described as "sits between Transport and Application" rather than cleanly as Layer 6. Don't over-fit a real symptom to exactly one layer: a firewall dropping SYN packets looks like a Transport-layer symptom (connection never establishes) but the actual cause and fix live at a security-policy layer that OSI doesn't model at all.

A correlation ID is a single identifier generated at the edge of a request and propagated through every hop, so logs, metrics, and traces from otherwise-independent services can be joined into one end-to-end picture.

Design

1. Generate once, at the edge (the first service to see the request), and reject or ignore any incoming ID from an untrusted external source unless you specifically want to correlate with an external partner's identifier.
2. Propagate via headers (e.g. X-Request-Id or the W3C traceparent format) on every downstream call, and via message baggage for async work (queue messages, background jobs) so the ID survives a hop that isn't a synchronous HTTP call.
3. Attach it to every log line and trace span emitted while handling that request, not just at the top-level handler.
4. For third-party/legacy components you cannot instrument, enrich logs at your own ingress/egress boundary around that component (the request going in, the response coming out) so you can at least bound how much time was spent inside the black box, even without visibility inside it.
5. Query time: given an ID, a single query across the log/trace store reconstructs the full path, ordered by timestamp, across every service that touched the request.

Trade-offs and pitfalls

High-cardinality IDs are cheap to log but expensive to index if you try to make every field high-cardinality; keep the correlation ID itself indexed and unique, but avoid also indexing every other high-cardinality field (like raw user input) at the same tier, or storage cost balloons. Sampling (only tracing 1% of requests in detail) is fine for aggregate analysis but means a specific customer's specific failing request may not have full trace data; the mitigation is to force full capture whenever an error is detected on that request, regardless of the sampling decision made at the start.

Error-budget borrowing lets a team spend AHEAD of its normal allocation for a specific, justified reason (a planned risky migration, a time-sensitive launch), as long as it's repaid, and the policy's whole job is making sure "borrowing" doesn't quietly become "just not tracking budget properly."

Structured elaboration

Allowed borrow amounts: capped at a modest fraction of the team's NEXT period's allocation (e.g. up to 20% of next month's budget can be borrowed against this month), preventing a team from borrowing so much that they're effectively operating with zero real margin for an extended stretch. Repayment time windows: a defined, short horizon (e.g. borrowed budget must be repaid, meaning the team operates with EXTRA caution and reduced risk-taking, within the following month), not an open-ended IOU that can persist indefinitely. Visibility requirements: every borrow event is logged in the same shared, auditable registry used for other governance actions, visible to any team or stakeholder who might reasonably want to know a team is currently operating on borrowed budget. Penalties or incentives: a team that fails to repay within the agreed window loses borrowing privileges for a defined cooldown period (e.g. two subsequent months), a real but proportionate consequence.

Worked example

Compliant scenario: Team A wants to ship a planned, moderately-risky database migration next week that they've assessed will likely consume more budget than their current month's remaining allocation supports; they formally request to borrow 15% of next month's budget, documented with the specific justification and expected repayment plan, approved via the standard lightweight sign-off, and visible to other teams sharing any affected infrastructure. Non-compliant scenario: Team B has been quietly running over budget for three consecutive months without ever formally requesting to borrow, simply treating each month's overage as if it will "sort itself out," with no visibility to anyone else and no explicit repayment plan; this is exactly the undisciplined pattern the formal borrowing policy exists to replace, since an UNTRACKED overage gives none of the planning benefit a formally-documented borrow arrangement provides.

Trade-offs and pitfalls

Without a real, felt consequence for failing to repay, "borrowing" degrades into a polite fiction that lets a team perpetually operate over budget while calling it something more palatable; the cooldown-period consequence needs to be genuinely enforced, not waived informally when a team has a good excuse each time. It's also worth deciding whether TWO teams should be allowed to simultaneously borrow against a SHARED downstream dependency's stability, since two individually-approved, modest borrow requests could combine to create a much larger combined risk than either looks like in isolation; a genuinely lightweight policy still needs at least a basic check for this kind of compounding risk across simultaneous borrow requests.

Direct answer. Use the bash builtin getopts in a while loop with an option string such as ':ho:r:'. A letter followed by a colon takes a value, which arrives in $OPTARG. After the loop, shift $((OPTIND - 1)) removes the parsed options so the positional argument is $1. The leading colon puts getopts in silent mode so you print the error messages yourself. Check that the required options and the positional exist, and on any problem print a message and usage to stderr and exit non-zero (2 by convention for a usage error). -h prints usage to stdout and exits 0.

Script

A few pieces of shell syntax appear in it. ${0##*/} takes $0 (the path the script was started with) and strips everything up to the last /, leaving just the file name. cat <<EOF ... EOF is a here-document: it feeds the lines between the markers to cat as input, a convenient way to print several lines of text. [[ $retries =~ ^[0-9]+$ ]] tests a value against a regular expression (here: one or more digits and nothing else). (( $# == 1 )) is an arithmetic test, and $# is the number of positional arguments, meaning the words left after the options. exit 2 stops the script with status 2.

This script takes -o OUTDIR and -r RETRIES, each with a value, and exactly one URL.

#!/usr/bin/env bash
# usage: fetch.sh -o OUTDIR -r RETRIES [-h] URL
set -euo pipefail

prog=${0##*/}
usage() {
  cat <<EOF
Usage: $prog -o OUTDIR -r RETRIES URL
  -o OUTDIR   directory to save into (required)
  -r RETRIES  number of retries, a non-negative integer (required)
  -h          show this help and exit 0
EOF
}
die() { echo "$prog: $*" >&2; usage >&2; exit 2; }   # 2 = usage error

outdir='' retries=''
while getopts ':ho:r:' opt; do        # leading ':' = we report errors ourselves
  case $opt in
    h) usage; exit 0 ;;
    o) outdir=$OPTARG ;;
    r) retries=$OPTARG ;;
    :) die "option -$OPTARG needs a value" ;;
    \?) die "unknown option -$OPTARG" ;;
  esac
done
shift $((OPTIND - 1))                 # drop the parsed options, leave positionals

[[ -n $outdir ]]  || die "missing required option -o"
[[ -n $retries ]] || die "missing required option -r"
[[ $retries =~ ^[0-9]+$ ]] || die "-r must be a non-negative integer, got '$retries'"
(( $# == 1 )) || die "expected exactly one URL, got $#"
url=$1

echo "url=$url outdir=$outdir retries=$retries"

How it works

• Option string ':ho:r:'. The leading : selects silent error handling. h takes no value, o: and r: do.
• Silent-mode cases. A missing value arrives as opt=: with the option letter in $OPTARG. An unrecognised option arrives as opt=?. The ? is a glob character so it is escaped (\?) in the case.
• OPTIND. It holds the index of the next argument to process. shift $((OPTIND - 1)) leaves only the positionals.
• Validation after parsing. Required options are checked afterwards, because getopts has no notion of "required". -r is validated with a regular expression so -r x is rejected with a clear message.
• Exit codes. Help is exit 0 and goes to stdout, so fetch.sh -h | less works. Errors go to stderr and exit 2.
• Quoting. Every expansion in the script is quoted, so a value containing spaces survives inside the script. The caller must quote it too, because the shell splits the command line into words before the script starts (see the transcript below).

Running it

Each block shows the command as typed, the first line it printed, and its exit status (the full usage text follows the first line on errors). The second command quotes the two values that contain spaces, and the third shows the same command without those quotes:

$ fetch.sh -o /data -r 3 https://example.com/a
  url=https://example.com/a outdir=/data retries=3
  exit=0
$ fetch.sh -r 3 -o '/my data' 'https://example.com/a b'
  url=https://example.com/a b outdir=/my data retries=3
  exit=0
$ fetch.sh -r 3 -o /my data https://example.com/a b
  fetch.sh: expected exactly one URL, got 3
  exit=2
$ fetch.sh -h
  Usage: fetch.sh -o OUTDIR -r RETRIES URL
  exit=0
$ fetch.sh -o /data https://example.com/a
  fetch.sh: missing required option -r
  exit=2
$ fetch.sh -o /data -r
  fetch.sh: option -r needs a value
  exit=2
$ fetch.sh -o /data -r x https://example.com/a
  fetch.sh: -r must be a non-negative integer, got 'x'
  exit=2
$ fetch.sh -x -o /data -r 3 https://example.com/a
  fetch.sh: unknown option -x
  exit=2
$ fetch.sh -o /data -r 3
  fetch.sh: expected exactly one URL, got 0
  exit=2
$ fetch.sh -o /data -r 3 -- -weird-url
  url=-weird-url outdir=/data retries=3
  exit=0
$ fetch.sh https://example.com/a -o /data -r 3
  fetch.sh: missing required option -o
  exit=2

Reading the quoting pair: with quotes, the shell hands the script one word for /my data and one for the URL, so getopts sees -o '/my data' and a single positional. Without quotes the shell splits on spaces first, so /my becomes the value of -o and data, the URL and b are three positionals, which the (( $# == 1 )) check rejects with exit 2.

Trade-offs and pitfalls

• getopts stops at the first non-option argument. Options placed after the URL, as in the last case, are not parsed (here -o was reported missing). Use -- to pass an argument that begins with a dash, as shown with -weird-url.
• It supports only single-letter options. Long options (--output) need a hand-written while/case loop over $1 with shift, or the external GNU getopt (not available on every system, and its use needs care).
• Without the leading colon, getopts prints its own message in its own format and you lose control of the wording.
• Count the positionals after the shift. Use (( $# == 1 )) rather than testing $1 alone, so extra arguments are an error too.
• Keep usage in a function so the help text and the error path print the same thing.
• Under set -u, initialise the variables the options fill in (here outdir=''), otherwise a missing option fails with unbound variable instead of your own message.

Direct answer. Build the detector on structural + historical signals, not pure syntax: feature envy shows up as a method that references another object's data/methods far more than its own; shotgun surgery shows up as a change to one concept requiring edits scattered across many files. Both are more reliably detected from CALL and CO-CHANGE patterns than from static structure alone.

Feature envy: signals to compute

• Data-access ratio: for each method, count field/method accesses on self versus on other objects' instances. A method that touches another class's internals 4x more than its own is a candidate.
• Call-graph locality: methods clustering their calls onto ONE foreign object repeatedly (not many different objects) strengthen the signal -- occasional cross-object calls are normal, a heavy skew toward one specific foreign object is the smell.

Shotgun surgery: signals to compute

• Co-change mining: from git history, find sets of files that are almost always modified together in the same commit/PR over a rolling window. A concept (e.g., 'add a new payment method') that historically requires touching 8+ files each time is shotgun surgery even if no single file looks obviously bad.
• Symbol fan-out: a renamed/changed identifier (a constant, an enum case) whose usages are scattered across many otherwise-unrelated modules, rather than centralized behind one seam.

False-positive risk and mitigation

• Feature envy: legitimate visitor/strategy patterns and thin adapters intentionally reach into another object's data as their whole job -- flag by a THRESHOLD and let a human confirm rather than auto-failing a build on this alone.
• Shotgun surgery: files that change together because of routine config/version bumps (a changelog, a version string) will look like co-change hotspots but aren't real coupling -- exclude known 'always touched' files (CHANGELOG, package manifests) from the co-change signal.
• Both signals are correlational, not causal; the tool's output should be a ranked list for a human to triage, not an automatic gate, because both smells require judgment about whether the coupling is INTENTIONAL (e.g., a deliberately thin façade) or accidental.

Trade-offs and pitfalls

• Co-change mining needs a long enough git history and a sensible commit-grouping window (single commits vs. whole PRs) or it will either miss real patterns (too short a window) or overcount unrelated batched commits (too long a window).
• Data-access-ratio detectors are language-dependent: dynamic languages make it harder to statically resolve which object a method call is 'really' targeting, so expect more false negatives there than in a strongly, statically typed codebase.
• Treat this as a triage aid for a human reviewer, not a merge-blocking gate -- both smells are judgment calls about design intent, and a false positive that blocks a legitimate PR erodes trust in the whole tool faster than an occasional missed real instance.