Loading...
Loading...
Loading...
Core CS and SQL interview guide
OSI and TCP/IP, IP addressing, TCP and UDP, DNS and HTTP. Every answer is short enough to say aloud, and every question links to the lesson that teaches it.
60 questionsLast updated
Broadcasts do not cross routers, so the router runs a DHCP relay agent. It receives the broadcast and forwards it as a unicast to the central DHCP server.
Lesson: MAC addresses, ARP, DHCP and NATSource NAT changes the source address of outgoing traffic, as a home router does for browsing. Destination NAT changes the destination address of incoming traffic, as port forwarding does to reach an inside server.
Lesson: MAC addresses, ARP, DHCP and NATCarrier-grade NAT is NAT done by the internet provider, so many customers share one public IP. Your router may then get a private or 100.64.x.x address, and port forwarding at home will not work.
Lesson: MAC addresses, ARP, DHCP and NATUsually not. IPv6 has enough addresses for every device to have a public one, so security is handled by firewalls instead of address translation.
Lesson: MAC addresses, ARP, DHCP and NATDHCP gives the phone an IP, mask, gateway and DNS server. DNS resolves the site name to an IP. Because that IP is on another network, ARP finds the gateway's MAC and the phone sends the frame to the router, which applies NAT and forwards it to the internet. Replies come back through the NAT table to the phone.
Follow-up: Where does ARP appear in that story? After DHCP, when the phone sends its first packet: it ARPs for the gateway's MAC so it can build the frame.
Common mistake: Mixing up the order. Say DHCP, ARP, DNS, TCP and TLS, then NAT at the router.
Lesson: MAC addresses, ARP, DHCP and NATBoth sides set up shared state before data flows: starting sequence numbers, window sizes and buffers. TCP does this with the handshake and tears it down at the end.
Follow-up: Does UDP have any connection at all? No. UDP keeps no state between messages, so each datagram is independent. A "UDP connection" in a library is only a socket that remembers an address.
Common mistake: Saying the connection is a dedicated wire. It is only shared state (numbers and buffers) kept in the two end hosts; the network in between does not know about it.
Lesson: TCP vs UDP and the three-way handshakeA socket is the endpoint of a connection, identified by IP address and port. A TCP connection is identified by four values: source IP, source port, destination IP and destination port.
Lesson: TCP vs UDP and the three-way handshakeFour 16-bit fields: source port, destination port, length and checksum, 8 bytes in total.
Lesson: TCP vs UDP and the three-way handshakeSource and destination ports, sequence number, acknowledgement number, header length, flags such as SYN, ACK, FIN, RST and PSH, window size, checksum and urgent pointer. The basic header is 20 bytes; options can make it up to 60.
Lesson: TCP vs UDP and the three-way handshakeTCP is connection-oriented: it sets up a connection with a handshake and gives reliable, ordered delivery using sequence numbers, ACKs and retransmission. UDP is connectionless and best effort, with an 8-byte header and no ordering or retransmission. TCP suits web pages and payments; UDP suits video calls, games and DNS.
Follow-up: Which would you pick for a live stock-price ticker? UDP, if the screen only needs the latest price, because an old price is useless. For trades or order confirmations, use TCP, since a missed message there is a real loss.
Common mistake: Answering only "TCP is reliable, UDP is fast". Say what reliability costs (setup, waiting for ACKs) and give one use case for each; slogans lose marks.
Lesson: TCP vs UDP and the three-way handshakeThe client sends SYN with its starting sequence number x. The server replies SYN-ACK with its own number y and ack x+1. The client sends ACK with ack y+1. After this both sides know each other's sequence numbers and that both directions work.
Follow-up: What happens if the final ACK is lost? The server stays in SYN-RECEIVED and resends its SYN-ACK. The client already believes it is connected, and the first data segment it sends also carries the ACK that completes the handshake.
Common mistake: Forgetting the numbers or saying the handshake has two steps. Draw all three arrows with seq and ack values (x, then y and x+1, then y+1).
Lesson: TCP vs UDP and the three-way handshakeEvery byte has a sequence number, and the receiver sends cumulative ACKs for the next byte it expects. If an ACK does not arrive before the timeout, or three duplicate ACKs arrive, the sender retransmits. The receiver reorders segments and drops duplicates before giving data to the app.
Follow-up: How does the sender know a segment was lost? Either the retransmission timeout expires with no ACK, or three duplicate ACKs arrive for the same number, which triggers fast retransmit.
Common mistake: Saying "TCP resends everything". It resends only the missing segment; the receiver holds later data and answers with a cumulative ACK.
Lesson: TCP vs UDP and the three-way handshakeFlow control protects the receiver: it advertises a receive window and the sender stays within it. Congestion control protects the network: the sender keeps a congestion window that grows with slow start and additive increase, and shrinks on loss. The sender uses the smaller of the two windows.
Follow-up: Which window decides how much the sender may send? Both. The sender keeps at most min(rwnd, cwnd) bytes in flight. The receiver sets rwnd; the sender computes cwnd from loss signals.
Common mistake: Swapping the two. Flow control protects the receiver, congestion control protects the network: say "receiver" and "network" in your answer.
Lesson: TCP vs UDP and the three-way handshakeBecause reliability costs time. In a voice call or a game, a packet that arrives late is useless, and waiting for a retransmission makes everything after it late too. UDP lets the app skip lost data, and protocols like QUIC add only the reliability they need on top of UDP.
Follow-up: Can you add reliability on top of UDP? Yes, in the application: sequence numbers, ACKs and retries only for messages that matter. QUIC does exactly this, which is why HTTP/3 runs on UDP.
Common mistake: Saying "UDP is faster" with no reason. The real reasons are no setup, no waiting for ACKs and no head-of-line blocking.
Lesson: TCP vs UDP and the three-way handshakeNormal DNS queries use UDP port 53 because a single small question and answer do not need a connection. DNS switches to TCP for large responses and for zone transfers between servers.
Follow-up: When does DNS use TCP? When an answer is too large for one UDP message, and for zone transfers between name servers. DNS over TLS and DNS over HTTPS also run on TCP-based transports.
Common mistake: Saying "DNS always uses UDP". Normal queries use UDP port 53, but TCP port 53 is used when needed.
Lesson: TCP vs UDP and the three-way handshakeTCP: HTTP/1.1, HTTP/2, HTTPS, SSH, FTP, SMTP, MySQL. UDP: DNS queries, DHCP, video and voice calls, online games, and QUIC (HTTP/3).
Lesson: TCP vs UDP and the three-way handshakeRST resets a connection immediately. A server sends it, for example, when a SYN arrives on a port where nothing is listening, which the client shows as "connection refused".
Lesson: TCP vs UDP and the three-way handshakeIt is the first sequence number a side chooses in its SYN. It is randomised so old packets from an earlier connection do not fit the new one and attackers cannot easily guess it to inject data.
Lesson: TCP vs UDP and the three-way handshakeOne side sends FIN to say it has finished sending but can still receive. The other side can keep sending until it also sends its FIN.
Lesson: TCP vs UDP and the three-way handshakeTCP measures the round-trip time of segments and keeps a smoothed average and variation. The timeout is set a little above the expected round-trip time and doubles after each failed retry.
Lesson: TCP vs UDP and the three-way handshakeWhen the sender gets three duplicate ACKs for the same number, it assumes that segment was lost and resends it at once, without waiting for the timeout.
Lesson: TCP vs UDP and the three-way handshakeIt is the range of bytes the sender may have sent but not yet had acknowledged. As ACKs arrive, the window slides forward and new bytes can be sent, so the sender does not wait after every segment.
Lesson: TCP vs UDP and the three-way handshakeAt the start of a connection the congestion window begins small and doubles every round trip, so the sender quickly finds how much the network can carry. It stops doubling at the slow-start threshold or on loss.
Follow-up: When does slow start end? When cwnd reaches the slow-start threshold or a loss happens. After the threshold, TCP grows the window by one segment per round trip, which is congestion avoidance.
Lesson: TCP vs UDP and the three-way handshakeAdditive increase, multiplicative decrease: in congestion avoidance the window grows by about one segment per round trip, and on loss it is cut, typically in half. This keeps many TCP flows sharing a link fairly.
Lesson: TCP vs UDP and the three-way handshakeBecause TCP delivers bytes in order, one lost segment holds back all the data behind it until it is retransmitted. This is why real-time apps prefer UDP and why HTTP/3 moved to QUIC.
Lesson: TCP vs UDP and the three-way handshakeUDP has less overhead: no handshake, no waiting for ACKs and a smaller header, so it has lower delay. But the raw link speed is the same; the difference is in delay and control, not in how fast bits travel.
Follow-up: Then why is HTTP/3 built on UDP? TCP pays for its handshake and for head-of-line blocking, where one lost segment stalls every stream. QUIC on UDP runs streams independently and merges transport and TLS setup into one round trip.
Common mistake: Saying "UDP is faster" as a flat rule. UDP has lower delay per message, but a file transfer is not faster if you must rebuild reliability yourself.
Lesson: TCP vs UDP and the three-way handshakeYes, the application can add sequence numbers, acknowledgements and retransmission on top of UDP. QUIC does exactly this, with encryption and multiple streams, and HTTP/3 runs on it.
Lesson: TCP vs UDP and the three-way handshakeSocket and ServerSocket use TCP. DatagramSocket and DatagramPacket use UDP.
No. TCP guarantees delivery within one connection, but a retry is a new request at the application level. The app must make the payment idempotent, for example with an idempotency key, so the second request does not charge again.
Follow-up: How do you make the retry safe? Send an idempotency key with the payment, so the server recognises the repeat and returns the first result instead of charging twice.
Common mistake: Saying "TCP guarantees delivery, so the payment went through". TCP guarantees bytes reach the other host, not that the server finished the work or that you received the reply.
Lesson: TCP vs UDP and the three-way handshakeDNS is the Domain Name System. It translates human-friendly names like www.example.com into IP addresses, using a distributed hierarchy of servers and lots of caching.
Follow-up: Is DNS a single server? No. It is a distributed hierarchy of root, TLD and authoritative servers, plus resolvers and caches everywhere, so there is no single point of failure.
Common mistake: Saying only "DNS converts a website name to an IP". Mention the hierarchy and caching to show depth.
Lesson: DNS and what happens when you type a URLPeople remember names, but routers need IP addresses. DNS also lets a site change servers or IPs without users noticing, because only the record changes.
Lesson: DNS and what happens when you type a URLIt is the DNS server your device asks, usually from your ISP, college or a public provider. It takes the recursive request, does all the lookups on your behalf and returns the final answer, caching it for others.
Lesson: DNS and what happens when you type a URLIn a recursive query the client asks for the final answer and the server must get it. In an iterative query the server answers with the best it knows, often a referral to another server, and the asker continues. Devices ask resolvers recursively; resolvers query root, TLD and authoritative servers iteratively.
Follow-up: Which type does your laptop use? Recursive: the laptop asks its resolver for the final answer. The resolver then uses iterative queries to the root, TLD and authoritative servers.
Common mistake: Reversing the two. The client's request is recursive; the resolver's chain of referrals is iterative.
Lesson: DNS and what happens when you type a URLA top-level domain is the last part of a name, such as .com, .org or the country code .in. TLD servers know the authoritative name servers for every domain under them.
Lesson: DNS and what happens when you type a URLIt is the server that holds the actual DNS records for a domain, set up by the domain owner or their DNS provider. Its answer is the source of truth; other servers only cache it.
Lesson: DNS and what happens when you type a URLTime to live, in seconds, says how long an answer may be cached. A short TTL makes changes visible quickly but causes more queries; a long TTL reduces load but slows changes.
Follow-up: What TTL would you set before moving a site to a new server? Lower the TTL, for example to 60 seconds, a day before the move so old answers expire quickly. Raise it again after the switch.
Common mistake: Saying a DNS change is instant. Cached answers live on until their TTL ends.
Lesson: DNS and what happens when you type a URLAn A record maps a name directly to an IPv4 address. A CNAME maps a name to another name, which must then be resolved to get the IP.
Follow-up: Can a CNAME sit at the root of a domain? No. The root of a domain also needs NS and SOA records, and a CNAME cannot sit beside other records. Providers offer an ALIAS or ANAME record instead.
Lesson: DNS and what happens when you type a URLIt lists the mail servers that accept email for a domain, each with a priority number. Sending servers try the lowest number first.
Lesson: DNS and what happens when you type a URLIn the browser, in the operating system, and in the recursive resolver. The hosts file on the computer can also override DNS for testing.
Lesson: DNS and what happens when you type a URLMost DNS exchanges are one small question and one small answer, so a TCP handshake would more than double the time. DNS falls back to TCP when the answer is too large or for zone transfers.
Lesson: DNS and what happens when you type a URLnslookup works on Windows, macOS and Linux, and dig gives more detail on macOS and Linux. For example nslookup example.com shows the resolver used and the addresses returned.
It parses it into scheme, host, port, path and query, and checks whether it is a URL or a search term. If the scheme is https and no port is given, it uses 443.
Follow-up: What does it check before asking DNS? Its own cache, the operating system cache and the hosts file. HSTS may also turn http into https before anything is sent.
Lesson: DNS and what happens when you type a URLHTTP/1.1 and HTTP/2 run on TCP, which gives reliable, ordered delivery. The three-way handshake must finish before any request bytes can be sent.
Follow-up: Why TCP and not UDP for HTTP? A page must arrive complete and in order, and TCP gives that. HTTP/3 now gets the same result from QUIC, which runs on UDP.
Lesson: DNS and what happens when you type a URLA load balancer or reverse proxy usually picks an app server. The app checks the session or token, runs the business logic, queries the database or cache, and builds the response with a status code, headers and body.
Lesson: DNS and what happens when you type a URLIt parses HTML into the DOM and CSS into the CSSOM, combines them into a render tree, calculates layout and paints pixels. JavaScript can change the DOM and trigger more layout and painting.
Lesson: DNS and what happens when you type a URLThe DNS answer is probably cached, the TCP and TLS connection may be reused, and static files may come from the browser cache or be revalidated with a 304 Not Modified. The page loads much faster.
Lesson: DNS and what happens when you type a URLHTTP Strict Transport Security is a header that tells the browser to use only HTTPS for that site for a period. After the first visit, the browser upgrades http:// to https:// itself, so no plain HTTP request is sent.
Follow-up: Why does HSTS help against attacks? It tells the browser to always use HTTPS for that site, so an attacker cannot downgrade the first request to plain HTTP.
Lesson: DNS and what happens when you type a URLThe site's DNS usually has a CNAME to the CDN, and the CDN's DNS returns the IP of a nearby edge server. That edge serves cached files quickly and fetches from the origin server only when needed.
Follow-up: How does a CDN change DNS? The CDN's DNS answers with the IP of a nearby edge server, so users in different cities get different IPs for one name.
Lesson: DNS and what happens when you type a URLThe name does not exist, so the browser cannot connect and shows an error such as "site cannot be reached" or "DNS_PROBE_FINISHED_NXDOMAIN". It may also offer to search the text instead.
Follow-up: How is NXDOMAIN different from a timeout? NXDOMAIN is a real answer meaning the name does not exist. A timeout means nobody answered, which points to a network or resolver problem.
Lesson: DNS and what happens when you type a URLThat points to DNS. I would run nslookup for the name, try a different resolver such as a public one, check the hosts file, and flush the DNS cache. If other resolvers also fail, the domain's records or name servers are the problem.
Follow-up: Which commands do you run? ping and curl by IP to confirm connectivity, then nslookup or dig for the name to see what the resolver returns, then check the resolver setting.
Common mistake: Restarting the server. If the IP works, the fault is in name resolution, not in the server.
Lesson: DNS and what happens when you type a URLThe browser parses the URL and checks its caches. DNS resolves the host through the resolver, root, TLD and authoritative servers. The browser opens a TCP connection to port 443 and does a TLS handshake to verify the certificate and agree on keys. It sends the HTTP GET request; the server, via a load balancer and app, returns 200 OK with HTML. The browser fetches CSS, JS and images, builds the DOM and CSSOM, and paints the page.
Follow-up: Go deeper on the TLS handshake. The browser sends its supported versions and ciphers, the server replies with its certificate, the browser verifies it, both agree on a shared key using asymmetric cryptography, and the data then uses fast symmetric encryption.
Common mistake: Skipping steps or mixing the order. Use the same skeleton every time: parse, cache, DNS, TCP, TLS, HTTP, server, render.
Lesson: DNS and what happens when you type a URLHTTP is the application-layer request-response protocol of the web. A client sends a request with a method, path, headers and optional body, and the server replies with a status code, headers and a body.
Lesson: HTTP vs HTTPS, ports and common protocolsThe server does not remember earlier requests by itself; each request carries everything needed. State such as a login is carried by cookies, sessions or tokens like JWTs.
Follow-up: How does a login stay active then? After login the server sends a session cookie or a token, and the browser attaches it to every request so the server can recognise the user.
Common mistake: Saying HTTP remembers users. The protocol keeps no memory; cookies or tokens carry the state.
Lesson: HTTP vs HTTPS, ports and common protocolsGET reads data, puts parameters in the URL, can be cached and bookmarked and is idempotent. POST sends data in the body to create or process something and is not idempotent. Neither is secure on its own; HTTPS is what protects the data.
Follow-up: Is POST safer than GET for passwords? Only slightly. The data is not in the URL or history, but without HTTPS it is still readable. The safety comes from HTTPS, not from the method.
Common mistake: Saying POST is secure and GET is not. POST only puts data in the body; use HTTPS to protect either.
Lesson: HTTP vs HTTPS, ports and common protocolsAn operation is idempotent if doing it many times has the same effect as doing it once. GET, PUT and DELETE are idempotent; POST is not, which matters when clients retry requests.
Follow-up: Which methods are idempotent? GET, PUT, DELETE, HEAD and OPTIONS. POST is not, which is why retrying a payment POST can charge twice.
Common mistake: Mixing up safe and idempotent. Safe means no change on the server (GET); idempotent means repeating gives the same result (PUT, DELETE).
Lesson: HTTP vs HTTPS, ports and common protocols1xx informational, 2xx success, 3xx redirection, 4xx client errors and 5xx server errors.
Lesson: HTTP vs HTTPS, ports and common protocols401 Unauthorized means the request is not authenticated: no login or an invalid token. 403 Forbidden means the server knows who you are but you do not have permission.
Follow-up: Which code does a valid user without rights get? 403 Forbidden. A request with missing or invalid credentials gets 401.
Common mistake: Swapping them. 401 means "who are you?" (not authenticated); 403 means "I know you, but no" (not authorised).
Lesson: HTTP vs HTTPS, ports and common protocols301 is a permanent redirect: browsers and search engines update to the new URL. 302 is temporary: keep using the old URL in future.
Lesson: HTTP vs HTTPS, ports and common protocolsThe browser sent a conditional request, for example with If-None-Match and an ETag, and the resource has not changed. The server sends no body, and the browser uses its cached copy.
HTTPS is HTTP sent over a TLS-encrypted connection, by default on port 443. It gives confidentiality, integrity and authentication of the server.
Lesson: HTTP vs HTTPS, ports and common protocolsEach lesson has quizzes, practice and more interview questions on the same topic.
Open the first lesson