---
title: Computer Networks Interview Questions & Answers (2026)
description: The computer networks interview questions that get asked in 2026 — OSI vs TCP/IP, TCP vs UDP, DNS, HTTP, subnetting, and what happens when you type a URL — with worked answers.
url: https://usegreenroom.app/blog/computer-networks-interview-questions
last_updated: 2026-06-20
---

← Back to blog

Technical

# Computer networks interview questions and answers

June 20, 2026 · 35 min read

![Computer networks interview questions and answers — cover from Greenroom, the AI mock interviewer](/assets/blog/computer-networks-interview-questions-hero.webp)

You're on a shared Zoom whiteboard, twelve minutes into a placement interview at a mid-size product company in Pune, and the interviewer types one instruction into the chat: "Draw the OSI model. All seven layers." You pick up the mouse-as-pen tool, which draws like you're holding a crayon with oven mitts on, and you start strong. Physical. Data Link. Network. Transport. You write "Transport" and then your hand just... stops. Not your hand — your brain. You know there's a layer here that does something with sessions, and another one that does something with presentation, but in what order, and which one is layer 5, and which one is layer 6, and does it even matter, and why is the interviewer's cursor just sitting there blinking next to your half-finished diagram like a tiny digital judge.

You write "Session" where "Transport" should still be getting room to breathe, scribble it out, and now your OSI model looks less like a reference architecture and more like a crime scene. The interviewer, mercifully, says "take your time" — which is the most terrifying sentence in the English language when you are actively losing a fight with a seven-layer mnemonic you learned for a semester exam two years ago and never thought about again.

This is **the computer networks interview** in miniature: a small set of layered, interlocking concepts that are genuinely not hard, individually, but that fall apart in your head the second someone asks you to produce them live, in order, under a blinking cursor. Computer networks is a staple CS subject in campus placements, and it resurfaces constantly in backend, DevOps, SRE, and systems interviews, because — unlike, say, a sorting algorithm you'll never personally implement at work — networking concepts are things working engineers actually debug on a Tuesday afternoon when an API call mysteriously times out. This guide covers the **computer networks interview questions** that actually get asked, with the kind of worked, layer-by-layer detail that holds up when an interviewer pushes back, not just enough to recognize the right answer on a flashcard.

## Why this subject keeps showing up in interviews

Three reasons, and they compound. First, networking is *load-bearing* — it underlies literally every distributed system, every API call, every "why is prod slow" incident, so interviewers treat it as a proxy for whether you understand what's actually happening when your code talks to another machine. Second, it's *layered and narratable* — unlike some CS topics that are a pile of disconnected facts, networking has one continuous story (the OSI/TCP-IP stack, or the URL-to-render walkthrough) that lets an interviewer test breadth and depth with a single open-ended question and follow-ups. Third, and most practically, it's *cheap to ask* — no whiteboard coding required, no IDE, just a conversation, which is exactly why it shows up in nearly every Indian campus placement loop (TCS, Infosys, Capgemini, Wipro, product company campus drives) and in early technical screens at startups that don't want to burn a full hour on LeetCode for a junior role.

The catch is that "cheap to ask" does not mean "easy to answer well." A question like "what happens when you type a URL and press enter" has no single correct sentence — it has a correct *shape*, and the interviewer is listening for whether you can walk that shape in order, under follow-ups, without getting lost the way you got lost drawing OSI layer 5 on that shared whiteboard. That's the actual skill being tested, and it's a verbal skill, not a memorization skill — which matters a lot for how you should practice, a point we'll come back to.

## The OSI model — seven layers, with what each one actually does

The **OSI model** (Open Systems Interconnection) is a conceptual, seven-layer reference model for how data moves from one device to another across a network. Nobody implements networking software in strict OSI layers in practice — real-world stacks blur boundaries — but it's the shared vocabulary interviewers use to organize every other networking question, so getting it solid is non-negotiable. Layer numbers run bottom-up, physical (1) to application (7), and the most common mnemonic is "Please Do Not Throw Sausage Pizza Away."

### Layer 1 — Physical

The physical layer is the actual hardware: cables, voltages, radio frequencies, the literal bits as electrical or optical signals. It defines things like cable types (Ethernet copper vs fiber), connector pinouts, and bit-rate. A concrete example: when your laptop's Ethernet port lights up green and starts blinking, that's the physical layer negotiating a link — no concept of "data" yet, just raw signal.

### Layer 2 — Data Link

The data link layer packages raw bits into **frames** and handles node-to-node delivery on the same local network, using **MAC addresses** to identify devices. It also does error detection (via checksums/CRC) for frames damaged in transit, and it's the layer where **switches** operate — a switch reads the destination MAC address in a frame and forwards it only to the correct port, instead of broadcasting to every device like a hub would. Concrete example: your laptop and the office printer, both on the same office LAN, talk to each other at this layer using MAC addresses, with zero awareness of IP addresses or the wider internet.

### Layer 3 — Network

The network layer is where **IP addresses** and **routing** live — it's responsible for moving packets across *different* networks, not just within one. This is the layer **routers** operate at: a router looks at the destination IP address in a packet and decides which next-hop network to forward it toward, potentially across dozens of hops to reach a server on the other side of the world. Concrete example: when a packet leaves your home network and crosses your ISP's backbone toward a US-hosted server, every router along that path is making layer-3 forwarding decisions.

### Layer 4 — Transport

The transport layer provides end-to-end communication between processes (not just devices) using **ports**, and this is where **TCP** and **UDP** live — the layer most candidates forget to mention by name when they freeze on that whiteboard. TCP adds reliability, ordering, and flow control on top of IP's "best effort" delivery; UDP just sends packets with no guarantees. Concrete example: your browser opening a TCP connection to port 443 on a web server is a transport-layer event — IP got the packets to the right *machine*, but it's TCP that ensures they arrive at the right *process*, in order, without loss.

### Layer 5 — Session

The session layer manages and maintains connections — opening, coordinating, and closing a session between two applications, including checkpointing for resuming interrupted transfers. In practice, most modern application protocols fold session management into themselves (HTTP cookies/sessions, TLS session resumption) rather than relying on a distinct OSI session-layer protocol, which is exactly why this layer is the one candidates blank on — it's real conceptually, but you rarely name a standalone "session layer protocol" the way you'd name TCP or HTTP. Concrete example: a video call maintaining one continuous logical session even as the underlying connection occasionally drops and reconnects.

### Layer 6 — Presentation

The presentation layer translates data between the format the application needs and the format suitable for network transmission — encryption, compression, and character encoding live conceptually here. Concrete example: SSL/TLS encryption and JPEG/MPEG encoding are presentation-layer concerns, even though in real stacks TLS is usually described as sitting "between" transport and application rather than as a pure OSI layer-6 citizen.

### Layer 7 — Application

The application layer is what users and applications directly interact with — **HTTP, FTP, SMTP, DNS** all live here. This is the layer your browser, email client, and curl command actually speak. Concrete example: when your browser sends a `GET /index.html` request, that's an application-layer message, even though by the time it physically leaves your machine it's been wrapped by every layer below it.

<div class="verdict"><strong>The core truth:</strong> interviewers rarely just want the seven names. They want you to map a real, everyday action — a Zoom call, a file download, a DNS lookup — onto a specific layer, on the spot, which is exactly the skill that drawing-from-memory practice doesn't build.</div>

## OSI vs TCP/IP model — what's actually different

The other near-guaranteed question is **OSI vs TCP/IP**, and the honest answer is that they're not really competing implementations of the same idea — OSI is a *conceptual, seven-layer teaching model* that was designed before the internet as we know it existed, while **TCP/IP** is the practical, four-layer model that the actual internet runs on. TCP/IP's four layers — Network Access (sometimes split into Link), Internet, Transport, Application — collapse OSI's top three layers (session, presentation, application) into one single Application layer, because in practice nobody builds separate protocols for "session" and "presentation" the way OSI imagined; HTTP and TLS just absorb those concerns directly.

| | OSI | TCP/IP |
|---|---|---|
| Layers | 7 | 4 (sometimes described as 5) |
| Origin | ISO standard, theoretical/teaching model | Grew organically from ARPANET, what's actually deployed |
| Top layers | Session, Presentation, Application — separate | Collapsed into one Application layer |
| Used for | Vocabulary, teaching, troubleshooting framework | The actual protocol suite the internet runs on |

The follow-up interviewers love here: "if TCP/IP is what's actually used, why do we still teach OSI?" The honest answer is that OSI's granularity is genuinely useful as a *debugging framework* — when something breaks, "is this a layer 2 problem (wrong MAC/ARP issue), a layer 3 problem (routing), or a layer 4 problem (port blocked, TCP handshake failing)?" is a more precise diagnostic question than TCP/IP's coarser four buckets give you. You use TCP/IP to build things and OSI to talk about and troubleshoot them — that one sentence usually satisfies the follow-up.

## TCP vs UDP — reliability, ordering, and when to use each

**TCP (Transmission Control Protocol)** and **UDP (User Datagram Protocol)** are the two dominant transport-layer protocols, and the contrast between them is maybe the single most-asked pair in any networking interview, because it's a clean way to test whether you understand *trade-offs*, not just facts.

**TCP is connection-oriented and reliable.** Before any data moves, TCP performs a three-way handshake (more below) to establish a connection. Once established, TCP guarantees: ordered delivery (packets are sequenced and reassembled in the right order even if they arrive out of order), reliable delivery (lost packets are detected via acknowledgments and retransmitted), and flow/congestion control (the sender backs off if the receiver or network is overwhelmed). The cost of all this reliability is overhead and latency — handshakes, acknowledgments, and retransmission all take time. Real protocols built on TCP: HTTP/HTTPS (web pages), SMTP/IMAP (email), FTP (file transfer) — anywhere correctness matters more than raw speed.

**UDP is connectionless and "fire and forget."** No handshake, no acknowledgment, no retransmission, no guaranteed ordering — a UDP packet (called a datagram) is sent and the sender moves on, trusting nothing. This sounds reckless until you realize that for some use cases, a slightly-lost or out-of-order packet is *less* bad than the delay TCP's reliability mechanisms would introduce. Real protocols built on UDP: DNS (a single quick query/response, retried at the application level if needed), video/audio streaming and VoIP (a dropped frame is fine, a half-second stall to retransmit it is not), online gaming (the same logic — stale data is worse than missing data), and DHCP.

The interview-killer follow-up: "DNS mostly uses UDP — why would a *reliability-conscious* protocol like DNS choose an *unreliable* transport?" The answer: DNS queries are small, idempotent, and cheap to simply retry from the application layer if no response arrives — paying TCP's handshake overhead for every single lookup would make DNS noticeably slower for something users expect to be instant. (DNS does fall back to TCP for responses too large for a single UDP datagram, and for zone transfers — a detail worth mentioning to show you know the exception, not just the rule.)

## The TCP three-way handshake (and the four-way close)

Before any data flows over TCP, the two sides perform a **three-way handshake** to establish the connection and agree on initial sequence numbers:

1. **SYN** — the client sends a SYN (synchronize) packet to the server with an initial sequence number, essentially saying "I want to connect, here's where my sequence numbering starts."
2. **SYN-ACK** — the server responds with its own SYN (its own initial sequence number) combined with an ACK acknowledging the client's SYN, saying "got it, here's where my sequence numbering starts, and yes let's connect."
3. **ACK** — the client sends a final ACK acknowledging the server's SYN, and the connection is now established. Data can flow.

```
Client                         Server
  | ------- SYN (seq=x) ------> |
  | <--- SYN-ACK (seq=y,ack=x+1)|
  | ------- ACK (ack=y+1) -----> |
  |       connection established |
```

The handshake exists specifically so both sides confirm bidirectional reachability and agree on sequence numbers *before* committing any real data — sending data blind, without this negotiation, is exactly the kind of thing that would make TCP's reliability guarantees impossible to deliver.

Closing a TCP connection is a separate, less-often-remembered question: it's a **four-way close** (sometimes shown as a FIN/ACK exchange in each direction), because TCP connections are full-duplex — each side has to independently signal "I'm done sending" with a FIN, and have it acknowledged, since one side might still have data left to send even after the other side is finished. This asymmetry is also the reason the `TIME_WAIT` state exists on whichever side closes first — it's a real, occasionally interview-relevant detail when discussing why a server under heavy connection churn can run out of available ports.

A genuinely good scenario follow-up here: "what's a SYN flood attack?" — an attacker sends a flood of SYN packets without ever completing the handshake with the final ACK, leaving the server holding open a pile of half-open connections waiting for an ACK that never comes, exhausting its connection table. It's a direct, mechanical abuse of the exact three steps above, which is why interviewers like asking it right after the handshake question — it tests whether you understood the mechanism or just memorized the three letters.

## The IP layer — IPv4 vs IPv6, and a real subnetting walkthrough

The **IP (Internet Protocol)** layer is responsible for addressing and routing packets across networks. **IPv4** addresses are 32-bit, written as four decimal octets (e.g., `192.168.1.10`), giving roughly 4.3 billion possible addresses — a number that sounded enormous in 1981 and has been effectively exhausted for years, which is the entire reason **IPv6** exists. IPv6 addresses are 128-bit, written as eight groups of hexadecimal digits (e.g., `2001:0db8:85a3:0000:0000:8a2e:0370:7334`), providing an address space so large (about 340 undecillion addresses) that "running out" stops being a realistic concern. IPv6 also drops the need for NAT in many designs (every device can get a real public address again), simplifies header processing for routers, and has built-in support for auto-configuration — but adoption has been slow because IPv4 and IPv6 aren't directly interoperable, requiring dual-stack support or translation layers during the (decades-long) transition.

### Subnetting and CIDR — a worked example

**Subnetting** splits a larger network into smaller sub-networks, mainly to control broadcast domain size and organize address allocation logically (e.g., separate subnets per office floor or per environment — prod, staging, dev). **CIDR notation** (Classless Inter-Domain Routing, e.g., `/24`) replaced the old class-based A/B/C system by letting you specify exactly how many bits of an address are the network portion versus the host portion.

Worked example, because this is the question where "I understand the concept" and "I can actually do it" diverge fast: you're given the network `192.168.1.0/24` and asked to split it into 4 equal subnets.

- `/24` means the first 24 bits are the network portion, leaving 8 bits (the last octet) for hosts — that's 256 addresses (`2^8`), giving 254 usable host addresses per subnet once you subtract the network address and broadcast address.
- To split into 4 subnets, you need 2 more bits borrowed from the host portion (`2^2 = 4`), making each subnet a `/26` (24 + 2 = 26).
- A `/26` leaves 6 host bits, so `2^6 = 64` addresses per subnet, 62 usable.
- The four subnets, walking the last octet in steps of 64: `192.168.1.0/26` (range .0–.63, broadcast .63), `192.168.1.64/26` (.64–.127, broadcast .127), `192.168.1.128/26` (.128–.191, broadcast .191), `192.168.1.192/26` (.192–.255, broadcast .255).

Each subnet's usable host range excludes its first address (network address) and last address (broadcast address) — so `192.168.1.0/26`'s usable range is actually `.1` through `.62`. This exact kind of "here's a network, give me N subnets, what's the new mask and the ranges" question is a near-universal networking-round staple precisely because you can't fake your way through it without actually doing the binary arithmetic — which makes it one of the highest-signal, lowest-ambiguity questions in the whole subject.

## DNS resolution — step by step

**DNS (Domain Name System)** translates human-readable domain names (`usegreenroom.app`) into IP addresses computers actually route by. The full resolution path, the version interviewers want when they say "walk me through DNS resolution," goes:

1. **Browser/OS cache check** — your browser and OS first check their local DNS cache; if the domain was resolved recently, this returns instantly with no network round-trip at all.
2. **Recursive resolver** — if not cached, the query goes to a **recursive resolver** (often your ISP's, or a public one like 8.8.8.8 / 1.1.1.1), which does the actual legwork on your behalf and caches the result for other users.
3. **Root server** — the recursive resolver queries one of the 13 logical **root nameservers**, which doesn't know the answer but knows which **TLD (top-level domain)** server handles `.app` (or `.com`, `.in`, etc.) and redirects there.
4. **TLD server** — the TLD server for `.app` doesn't know the final IP either, but it knows which **authoritative nameserver** is responsible for `usegreenroom.app` specifically, and redirects there.
5. **Authoritative nameserver** — this server actually holds the DNS records for the domain and returns the real answer — typically an **A record** (IPv4 address) or **AAAA record** (IPv6 address).
6. **Resolver returns and caches** — the recursive resolver passes the IP back to your browser and caches it for the record's **TTL (time to live)**, so the next lookup (by you or anyone else using that resolver) skips straight to a cache hit.

This whole chain typically completes in tens of milliseconds and is invisible to users — until it isn't, which is exactly why "DNS resolution, slowly, on purpose" is also a debugging scenario interviewers like to ask (more on that below). Cloudflare's Learning Center has a genuinely good visual walkthrough of this exact chain if you want a second explanation to triangulate against your own mental model.

## HTTP vs HTTPS, and the TLS handshake

**HTTP (HyperText Transfer Protocol)** is the application-layer protocol browsers and servers use to exchange requests and responses — it's plaintext by default, meaning anyone intercepting the traffic (a malicious WiFi hotspot, an ISP, a man-in-the-middle) can read or tamper with it. **HTTPS** is HTTP layered over **TLS (Transport Layer Security)**, which encrypts the connection, verifies the server's identity via a certificate, and protects against tampering — it's the difference between mailing a postcard and mailing a sealed, tamper-evident envelope.

The **TLS handshake** (simplified, for TLS 1.2/1.3 conceptually) runs roughly:

1. **ClientHello** — the client sends supported TLS versions and cipher suites.
2. **ServerHello + certificate** — the server responds with its chosen cipher suite and its **SSL/TLS certificate**, which contains its public key and is signed by a trusted **Certificate Authority (CA)**.
3. **Certificate validation** — the client verifies the certificate's signature chain against trusted root CAs it already has, confirming the server is who it claims to be (this is what stops a malicious server from just presenting its own fake certificate).
4. **Key exchange** — client and server derive a shared **session key** (using asymmetric crypto just for this negotiation, since asymmetric crypto is too slow for bulk data).
5. **Symmetric encryption begins** — from here on, the much faster symmetric session key encrypts all actual HTTP traffic for the rest of the connection.

The follow-up worth being ready for: "why not just use asymmetric (public/private key) encryption for the whole connection, since it's already there?" — asymmetric crypto is computationally far more expensive than symmetric crypto, so TLS uses it only briefly, to safely establish a shared symmetric key, then switches to the cheap, fast symmetric algorithm for the actual bulk data transfer. That hybrid design is the entire point of the handshake, and articulating *why* (not just *that*) is what separates a memorized answer from an understood one. MDN's documentation on HTTPS and the TLS handshake is the standard reference if you want to read the RFC-adjacent detail beyond what an interview needs.

## HTTP methods and status codes

A quick-fire but common pairing: **GET** retrieves a resource (should be safe/idempotent — no side effects from repeating it), **POST** creates a resource (not idempotent — repeating it can create duplicates), **PUT** replaces a resource entirely (idempotent — repeating it gives the same end state), **PATCH** partially updates a resource, and **DELETE** removes one. We cover the full REST contract, idempotency nuances, and worked examples in our [REST API interview guide](/blog/rest-api-interview-questions) — worth pairing with this one since the two rounds frequently overlap.

Status codes, the ones that actually come up: `200 OK` (success), `201 Created` (successful POST), `301`/`302` (permanent/temporary redirect), `304 Not Modified` (cached response is still valid — a caching-specific code interviewers like because it tests whether you understand conditional requests, not just the code list), `400 Bad Request` (malformed client request), `401 Unauthorized` (missing/invalid auth), `403 Forbidden` (authenticated but not permitted), `404 Not Found`, `429 Too Many Requests` (rate limiting), `500 Internal Server Error`, `502 Bad Gateway` (upstream server failed to respond properly — a classic load-balancer/reverse-proxy symptom), `503 Service Unavailable` (server overloaded or down for maintenance), and `504 Gateway Timeout` (upstream took too long). Knowing 502 vs 503 vs 504 specifically, and what infrastructure layer each one implicates, is a small but real signal of production experience versus textbook memorization.

## Sockets and ports

A **socket** is the combination of an IP address and a port number, representing one endpoint of a two-way network connection — it's the actual abstraction your operating system gives applications to send/receive data over a network, identified uniquely by the tuple (source IP, source port, destination IP, destination port, protocol). A **port** is a 16-bit number (0–65535) that lets a single IP address host multiple simultaneous network services or connections — your machine has one IP but can run a web server on port 80, an SSH daemon on port 22, and a database on port 5432, all distinguishable by port number alone. Well-known ports worth having memorized cold: 20/21 (FTP), 22 (SSH), 25 (SMTP), 53 (DNS), 80 (HTTP), 443 (HTTPS), 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB). A genuinely good interview moment is being asked "can two processes on the same machine listen on the same port?" — no, not for the same protocol and interface; the OS will refuse to bind a second listener to an already-bound (IP, port, protocol) combination, which is exactly why you get "address already in use" errors restarting a server too quickly after killing it.

## The classic question: what happens when you type a URL and press enter?

This is the single most-asked open-ended networking question, precisely because it forces you to narrate every concept above, in order, as one continuous story instead of as isolated facts. A strong, complete answer:

1. **Browser cache check.** The browser checks if it already has a cached, unexpired DNS resolution and/or a cached copy of the resource (via HTTP cache headers) — if so, it may skip straight to rendering with zero network calls.
2. **DNS resolution.** If not cached, the browser resolves the domain to an IP address via the full DNS chain described above (recursive resolver → root → TLD → authoritative).
3. **TCP connection.** The browser opens a TCP connection to the server's IP on port 443 (or 80 for plain HTTP), completing the three-way handshake.
4. **TLS handshake** (for HTTPS). Certificate exchange, validation, and symmetric key negotiation as described above — this happens before any HTTP data is sent.
5. **HTTP request.** The browser sends an HTTP request (`GET / HTTP/1.1`, with headers — `Host`, `User-Agent`, cookies, `Accept-Encoding`, etc.) over the now-secure connection.
6. **Server processing.** The request may hit a load balancer first, which routes it to one of several backend servers; that server's application code runs, possibly querying a database, and constructs a response.
7. **HTTP response.** The server returns a status code, headers, and a body (typically HTML for the initial request).
8. **Browser parsing and rendering.** The browser parses the HTML, builds the DOM, discovers references to additional resources (CSS, JS, images, fonts), and fires off additional requests for each — often in parallel, each potentially needing its own DNS lookup and TCP/TLS handshake if hosted on a different domain (a CDN, for instance).
9. **Render and paint.** CSS is applied, the render tree is built, JavaScript executes (potentially blocking or deferred, per the `<script>` tag's attributes), and the page becomes visible and interactive.

Being able to narrate this end to end, smoothly, while fielding interruptions ("wait, what's actually inside that TLS handshake you just glossed over" or "what if the load balancer's health check just failed on that backend") is the actual skill being tested — and it's exactly the skill that silently reading this list does not build, because reading lets you nod along with each step without ever having to produce the next one yourself, out loud, with no script in front of you.

## Routers, switches, and hubs

A quick, frequently-confused trio, and the one that famously trips people up live on calls (yes, including the occasional engineer who should know better): a **hub** is a dumb, layer-1 device that simply repeats every incoming signal out to all other ports — no addressing logic at all, which means it creates one big collision domain and is essentially obsolete in modern networks. A **switch** operates at layer 2, reads the destination MAC address of each incoming frame, and forwards it only to the specific port that device is connected to, using a MAC address table it builds by observation — this means devices on a switch don't see each other's traffic, unlike on a hub. A **router** operates at layer 3, connects *different* networks together (e.g., your home LAN to your ISP's network, or two corporate subnets to each other), and makes forwarding decisions based on destination IP address and routing tables, often using protocols like OSPF or BGP to learn the best path. The one-line distinction interviewers want: a switch connects devices *within* a network; a router connects *different* networks *together*.

## NAT, firewalls, and load balancers

**NAT (Network Address Translation)** lets multiple devices on a private network (each with a private IP like `192.168.x.x`) share a single public IP address when talking to the internet — your home router rewrites outgoing packets' source IP/port to its own public IP and a unique port, tracks the mapping in a table, and rewrites incoming responses back to the right internal device. NAT is also why most home networks aren't directly reachable from the internet without explicit port forwarding — it's an incidental security benefit on top of its real purpose, which was conserving scarce IPv4 addresses.

A **firewall** inspects and filters network traffic based on rules — allow/deny by IP, port, protocol (a basic packet-filtering firewall), or with deeper awareness of connection state (a stateful firewall, which tracks whether a packet belongs to an already-established, legitimate connection) or even application content (a next-gen/application-layer firewall). Interview-relevant nuance: a stateful firewall can allow a response packet back in without an explicit rule for it, because it recognizes the response as belonging to a connection it already approved outbound — a stateless firewall can't make that distinction and needs explicit rules for both directions.

A **load balancer** distributes incoming traffic across multiple backend servers, which is what makes horizontal scaling and high availability possible — if one backend dies, the load balancer's health checks detect it and stop routing traffic there. Common algorithms: round-robin (rotate evenly), least-connections (send to whichever backend currently has the fewest active connections), and IP-hash (route the same client consistently to the same backend, useful for session affinity). Load balancers can operate at layer 4 (routing based on IP/port alone, faster, protocol-agnostic) or layer 7 (routing based on actual HTTP content — URL path, headers, cookies — slower but far more flexible, e.g., routing `/api/*` to one service and `/static/*` to another).

## Latency vs bandwidth vs throughput

Three terms candidates routinely conflate, and interviewers know it, which is exactly why this trio shows up so often: **latency** is the time delay for a single piece of data to travel from source to destination (measured in milliseconds) — think of it as how long it takes one car to drive down a highway. **Bandwidth** is the maximum theoretical capacity of a connection (measured in bits per second) — how many lanes the highway has. **Throughput** is the actual rate of data successfully transferred in practice (also bits per second) — how many cars actually get through per minute, accounting for traffic, accidents, and tollbooths, which is why throughput is often noticeably lower than the advertised bandwidth. A genuinely useful way to phrase the relationship out loud: you can have a huge-bandwidth connection (a multi-lane highway) and still suffer from high latency (each individual car still takes a long time to physically drive the distance, e.g., a satellite link), and you can have low latency but low effective throughput if something downstream is bottlenecking actual transfer (heavy traffic, packet loss forcing TCP retransmissions, or an overloaded server).

## Scenario and debugging questions

Increasingly, networking rounds — especially for backend, DevOps, and SRE roles — skip pure definitions and instead hand you a symptom and ask you to reason through causes. These are worth specifically rehearsing because they require connecting multiple concepts above, live:

**"The site loads slowly but `ping` to the server is fast — what do you check?"** A fast ping confirms basic network reachability and low latency at the ICMP/network layer, but says nothing about the application layer. Check: DNS resolution time (is a slow resolver adding delay before the request even starts?), TLS handshake time (a misconfigured certificate chain or an overloaded server can slow the handshake specifically), server response/processing time (is the backend slow — a slow database query, an overloaded application server — rather than the network?), the number and size of downloaded resources (unoptimized images, render-blocking scripts), and whether a CDN or load balancer health check is silently routing requests to a degraded backend. The point of this question is realizing `ping` only tests one thin slice (ICMP round-trip) of a much longer chain.

**"A user reports intermittent connection drops — where do you start?"** Distinguish between client-side (WiFi signal, a flaky local network), ISP-level, and server-side causes. Check server logs for connection resets, check if it correlates with load (could be the server or load balancer exhausting connections/file descriptors under peak traffic), check for `TIME_WAIT` socket exhaustion on a high-churn server, and check if a stateful firewall or NAT timeout is closing idle connections prematurely — a classic, hard-to-diagnose bug where a connection idle for too long gets silently dropped by an intermediate NAT device, not by either endpoint.

**"DNS works from your laptop but not from inside a Docker container — why?"** Almost always a container networking/DNS configuration issue — the container may not be picking up the host's DNS resolver config, or it's on an isolated network namespace without the right `/etc/resolv.conf` entries, or a corporate VPN's split-DNS rules don't propagate into the container's network namespace the way they do for the host OS.

**"A specific API call works fine from Postman but fails from the browser with no clear error"** — strongly suggests **CORS** (Cross-Origin Resource Sharing): browsers enforce same-origin restrictions that tools like Postman or curl simply don't, so the request may never even reach the server from the browser's perspective, or the server responds but without the `Access-Control-Allow-Origin` header the browser requires to expose the response to your JavaScript. This trips up candidates who understand networking but have never debugged a real CORS error, which is exactly why interviewers like asking it.

**"How would you debug 'works on my machine, fails in production' for a network-related bug?"** Check for environment differences in DNS resolution (different resolvers, different `/etc/hosts` entries), firewall/security-group rules that block a port in production but not locally, load balancer health checks failing silently, TLS certificate issues that only manifest with the production domain, and IPv4-vs-IPv6 routing differences if production explicitly enables IPv6 and your local setup doesn't.

## How other prep methods handle computer networks — and where they fall short

Most candidates preparing for a networking round default to one of four approaches, and it's worth being honest about what each one is actually good for, because — unlike topics like raw algorithm grinding, where volume genuinely helps — networking is a verbal-narration subject, and that changes the cost-benefit math.

**GeeksforGeeks-style question dumps** are genuinely useful as a *checklist* — they're comprehensive, they're free, and they're a fast way to confirm you haven't missed an entire topic area (a quick scan will remind you that, yes, you also need to know about ARP and ICMP, not just the headline topics). What they don't do is simulate the experience of being asked "okay, but *why* does DNS prefer UDP" mid-answer and having to produce a coherent response on the spot — you read the answer, nod, and move to the next question, which builds recognition, not production.

**A YouTube networking crash-course, watched at 1.5x or 2x speed** the night before, is the single most common last-minute move, and it's not nothing — a good crash course can genuinely fix a shaky mental model fast. But watching someone else narrate the OSI model fluently is a fundamentally different skill from narrating it yourself with no script, and the gap between "I followed that explanation easily" and "I can reproduce that explanation live" is exactly the gap that shows up as a blank stare on a shared whiteboard.

**ChatGPT-generated answer lists** are fast to produce and often accurate, but they create a specific failure mode: candidates read a clean, complete, well-organized answer and mistake the *feeling* of understanding it for *having* the answer ready to produce unprompted. The text was never actually retrieved from your own memory under any pressure — it was recognized as correct when shown to you, which is a much easier cognitive task than generation. The OSI-layer-5 freeze from the opening of this guide is almost always this exact failure mode in disguise: the candidate had "read" the seven layers a dozen times and never once had to produce them cold.

**Generic flashcard apps** (Anki decks, Quizlet sets) are decent for raw recall of small facts — port numbers, status codes, which protocol uses TCP vs UDP — and there's no shame in using them for exactly that narrow purpose. But flashcards test recognition of a fact in isolation; they don't test whether you can chain five facts together into one coherent eight-step walkthrough while someone interrupts you with "wait, go back — why TCP and not UDP there specifically."

Where **Greenroom** differs is the format, not the content: instead of reading or recognizing the answer to "what happens when you type a URL," you say it out loud, to a voice-based AI interviewer, which then asks the kind of follow-up a real interviewer would — "you mentioned the TLS handshake, walk me through what's actually being exchanged" or "why would the load balancer route differently for that request" — forcing you to actually hold the whole stack in working memory and produce it under mild, realistic pressure, the same pressure that turned a known answer into a blank whiteboard in the opening scene. The honest tradeoff: it takes longer per topic than skimming a question dump, and it won't replace the breadth-building a GeeksforGeeks scan or crash-course gives you early on. The two are complementary, not competing — build breadth fast with a written dump or video, then convert that recognition into spoken fluency before the real interview, which is the step almost everyone skips because it's the uncomfortable one.

<div class="verdict"><strong>The core truth:</strong> networking interviews reward a connected mental model of the stack, not isolated facts. The candidate who can narrate "what happens when you type a URL" cleanly, layer by layer, while taking follow-ups, instantly signals real understanding — and that's a speaking skill you build by speaking, not by reading.</div>

## How to prepare, concretely

Start by drilling the connective tissue, not just the definitions: for every concept above, force yourself to also answer "why does this exist, and what breaks without it" — why does TCP need a three-way handshake (because committing data without confirming bidirectional reachability and agreeing on sequence numbers first would make reliable delivery impossible), why does DNS prefer UDP (because the overhead of TCP's handshake isn't worth it for a small, retryable, latency-sensitive query). Interviewers ask "why" far more than "what," and "why" answers are exactly the ones flashcards and question dumps train the least.

Then specifically rehearse the big narrative questions — the URL walkthrough, the OSI-layer walkthrough, the TLS handshake — out loud, ideally to another person or a tool that can interrupt you with follow-ups, because the interrupt-and-recover skill is the actual interview, not a side effect of it. Pair this guide with our [system design interview guide](/blog/system-design-interview-guide-india) (networking concepts — load balancers, CDNs, latency — resurface constantly in system design rounds), our [operating systems interview guide](/blog/operating-system-interview-questions) (processes, threads, and memory questions show up in the same campus loops as networking), and [coding interview communication tips](/blog/coding-interview-communication-tips) for the broader skill of narrating technical reasoning out loud under follow-up pressure, since that skill transfers directly from coding rounds to networking rounds. If your loop also includes a system-design round proper, [what system design interviews actually test](/blog/system-design-interviews-what-they-test) is worth reading before you assume it's a separate, unrelated topic — the overlap with networking fundamentals is larger than most candidates expect.

[Greenroom](/) runs spoken technical mock interviews that ask exactly this kind of follow-up — "you said TCP guarantees ordering, how does it actually do that" — and gives feedback on where your explanation got vague, stalled, or skipped a step, which is the specific failure mode that silent reading can't catch because there's no one there to notice you skipped it.

## Frequently asked questions

### What are the most common computer networks interview questions?

Common questions cover the OSI model's seven layers and OSI vs TCP/IP, TCP vs UDP, the TCP three-way handshake, IP and IPv4 vs IPv6 with subnetting/CIDR, DNS resolution, HTTP vs HTTPS and the TLS handshake, sockets and ports, the classic "what happens when you type a URL" walkthrough, and networking devices like routers, switches, firewalls, NAT and load balancers, often combined with scenario/debugging questions like "the site is slow but ping is fast."

### What is the difference between TCP and UDP?

TCP is connection-oriented and reliable: it establishes a connection via a three-way handshake, guarantees ordered delivery, and retransmits lost packets, which makes it ideal for web pages, email and file transfer. UDP is connectionless and faster with no delivery or ordering guarantees, which suits real-time uses like video streaming, gaming and DNS where speed matters more than perfect reliability.

### What happens when you type a URL and press enter?

The browser checks its cache, resolves the domain to an IP via DNS, opens a TCP connection to the server (and performs a TLS handshake for HTTPS), sends an HTTP request, the server (often via a load balancer) processes it and returns a response, and the browser parses the HTML, requests additional resources like CSS and JS, and renders the page. This single walkthrough tests the entire networking stack end to end.

### How do I calculate subnets from a CIDR block, like splitting a /24 into 4 subnets?

Borrowing bits from the host portion doubles the number of subnets per bit: a /24 has 8 host bits (256 addresses); borrowing 2 bits to make four /26 subnets leaves 6 host bits each (64 addresses, 62 usable per subnet after excluding the network and broadcast addresses). The four resulting /26 ranges from 192.168.1.0/24 would be 192.168.1.0–.63, .64–.127, .128–.191, and .192–.255.

### Why does DNS use UDP instead of TCP?

DNS queries are small, idempotent, and cheap to retry at the application layer if no response arrives, so paying TCP's three-way handshake overhead for every lookup would add unnecessary latency to something users expect to be near-instant. DNS does fall back to TCP for unusually large responses and for zone transfers between servers.

### How should I prepare for a computer networks interview?

Build a connected mental model of the stack rather than isolated facts, drill the "why" behind each mechanism (why TCP handshakes, why DNS prefers UDP), and especially rehearse the big narrative questions — the OSI-layer walkthrough, the TLS handshake, the "what happens when you type a URL" question — out loud. Since these questions are entirely verbal, practise narrating mechanisms and flows with real follow-up pressure, ideally with a voice-based mock interview that interrupts and pushes back the way a real interviewer would.

Networking rounds reward a connected mental model, narrated out loud under follow-up pressure. Greenroom runs spoken technical interviews that follow up and give feedback. Free to start.