Loading...
Loading...
Loading...
Backend interview guide
HTTP methods and status codes, headers, cookies, sessions, JSON and REST API design. Every answer is short enough to say aloud, and every question links to the lesson that teaches it.
60 questionsLast updated
The client sends one request, the server does the work and sends back exactly one response. The client always starts; the server never sends something nobody asked for. A browser loading a page runs many of these cycles, one per file it needs.
Lesson: Clients and serversYes to both. A server answers many clients at the same time and keeps each request's response separate. One machine can run many servers, each waiting on its own port, such as a database on 3306 and a web app on 8000.
Lesson: Clients and serversThat message means nothing is waiting at that address and port, so I first check that the server is actually running. Then I check the port in the URL matches the port the server printed when it started.
Lesson: Clients and serversThe IP address identifies the computer and the port identifies one server program on it. Together, as address:port, they say exactly where a request goes, for example 104.20.23.154:443.
DNS turns names like example.com into IP addresses, through a resolver that asks other DNS servers and caches the answers. If DNS fails, clients cannot find addresses, so sites stop opening by name even though the servers themselves are fine.
I look at the exact error. "Could not resolve host" or NXDOMAIN means the name step failed, so I check the name with nslookup. "Connection refused" means the address was found but no server listens on that port, so I check that the server is running on the right port.
Scheme, host, port, path, query string and fragment: scheme://host:port/path?query#fragment. Only the scheme and host are always present; the port defaults to 80 for http and 443 for https.
No. The browser removes everything after # before sending the request and uses it only to jump to a place in the page. So if a value really contains #, it must be encoded as %23.
Only when the server does not use the scheme's default port. Public sites use 443 for https, so no port is shown; local development servers often run on 8080 or 8000, so their URLs include :8080.
The page puts the search text into the URL without encoding it, so the & splits it into two parameters and the server sees q=C . The fix is to percent-encode the value, so the URL carries q=C%20%26%20DS.
For an https URL: a DNS lookup for the address, the TCP three-way handshake (SYN, SYN-ACK, ACK), then the TLS handshake to agree on encryption. Only then does the client write GET / HTTP/1.1 and the headers into the connection.
They carry the same requests, headers and status codes. HTTP/1.1 is text and handles one request at a time per connection; HTTP/2 uses binary frames and many requests at once on one TCP connection; HTTP/3 does the same over QUIC on UDP, which connects faster and handles packet loss better.
Lesson: TCP: the connection under HTTPYes. HTTP/1.1 is just text, so I can open a plain TCP connection, for example with curl telnet://example.com:80 or nc, and type the request line, the Host header and an empty line. The server answers with a normal response.
The client says hello with the TLS versions and methods it supports, the host name it wants and its key share. The server answers with its choice and its own key share, and both sides compute the same shared secret without sending it. The server then sends its certificate, the client checks the name, the dates and the issuer, and everything after that, including the HTTP request, is encrypted.
Lesson: HTTPS and TLS in plain wordsIt proves the connection is encrypted and that the server holds a valid certificate for that exact domain. It does not prove the site is honest; a phishing site can have a perfectly valid certificate for its own lookalike domain.
Lesson: HTTPS and TLS in plain wordsThey still carry passwords, tokens and personal data, and networks inside companies or colleges are not automatically safe. Certificates are free with Let's Encrypt, so there is little reason to skip it. Test setups also tend to become production setups.
Lesson: HTTPS and TLS in plain wordsThe first request only gets the HTML. The browser then requests every CSS file, script, image and font the HTML refers to, and scripts can make their own API calls. Each file is a separate request-response cycle.
Lesson: Watching requests in browser dev toolsIt turns the exact request the browser sent into a curl command. I can replay it in the terminal, change one header or value at a time to find a bug, and give the backend team a request they can run themselves. I remove cookies and tokens before sharing it.
Lesson: Watching requests in browser dev toolsEither dev tools was opened after the request happened, the page navigated away and Preserve log was off, or a filter such as Fetch/XHR is hiding it. A file served from the browser's cache still appears, marked (disk cache) or (memory cache). Opening the tab first, ticking both boxes, choosing the All filter and reloading shows everything.
Then no connection is attempted at all, and the browser shows something like DNS_PROBE_FINISHED_NXDOMAIN. I would check the spelling, the internet connection and the name with nslookup, and try another resolver such as 8.8.8.8 to see whether my resolver is the problem.
I would open the Network tab and look at the Timing view of the slow request. Long DNS, connection or SSL phases point at the network or distance; a long "Waiting for server response" points at the server; a long download points at a large response.
Lesson: Practice: how the web worksNowhere: the browser keeps it and uses it to scroll to a part of the page; it is never sent to the server. That is why a # inside a value must be encoded as %23.
One server machine often hosts many websites on a single IP address. The TCP connection only carries the address and port, so Host tells the server which site the request is for. Without it, an HTTP/1.1 server answers 400 Bad Request.
Header names are not: Content-Type and content-type are the same header, and HTTP/2 even sends all names in lowercase. Values can be case-sensitive, for example tokens, so I copy them exactly.
If it is too small, the server reads only part of the body, usually fails to parse it and answers 400; the leftover bytes can even be mistaken for the start of a next request. If it is too large, the server keeps waiting for bytes that never come until it times out. That is why we let tools compute it.
PUT replaces the whole resource with the body, so the body must hold every field. PATCH changes only the fields it contains. To change one price I send PATCH /products/16 with {"price":1299.00}; with PUT I would have to send the full product.
The HTTP standard gives a GET body no meaning, so servers, proxies and caches may ignore it or reject the request. I put GET inputs in the path and query string, and if the input is too large or secret, the endpoint should use POST.
Lesson: GET, POST, PUT, PATCH and DELETECancelling has business rules, like refunds and putting stock back, and the order must remain for history, so I would not use DELETE. I would use POST /orders/16/cancel as an action, or PATCH /orders/16 with {"status":"CANCELLED"}. The server checks the current status and answers 409 Conflict if the order is already cancelled or shipped.
Safe means the request only reads and asks for no change, like GET. Idempotent means repeating the request leaves the server in the same state as sending it once. PUT and DELETE are idempotent but not safe; every safe method is also idempotent.
Lesson: Safe and idempotent methodsNot by definition. A PATCH that sets fields, like {"price":1299.00}, behaves idempotently, but a PATCH that says "add 5 to stock" does not. Because the standard does not promise it, clients should not retry PATCH automatically.
The server saves each key with the result of the first request, usually for a limited time such as 24 hours. If the same key comes again, it returns the saved result without repeating the work. It should also reject the key if it comes with a different body, because that is a client bug.
Lesson: Safe and idempotent methods1xx informational, 2xx success, 3xx redirection, 4xx client error and 5xx server error. The first digit already tells a client what to do: use the result, look elsewhere, fix the request, or retry later.
Lesson: Status code families: 2xx, 3xx, 4xx and 5xxWhen the request created a new resource, usually a POST to a collection. I return 201 with a Location header pointing to the new item and the item in the body. Reads and updates use 200.
Clients, monitoring, caches and retry logic all decide from the status code. A 200 with an error in the body gets cached, counted as success and never retried or alerted on. The correct code lets every tool handle the problem without reading my custom JSON.
Lesson: Status code families: 2xx, 3xx, 4xx and 5xxThe server sends an ETag with the resource. Next time the client sends it back in If-None-Match; if nothing changed, the server answers 304 with no body, and the client reuses its saved copy instead of downloading it again.
curl -d?Because -d labels the body application/x-www-form-urlencoded by default. The server reads Content-Type, sees form data instead of JSON and refuses. Adding -H "Content-Type: application/json", or using --json, fixes it.
It holds a URL. After 201 Created it is the address of the new resource, so the client can fetch it without building the URL. On a 3xx redirect it is where the client should go next.
For years custom headers were marked with X-, like X-Request-Id, to show they were not standard. The IETF dropped that advice in 2012 because such headers often became standard later, so new headers like Idempotency-Key have no prefix, but many old X- headers are still in use.
-i and -v?-i adds the response status line and headers to the output. -v shows the whole exchange: curl's connection notes, the request headers it sent and the response head. I use -i to check results and -v to debug what my request really contained.
curl behave strangely in Windows PowerShell?In Windows PowerShell 5.1, curl is an alias for Invoke-WebRequest, a different command with different options, so I type curl.exe. PowerShell 5.1 also strips double quotes from arguments to native programs, so I send JSON from a file with --json "@body.json".
-L, -s and -o do?-L follows redirects until the final response. -o file writes the body to a file. -s hides the progress meter and error messages, which is useful in scripts; I add -S too so real errors still show.
GET, HEAD and OPTIONS are safe, meaning read-only, and so also idempotent. PUT and DELETE are idempotent but not safe. POST is neither, and PATCH is not guaranteed to be idempotent.
Lesson: Practice: HTTP requests and responsesEvery tool in the chain reads the status code: client libraries, caches, retries, monitoring and load balancers. With 200 for errors, failures get cached, counted as success and never alerted on.
Lesson: Practice: HTTP requests and responsesEach lesson has quizzes, practice and more interview questions on the same topic.
Open the first lesson