Networking interview questions & answers
HTTP, DNS, TCP and request troubleshooting. Practice clear explanations, realistic scenarios and follow-up questions for interviews.
Official reference: MDN: HTTP
8 Networking interview questions study by subtopic
1.What happens when you open an HTTPS URL?mid
The browser checks relevant caches and resolves the hostname through DNS if needed. It establishes a connection and negotiates TLS to authenticate the server and protect traffic. It sends an HTTP request, receives a response, and parses the document and its resources. Connection reuse, caching and the HTTP version can change the exact sequence. I would separate DNS, connection, server and rendering time when investigating a slow page.
What interviewers listen for- DNS resolves the hostname
- TLS protects traffic
- HTTP exchanges requests and responses
- Caching and connection reuse affect timing
Likely follow-up: How would you identify whether the delay is DNS or the server?
2.How do TCP and UDP differ?mid
TCP provides an ordered byte stream with retransmission and flow control. Applications still need message framing and application-level error handling. UDP sends datagrams without guaranteeing delivery or order. It can suit latency-sensitive traffic where the application handles loss, but it is not automatically faster in every workload. Protocols built on UDP can add reliability: QUIC is an example. I would choose based on delivery requirements and the protocol ecosystem.
What interviewers listen for- TCP provides ordered reliable transport
- UDP preserves datagram boundaries
- Applications still handle failures
- Choose based on requirements
Likely follow-up: Why might a real-time application tolerate some packet loss?
3.How do you safely retry a request after a timeout?hard
A timeout does not prove the server did nothing. First determine whether the operation is safe to repeat. For a payment or order creation, use an idempotency key and have the server store or recover the result for that key. Limit attempts, apply exponential backoff with jitter and honor retry guidance where available. Retry transient failures rather than every error, and set an overall deadline so retries do not amplify an outage.
What interviewers listen for- Timeouts have ambiguous outcomes
- Use idempotency for side effects
- Bound retries with backoff and jitter
- Respect an overall deadline
Likely follow-up: What happens if two requests with the same key arrive together?
4.How do latency and bandwidth affect application performance?easy
Latency is the time required for an interaction or transfer step; bandwidth is the available data transfer rate. A small API response can be slow because of several sequential network round trips even when bandwidth is high. A large download may instead be limited by throughput. I would measure request timing and payload size, then reduce unnecessary round trips, compress suitable payloads or cache data according to the actual bottleneck.
What interviewers listen for- Distinguish delay from transfer rate
- Sequential round trips accumulate delay
- Large transfers can be throughput-limited
- Measure before optimizing
Likely follow-up: Why might batching requests help on a high-latency connection?
5.How would you distribute traffic across several API servers?mid
Put a load balancer in front of healthy instances and choose a policy such as round robin or least connections based on workload. Configure health checks that reflect whether an instance can serve traffic and drain connections during removal. Keep application session state external or deliberately handle affinity. I would monitor latency, errors and instance load because equal request counts do not necessarily mean equal work. The balancer itself also needs an availability strategy.
What interviewers listen for- Route only to healthy instances
- Choose a policy for the workload
- Plan session state and connection draining
- Monitor and avoid a single point of failure
Likely follow-up: How would long-lived connections affect balancing?
6.Why can users temporarily reach different servers after a DNS change?mid
Resolvers and clients may still hold cached records from before the change. Records have a time to live, so changing an authoritative answer does not immediately invalidate every cached copy. Different users can consult different resolvers at different times. Before a migration, lower the relevant TTL sufficiently in advance and keep the old destination working during the transition. Diagnose by comparing answers from authoritative servers and the resolvers that affected clients use.
What interviewers listen for- DNS answers are cached at multiple layers
- TTL affects cache lifetime
- Authoritative changes do not instantly invalidate caches
- Keep migration overlap and inspect resolver answers
Likely follow-up: Why does lowering the TTL at the moment of cutover not clear old caches?
7.When would you choose WebSockets rather than HTTP polling?mid
WebSockets suit frequent bidirectional communication such as interactive collaboration. Polling is often simpler when updates are infrequent and a little delay is acceptable. I would compare update frequency, infrastructure support and operational complexity before choosing. A WebSocket design needs authentication, reconnect behavior, heartbeats and backpressure. Reconnection alone does not recover missed events, so important updates need a sequence or resynchronization strategy. Long-lived connections also affect deployment and load balancing.
What interviewers listen for- Match transport to interaction needs
- Polling can be simpler
- Plan connection lifecycle and backpressure
- Recover missed events after reconnect
Likely follow-up: How would a client detect that it missed updates?
8.How would you investigate intermittent 502 and 504 responses?hard
First identify which proxy generated the response and correlate its logs with backend request identifiers. A 502 generally indicates an invalid upstream response, while a 504 indicates an upstream timeout. Check target health, connection failures, resets, saturation and the timeout budgets of each hop. Compare failing and healthy requests and recent deployments. Increasing a timeout may hide overload, so measure queueing and service time before changing limits. Retry only when the operation is safe to repeat.
What interviewers listen for- Identify the failing hop
- Distinguish bad upstream responses from timeouts
- Correlate logs and resource pressure
- Treat timeout changes and retries carefully
Likely follow-up: What happens when a client timeout is shorter than the backend timeout?
No questions match that filter.
Prefer multiple choice? All 11 Networking MCQs with answers →