Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What happens when you type a URL into the browser and press Enter?

They're testing: whether you can describe the whole path in order, then go deep anywhere.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The browser resolves the domain to an IP address with DNS, checking caches first. It opens a connection (a TCP handshake, or QUIC for HTTP/3), then a TLS handshake verifies the certificate and sets up encryption. It sends the HTTP request. On the server side, a load balancer routes it to an app server, which may read from a cache and a database, and sends a response. The browser renders the HTML and fetches the CSS, JavaScript and images it references, often from a CDN.
3
4**Counter-questions:**
5- *"What if the DNS answer is already cached?"* → The lookup is skipped, which saves time. That's why DNS records have a TTL (Chapter 4).
6- *"Where could this be slow?"* → Every handshake round trip, a far-away server, a slow database query, large images, or many requests made one after another. I'd measure each step.
7
8**Trap:** stopping at "the server sends back the page".

Q2. GET vs POST?

They're testing: semantics, not just "POST has a body".

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** GET reads; it's safe and idempotent, so it can be cached and retried freely. POST creates something or triggers an action; it isn't idempotent, so retrying it can create duplicates. GET parameters go in the URL, so they show up in logs and history, which is another reason not to put secrets there.
3
4**Counter-questions:**
5- *"Can a GET have a body?"* → The spec doesn't give a GET body any defined meaning, and many servers and proxies ignore or reject it. Don't rely on it.
6- *"Is POST more secure than GET?"* → Not by itself. Both are equally visible without HTTPS. POST just keeps data out of the URL and logs.
7
8**Trap:** "POST is for sending data, GET is for getting data", with nothing about safety or idempotency.

Q3. PUT vs PATCH vs POST?

They're testing: idempotency and resource thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** POST creates a new resource (the server picks its ID) and isn't idempotent. PUT replaces the resource at a known address with exactly what you send, so sending it twice gives the same result. PATCH changes part of a resource; it may or may not be idempotent depending on the change ("set phone to X" is, "add 1 to quantity" isn't).
3
4**Counter-questions:**
5- *"Can PUT create something?"* → Yes, if the client chooses the address, like `PUT /users/7/avatar`. Then it creates or replaces.
6
7**Trap:** "PUT is update, POST is create" with no mention of replacing vs partial changes.

Q4. Which HTTP methods are idempotent, and why does it matter?

They're testing: reliability thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** GET, HEAD, OPTIONS, PUT and DELETE are idempotent; POST isn't, and PATCH isn't guaranteed. It matters because networks fail and clients retry. A timed-out idempotent request can be retried safely. A timed-out POST might have succeeded, so retrying it can double an order or a payment. For those, we use an idempotency key so the server recognises a repeat (Chapter 24).
3
4**Counter-questions:**
5- *"Is DELETE really idempotent if the second call returns 404?"* → Yes. Idempotency is about the effect on the server, not the response. After one or two DELETEs, the item is gone either way.
6
7**Trap:** confusing idempotent with safe.

Q5. 401 vs 403? 502 vs 503 vs 504?

They're testing: precise codes, which shows real debugging experience.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** 401 means not authenticated: log in or send valid credentials. 403 means authenticated but not allowed. 502: a gateway such as a load balancer got an invalid response from the server behind it. 503: the service is unavailable, often overloaded or in maintenance. 504: the gateway gave up waiting for the server behind it.
3
4**Counter-questions:**
5- *"You see a spike of 504s. Where do you look?"* → At the servers behind the load balancer: slow database queries, a dependency that's hanging, or too few servers for the load. Compare the load balancer's timeout with the app's response times.
6
7**Trap:** treating all 5xx errors as "server error" with no difference.

Q6. TCP vs UDP: when would you use each?

They're testing: trade-offs, not definitions.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** TCP gives a reliable, ordered byte stream after a handshake, so it suits anything that must be complete: web pages, APIs, files, databases. UDP sends independent packets with no guarantees, so it suits real-time traffic where late data is useless, like voice and video calls or games, and simple question-and-answer lookups like most DNS. QUIC builds its own reliability on UDP, which is how HTTP/3 gets reliability without TCP's head-of-line blocking.
3
4**Counter-questions:**
5- *"Why not just use TCP for video calls?"* → A lost packet makes TCP hold back everything behind it until it's resent. For live audio, it's better to skip a few milliseconds than to freeze.
6
7**Trap:** "UDP is faster, so use it for speed", without the loss of guarantees.

Q7. How does HTTPS work?

They're testing: a correct, simple mental model.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** HTTPS is HTTP over TLS. In the handshake, the server sends a certificate signed by a trusted certificate authority to prove its identity, and both sides use public-key cryptography to agree on a shared secret. Then all traffic is encrypted with fast symmetric encryption, and tampering is detected. TLS 1.3 completes the handshake in one round trip.
3
4**Counter-questions:**
5- *"Why not use public-key encryption for everything?"* → It's much slower. It's used to agree on a key, then symmetric encryption does the bulk work.
6- *"What can an observer still see?"* → IP addresses, timing and size of traffic, and usually the domain name. Not the path, headers or body.
7
8**Trap:** "HTTPS encrypts with the server's public key", end of story.

Q8. HTTP/1.1 vs HTTP/2 vs HTTP/3?

They're testing: why each version exists.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** HTTP/1.1 added persistent connections but, in practice, handles one request at a time per connection. HTTP/2 multiplexes many requests over one TCP connection and compresses headers, but one lost TCP packet still stalls everything on that connection. HTTP/3 runs over QUIC on UDP, gives each stream independent delivery, combines the transport and TLS handshakes, and copes better with network changes on mobile.
3
4**Counter-questions:**
5- *"Does HTTP/2 make every site faster?"* → It helps most when a page needs many small resources. On lossy networks, TCP's head-of-line blocking can still hurt, which is what HTTP/3 addresses.
6
7**Trap:** "HTTP/3 is faster because it's newer".

Q9. What does stateless mean, and why do we want stateless servers?

They're testing: the link between statelessness and scaling.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A stateless server keeps no per-user data in its own memory between requests. Each request carries what's needed, and shared state lives in a database or cache. That lets any server handle any request, so we can load-balance freely, add or remove servers easily, and lose a server without losing sessions.
3
4**Counter-questions:**
5- *"Isn't a WebSocket server stateful?"* → Yes. A long-lived connection ties a user to one server. You still keep the important state in shared stores, so another server can take over on reconnect (Chapter 21).
6- *"What about sticky sessions?"* → They work around stateful servers by always sending a user to the same one. They make scaling and failures harder, so I'd treat them as a stopgap (Chapter 7).
7
8**Trap:** "stateless means we don't store any data".

Q10. Sessions or JWTs?

They're testing: trade-offs, especially revocation.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A session stores the truth on the server, keyed by a random ID in a cookie: easy to revoke, but a lookup per request. A signed token like a JWT carries the claims itself, so any service can verify it without a lookup, but it can't easily be revoked before it expires. I'd use server sessions for a website, and short-lived access tokens plus revocable refresh tokens for mobile apps and many services.
3
4**Counter-questions:**
5- *"How do you log out a user everywhere with JWTs?"* → Keep access tokens short-lived, revoke the refresh tokens, and for urgent cases keep a small deny-list of token IDs checked on each request.
6- *"Where should a browser store tokens?"* → An `HttpOnly`, `Secure`, `SameSite` cookie is generally safer than `localStorage`, which any script on the page can read.
7
8**Trap:** "JWT is better because it's stateless", with no word on revocation.

Q11. What are cookies, and how do you keep them safe?

They're testing: basic web security awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Cookies are small values a server sets with `Set-Cookie`; the browser sends them back automatically to that site. They usually carry a session ID or token. To keep them safe: `HttpOnly` so scripts can't read them, `Secure` so they only travel over HTTPS, `SameSite` to limit cross-site sending, and a sensible expiry.
3
4**Counter-questions:**
5- *"What does SameSite protect against?"* → Mainly cross-site request forgery, where another site tricks your browser into sending a request with your cookies.
6
7**Trap:** storing passwords or personal data directly in cookies.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 3.1 Client and server | Q1, Level 5.1 |
18| 3.2 Request and response | Level 3, Q1 |
19| 3.3 Typing a URL | Level 2, Q1 |
20| 3.4 Methods | Level 1A, Level 5.5, Q2, Q3, Q4 |
21| 3.5 Status codes | Level 1B, Level 3, Q5 |
22| 3.6 Headers and body | Level 3, Q11 |
23| 3.7 TCP vs UDP | Level 2, Q6 |
24| 3.8 HTTPS and TLS | Level 2, Q7 |
25| 3.9 Keep-alive, HTTP/2, HTTP/3 | Level 2, Level 5.4, Q8 |
26| 3.10 Stateless servers | Level 4, Q9 |
27| 3.11 Cookies, sessions, tokens | Level 4, Level 5.2, Level 5.3, Q10, Q11 |
28
29---

3. Client and Server