Networking Interview Questions for SRE and Backend Engineers: DNS, TCP, TLS, and Load Balancing

A customer says your API is down. DNS returns an address, the load balancer is green, and every backend looks healthy. From one region the request succeeds; from another it hangs before a single HTTP byte arrives.

This is what strong networking interview questions for SRE and backend engineers are designed to test. The interviewer is not looking for an OSI mnemonic. They want to see whether you can locate a failure across DNS, routing, TCP, TLS, load balancing, and the application without turning your answer into random commands.

Start with PracHub's real Site Reliability Engineer interview questions and Backend Engineer interview questions. Then use the eight production scenarios below to practice evidence-first answers aloud.

Networking interview questions for SRE and backend engineers covering DNS TCP TLS and load balancing

A production-minded answer follows the request path and identifies the first layer that breaks.

Quick Verdict

The best networking interview answers isolate the layer before proposing the fix. Start with user impact and scope, resolve the same hostname from the affected environment, test the actual destination and port, separate TCP from TLS and HTTP, then compare the load balancer's view with the backend's view.

A concise answer sounds like this: "I would compare a failing request with a working one, identify the first divergent layer, apply the smallest reversible mitigation, and verify recovery from the client side."

This guide focuses on application and production networking. For host-level CPU, memory, disk, and interface diagnosis, use the Linux troubleshooting interview guide. For SLOs, incidents, and reliability design, use the broader SRE Interview Guide 2026.

What the Interviewer Is Actually Scoring

Signal	Strong evidence	Weak answer
Layer isolation	Separates DNS, route, TCP, TLS, proxy, and application behavior	Says "the network is slow"
Scope	Compares client, region, IP, protocol, and time window	Assumes one failed request represents every user
Evidence	Explains what a lookup, handshake, capture, or proxy log would prove	Lists tools without changing the hypothesis
Operational judgment	Preserves evidence and chooses a reversible mitigation	Flushes caches or restarts proxies first
Prevention	Improves timeouts, health checks, observability, or rollout controls	Stops when the request works once

A 90-Second Network Troubleshooting Framework

Protect users and scope impact. Ask which clients, regions, protocols, endpoints, and release versions fail.
Resolve the exact name. Compare resolver, answer, record type, TTL, and IP with a healthy environment.
Test reachability and TCP. Use the real destination and port; distinguish timeout, reset, and successful handshake.
Inspect TLS and HTTP separately. Check certificate, SNI, ALPN, protocol version, response status, and timing.
Compare proxy and backend views. Correlate one request ID across the load balancer, connection pool, and application.
Mitigate, verify, and prevent. Shift traffic or remove a bad endpoint, confirm user recovery, then close the control gap.

Google's SRE troubleshooting guidance recommends describing the packet flow from a specific source to a specific destination, including transformations such as proxies or NAT and filters such as firewalls. That mental model is more useful than starting with a favorite command.

Network troubleshooting workflow from DNS through TCP TLS load balancing and verification

Move one layer at a time and keep a working request as your control.

The Fast Evidence Map

Stage	Evidence to collect	What it separates
DNS	Answer, resolver, TTL, A/AAAA, authoritative comparison	Stale data, split horizon, resolver or authority failure
Route	Source and destination IP, path, packet loss by hop	Regional path, firewall, NAT, or routing issue
TCP	SYN/SYN-ACK/RST, connect time, socket state	Drop, reject, listener, backlog, or port pressure
TLS	SNI, certificate chain, expiry, version, cipher, ALPN	Identity, trust, compatibility, or protocol negotiation
Load balancer	Endpoint health, selected backend, pool reuse, drain state	Bad subset, stale connection, or health-check mismatch
Application	Request ID, queue time, dependency timing, response code	Network symptom from backend or dependency failure

Eight production networking interview scenarios for SRE and backend engineers

The same visible error can begin at a different layer, so make the evidence choose the branch.

DNS Interview Scenarios

Scenario 1: Some Clients Still Resolve the Old IP After a Failover

Compare the answer from the affected client's configured resolver with a known recursive resolver and the authoritative servers. Check A and AAAA records, CNAME chains, TTL remaining, local or application caches, and whether internal and external DNS intentionally return different answers.

DNS is a distributed, cached database. RFC 1034 explicitly frames caching as a trade-off between lookup cost, update speed, and cache accuracy. Lowering the TTL after the failover does not invalidate records already cached under the old TTL.

Safe mitigation: keep the old endpoint serving, restore dual service, or route both addresses while caches expire. For a planned migration, lower TTLs before the change and verify which layer actually honors them.

Scenario 2: One Region Sees Slow DNS and Intermittent SERVFAIL

Run the lookup from the affected runtime, not your laptop. Compare query time, resolver IP, UDP and TCP behavior, authority reachability, DNSSEC validation, and resolver error metrics. A trace can show where delegation stops, but resolver logs tell you whether the failure was timeout, refusal, validation, or bad delegation.

Be aware that failures can outlive the original incident through caching. RFC 9520 requires resolvers to cache DNS resolution failures for a bounded period to prevent aggressive retries.

Mitigation: move the affected clients to a healthy resolver or restore an authoritative path. Verify with uncached and cached names, then monitor latency, SERVFAIL rate, and authority reachability.

TCP Interview Scenarios

Scenario 3: One Client Times Out, While Another Gets Connection Refused

A timeout and an immediate refusal are different branches. A timeout often means the SYN or response is being dropped or lost; an immediate reset often means the destination is reachable but nothing accepts that socket, or a device actively rejects it.

Confirm the resolved IP and route, then capture the handshake from both sides when possible. Check listener state, security rules, network policy, NAT translation, connection backlog, and whether IPv4 and IPv6 take different paths. RFC 9293 defines the TCP state transitions and the retransmission behavior that make these observations meaningful.

Strong answer: name the expected packet sequence and say how each missing or reset packet changes the next hypothesis.

Scenario 4: p99 Latency Rises While CPU and Request Rate Stay Flat

Break latency into DNS, connect, TLS, time to first byte, and transfer time. If connect or transfer time rises, compare RTT, retransmissions, receive windows, path changes, packet loss, and MTU behavior between healthy and unhealthy traffic.

A simultaneous packet capture at both endpoints can separate loss before the server, loss on the return path, and application delay after delivery. During impact, shift traffic away from the bad path or zone; afterward, add phase-level latency and retransmission telemetry so the next alert is more specific than "API slow."

Scenario 5: A Proxy Has Thousands of TIME_WAIT Sockets and New Connections Fail

TIME_WAIT is normal TCP behavior, not a root cause by itself. The active closer retains state so delayed packets from an old connection cannot corrupt a new one. The useful question is whether connection churn is exhausting ephemeral ports or a NAT/proxy connection table.

Correlate socket states with failed connects, source-port range, destination fan-out, connection reuse, pool size, idle timeout, and who closes first. Prefer persistent connections and bounded pools before changing kernel timers. Tuning away a symptom can create harder-to-debug connection reuse failures.

TLS and Load Balancing Scenarios

Scenario 6: TLS Fails for One Hostname or Client Version

Test the same IP while sending the expected hostname. Check certificate expiry and hostname coverage, intermediate chain, trust store, client clock, TLS versions and ciphers, SNI routing, and ALPN negotiation. A successful TCP connect proves only that the transport opened.

SNI lets the server choose a certificate or policy from the requested server name, while ALPN negotiates the application protocol inside the TLS handshake. That is why the same address can work for one hostname or HTTP version and fail for another.

Safe mitigation: restore the correct certificate or routing configuration, or route clients to a compatible listener. Do not disable certificate verification to make the test pass.

Scenario 7: The Load Balancer Is Green, but Users Receive 503s

Ask what "healthy" actually proves. A TCP health check can pass while the application is overloaded, missing a dependency, or unable to serve the tested route. Compare health-check traffic with a real request, inspect the selected backend, and test each endpoint directly.

Also inspect endpoint discovery, readiness, outlier detection, retry behavior, and connection pools after a rollout or scale-down. Envoy's health-checking documentation notes that a successful health-check URL does not necessarily prove the host is valid for the intended service.

Mitigation: remove or drain the failing subset, use a health check that represents serving readiness, and verify recovery through the load balancer rather than only against one backend.

Scenario 8: One Backend Is Hot While Its Peers Are Idle

Break utilization down by selected endpoint, connection count, request count, latency, zone, and tenant. Round-robin requests may still produce uneven work when connections are long-lived, requests vary in cost, sessions are sticky, or one endpoint is slower.

Choose the balancing policy around the workload: least-request for uneven request duration, weighted policies for unequal capacity, and deliberate hashing only when affinity is required. Then ask whether state can move out of the backend so traffic can be redistributed safely.

How the Bar Changes by Role

SRE candidates should emphasize blast radius, black-box signals, packet-path evidence, traffic shifting, safe rollback, and prevention. Backend candidates should go deeper on client pools, connection reuse, timeout budgets, retries, idempotency, proxy behavior, and dependency latency.

Senior candidates in either role should explain ownership boundaries without using them as an excuse. You may not control the network or load balancer, but you should know what evidence lets the responsible team act quickly.

Common Mistakes That Cost Candidates the Round

Treating ping as proof. ICMP success or failure does not establish that the application port, TLS handshake, or HTTP path works.
Flushing caches immediately. This destroys evidence and may add load without fixing the authority or resolver.
Assuming every 503 means the same thing. Status and reset semantics vary by proxy; inspect that implementation's logs.
Adding retries without a budget. Retries can multiply load and extend an incident when the dependency is already failing.
Stopping at the first healthy backend. Intermittent failures often live in one endpoint, zone, address family, or connection pool.

A 5-Day Networking Interview Practice Plan

Day	Focus	Practice output
1	DNS resolution, TTLs, and regional failures	Two three-minute diagnosis answers
2	TCP handshake, timeout, reset, and TIME_WAIT	Explain each packet branch without notes
3	TLS certificates, SNI, ALPN, and timing	One client-specific failure walkthrough
4	Health checks, pools, draining, and balancing	Diagnose a green load balancer returning errors
5	Mixed production mock	Scope, evidence, mitigation, verification, prevention

Networking Interview FAQ

What networking topics matter most for SRE interviews?

Prioritize DNS resolution and caching, IP routing and NAT, TCP states and retransmissions, TLS certificates and negotiation, HTTP timing, load-balancer health and connection pools, packet capture, and production mitigation. Learn how the layers interact under failure.

How much networking should a backend engineer know?

You do not need to configure enterprise routers for most backend roles. You should be able to trace a request, reason about TCP and TLS failures, set timeouts and retries, design connection pools, understand proxies and load balancers, and produce evidence when another team owns the failing layer.

Should I memorize networking ports and OSI layers?

Know common protocols and enough layering to structure an investigation, but do not make memorization the center of your preparation. Interviews become more revealing when the prompt changes one condition and asks what you would measure next.

How should I practice networking troubleshooting questions?

Answer aloud with a working and failing request side by side. State the layer you are testing, the evidence you expect, how each result changes your hypothesis, the safest mitigation, and the client-side signal that confirms recovery.

Final Takeaway

A strong networking answer turns "the service is down" into a controlled comparison across DNS, route, TCP, TLS, load balancing, and the backend. It finds the first broken contract, restores service with minimal risk, and leaves the system easier to diagnose next time.

Use PracHub's real SRE interview questions and written solutions, browse Backend Engineer interview questions, and use company-specific interview prep to practice the depth your target loop actually requires.