All jobs / Frontend / web developer

Web Fundamentals interview questions

Web Fundamentals questions a Frontend / web developer can be asked, from first job to senior. Open one to see the strongest answer and why it works.

  1. Walk me through what happens between typing a URL and seeing the page.

    The strongest answer: DNS turns the name into an IP, the browser opens a TCP and TLS connection, sends an HTTP request, then parses the HTML, fetches the CSS, scripts and images it references, and renders

    Why it works: Exactly — name lookup, connection, request, response, render. Each step is a place a slow or broken page can be diagnosed.

    • Lookup, connect, request, render.
    • DNS: name to IP address.
    • TCP plus TLS, then the HTTP request.
    • HTML parsed; subresources fetched; page painted.

  2. View Source on your SPA shows an almost empty page with one div, but the Elements panel shows the full UI.

    Why do the two differ, and why does it matter?

    The strongest answer: View Source is the HTML the server sent; the Elements panel shows the live DOM after scripts changed it. Anything that doesn’t run our JavaScript sees only the first one

    Why it works: Right — source is the response, the DOM is the live tree. Crawlers, link previews and slow devices may only get the response.

    • Source is the response; DOM is live.
    • View Source: what the server sent.
    • Elements: the tree after scripts ran.
    • Ask who only sees the first.

  3. Remember a UI theme versus send a session id to the server — where does each go, at a basic level?

    The strongest answer: Theme can live in localStorage; session/auth belongs in an httpOnly cookie (or equivalent), not readable JS storage

    Why it works: JS-readable storage is fine for preferences and a theft target for sessions.

    • Preferences vs credentials are different stores.
    • localStorage: non-secret UI state.
    • Session: httpOnly Secure SameSite cookie.
    • Never log tokens.

  4. The API returns 401 versus 404 versus 503. What does the UI do differently?

    The strongest answer: 401 → sign-in or refresh; 404 → not found; 5xx → backoff and a human message — don't treat every status as one Error

    Why it works: Status codes are UX. Mixing them trains users to ignore errors and can lock people out.

    • Map status to a next step.
    • 401: session.
    • 404: missing resource.
    • 5xx: retry with backoff, no stack traces.

  5. A script tag in the head is delaying first paint. What are your options, and how do defer and async differ?

    The strongest answer: A plain script blocks parsing while it downloads and runs. defer downloads in parallel and runs in document order after parsing; async runs whenever it arrives, so only for independent scripts

    Why it works: Exactly — parsing is what the script blocks. defer keeps order and waits for the document; async gives up order for speed.

    • Don’t block the parser.
    • Plain script: parsing stops.
    • defer: parallel download, ordered, after parsing.
    • async: independent scripts only.

  6. A JSON POST from the SPA to api.other.com triggers an OPTIONS request. How do you explain it?

    The strongest answer: Cross-origin non-simple requests preflight; the server must allow origin, method, and headers — the frontend cannot turn CORS off

    Why it works: Preflight is the browser asking permission before a credentialed or content-typed cross-origin POST. Fix it on the API.

    • CORS is a browser rule the server satisfies.
    • JSON POST is usually non-simple → OPTIONS.
    • Allow origin, method, headers on the API.
    • Don't 'fix' it in the client with no-cors or plugins.

  7. A web editor must keep long drafts with pasted images on the device so a dropped connection or a closed tab loses nothing.

    Where in the browser do you store them, and what do you watch for?

    The strongest answer: IndexedDB for the drafts — asynchronous, structured, holds blobs — with quota errors handled and a sync to the server when online; localStorage is synchronous, string-only and small

    Why it works: Exactly — IndexedDB is built for large structured data off the main thread. Storage can still fill up or be evicted, so handle the error and sync.

    • Match the store to the data.
    • Large or binary: IndexedDB.
    • Handle quota errors and eviction.
    • Sync to the server when online.