Top 9 Http Interview Questions
Browse 9 real-world technical and behavioral interview questions about Http. Review scenarios, edge cases, and architectural best practices.
What happens when you type a URL and press Enter? Give me the version you would give in a campus viva, then tell me where you expect me to push.
Six steps in order: the browser checks its cache, DNS resolution turns the hostname into an IP address, a TCP handshake opens a connection, a TLS handshake authenticates the server and agrees keys, an HTTP request fetches the page, and the browser renders it. Panels push on DNS, the handshakes and certificates.
Two clients open the same record, both edit it, and the second save silently overwrites the first. How would you use ETags to turn that lost update into something the client can see and handle?
Return a strong ETag on GET, require If-Match on writes, and reject a stale token with 412 Precondition Failed so a lost update becomes a visible error rather than silent data loss. What makes it correct is that the comparison and the write must be one atomic operation - an UPDATE guarded by the version in its WHERE clause - because a SELECT then UPDATE reintroduces the race.
Your logs are full of Cannot set headers after they are sent. Walk me through how a request gets into that state.
ERR_HTTP_HEADERS_SENT means an Express route tried to set status or headers after the response had already been sent. The usual cause is two response paths: missing return after res.send, async callbacks racing, or an error handler trying to respond after headers are committed.
How do you design the error contract for an API that other teams have to program against?
Treat errors as published contract: an HTTP status that classifies the failure, a stable machine-readable code the client branches on, a human message that carries no internal detail, per-field detail for validation, and an explicit statement of whether a retry is safe.
A client times out and retries your POST /payments call. How do you make that endpoint idempotent?
Take an idempotency key from the client and store it in a uniquely-constrained row written in the same transaction as the effect, so the dedupe record and the work commit together. Replay the stored response on a repeat, refuse a retry arriving mid-flight, and expire keys past the retry horizon.
Clients are asking for page 4,000 of your /orders collection. How is that endpoint paginated, and what would you change?
Offset pagination gets slower with depth and drifts when rows are inserted mid-traversal, so paginate with a keyset comparison on the sort key plus a unique tiebreaker, hand back an opaque cursor and a Link rel=next header, and price an exact total count separately.
Which status codes and method semantics do you insist on in a code review, how do the caching headers fit together, and is the API you just described REST?
Get the method's safety, idempotency and cacheability right, use the status code intermediaries and clients act on rather than a generic 200 with an error body, pair Cache-Control freshness with ETag or Last-Modified validators, and be honest that most APIs called REST are resource-shaped HTTP without hypermedia.
Customers need to upload two-gigabyte files to your API over a flaky connection. What does that endpoint look like, and what breaks if you just accept a POST body?
A single large POST fails on the last percent and starts again, and it drags every proxy body limit and idle timeout into your critical path. Either hand out a scoped credential so bytes go straight to storage, or model the upload as a resource with a committed offset the client can resume from.
Walk me through everything that happens when you type a URL into the browser and press enter.
The browser checks its caches, resolves the hostname through browser, OS and resolver caches, opens a TCP connection, completes a TLS handshake, sends the request, then parses the streamed response. QUIC fuses transport and crypto setup into one round trip and stops one lost packet stalling every stream.