Web Fundamentals
Every technical interview starts with "what happens when you type a URL". Walk the full network lifecycle, compare API architectures, decode status codes and survive the security questions.
URL parsing
The browser splits the address: scheme (https), host (google.com), port (443 default), path, query, fragment. HSTS list check: if google.com is on the browser's preloaded HSTS list, plain http:// is upgraded to https:// before any request is made.
Likely follow-up: 'What's the difference between http:// and https://?' — HTTPS = HTTP inside TLS: same semantics, encrypted and server-authenticated channel.
DNS resolution
Hostname → IP, checked through caches in order: browser cache → OS resolver cache → recursive resolver (ISP or 8.8.8.8) → root servers → .com TLD → authoritative nameserver, which returns an A (or AAAA) record. Each level caches per its TTL.
Likely follow-up: 'Which record maps a domain to an IP?' — A (IPv4) / AAAA (IPv6); CNAME aliases one name to another; MX is mail.
TCP three-way handshake
Client sends SYN (with initial sequence number), server answers SYN-ACK, client replies ACK. Now both sides agree on sequence numbers and the connection is established. If the hostname is fresh in DNS cache, HTTP/3 (QUIC over UDP) may skip TCP entirely and combine handshake + encryption.
Likely follow-up: 'Why three packets, not two?' — Both sides must confirm both directions work: SYN proves client→server, ACK proves server→client, and the server's SYN lets the client prove client→server too.
TLS handshake
Client sends supported ciphers + SNI (server name indication); server returns its certificate; the browser validates the chain against trusted CAs, checks expiry and hostname match; key exchange (ECDHE) establishes session keys; both sides switch to encrypted application data. TLS 1.3 does this in a single round trip.
Likely follow-up: 'What does the certificate actually prove?' — That the public key in it belongs to google.com, vouched by a CA chain the browser trusts — it prevents man-in-the-middle substitution.
HTTP request
Browser sends GET / HTTP/1.1 (or HTTP/2 binary frames on one multiplexed connection) with headers: Host, User-Agent, Accept, cookies, Accept-Encoding (enables gzip/brotli compression), and connection reuse hints.
Likely follow-up: 'HTTP/1.1 vs HTTP/2?' — 1.1 uses one request per connection (head-of-line blocking, so browsers open 6+ connections); 2 multiplexes many streams over one connection with header compression.
Server-side processing
Load balancer → web/app server → application logic → (cache check → database query) → response. Static assets may come from a CDN edge instead of the origin. Status line + headers + body come back: 200 OK with HTML, or 301/302 redirect, or 404/500 errors.
Likely follow-up: 'Where do cookies fit?' — Server may set Set-Cookie; the browser stores it and attaches it to every subsequent request to that domain — the mechanism behind sessions.
Parsing & rendering pipeline
HTML → DOM tree; CSS → CSSOM; both → render tree → layout (geometry) → paint → composite. The parser pauses on <script> (unless defer/async) and on blocking CSS. Subresources (JS, images, fonts) trigger their own fetches. Hydration follows for SSR frameworks.
Likely follow-up: 'defer vs async scripts?' — async: download in parallel, execute immediately when ready (order not guaranteed); defer: download in parallel, execute after parsing in order.