Web Fundamentals
This topic is not about one API but about the broad context front-end code lives in. A good engineer understands not only their JavaScript but the platform around it: how the browser turns markup into pixels, over which protocol data flies, why one image ships as JPEG and another as PNG, what makes a UI accessible, and how to test a component so it catches a regression.
Each layer here is a field of its own, asked in an interview as a separate block of questions, and nearly every one boils down to an engineering trade-off: speed versus reliability (TCP/UDP), size versus quality (formats), test speed versus coverage (snapshot/screenshot). The full map is below.
Topic map
- How the web platform works — the browser as a runtime, the HTML/CSS/JS split, the rendering pipeline, and semantic markup.
- Network protocols — HTTP and WebSocket over TCP, and the TCP vs UDP difference in reliability and overhead.
- Image formats — JPEG versus PNG, transparency and loss, modern WebP/AVIF, and vector SVG.
- Accessibility — keyboard operability, semantics and ARIA, focus management, contrast, and verification.
- Headless UI kits — libraries providing behavior and accessibility without imposing styles or markup.
- Component testing — snapshot versus screenshot, what each catches and where its limit lies.
Common traps
| Mistake | Consequence |
|---|---|
| Thinking HTTP runs over UDP | HTTP is over TCP; UDP is used by video, games, DNS |
| Swapping the reliability roles of TCP and UDP | TCP is reliable and ordered; UDP has no guarantees but low overhead |
| Calling WebSocket "request/response" | WebSocket is a full-duplex persistent connection |
| Thinking JPEG supports transparency | Transparency comes from PNG (and WebP/AVIF), not JPEG |
| Treating PNG as lossy or capped at 256 colors | That describes GIF; PNG is lossless and full-color |
Assuming aria-label on everything solves accessibility | First semantic HTML, keyboard, focus, contrast |
| Believing an automated audit proves accessibility | Automation catches only part; you need keyboard and a screen reader |
Removing focus with outline: none and no replacement | Keyboard users lose the visible focus |
| Thinking a headless kit imposes styles | The opposite — it gives behavior and a11y, the styling is yours |
| Expecting a snapshot test to catch a CSS regression | Snapshot is blind to visuals; that needs a screenshot |
Interview relevance
These questions separate an engineer with a broad view from a narrow "coder". The answer here is almost always a trade-off, and a strong candidate names both sides: "PNG is lossless with transparency but heavy; JPEG is light but lossy with no alpha channel — so photos in JPEG, logos in PNG".
Typical checks:
- The protocol layer: HTTP/WebSocket over TCP, the TCP vs UDP difference.
- Choosing an image format for the task and why WebP/AVIF win.
- What makes a UI accessible and that automation does not prove it.
- What a headless library is and why to reuse its a11y logic.
- How a snapshot test differs from a screenshot and each one's limit.
Common wrong answer: "accessibility is adding an aria-label to every element, and screen readers will work". In fact a flood of ARIA over non-semantic markup often hurts; you start with native elements, keyboard operability, focus management, and contrast, and add ARIA sparingly.