“Design YouTube’s watch page” is a senior+ frontend system-design prompt that tests how you decompose a heavy, multi-component page. Player, recommendations, comments, end-screen, mini-player, live chat — each is a non-trivial component, and the page has to feel snappy on a mid-range device. This guide covers what interviewers actually probe.
Components on the page
- Video player (HLS/DASH, ABR, captions, ads)
- Title, description, channel info, like/share
- Recommendations rail (right side)
- Comments section
- Live chat (if a live stream)
- Chapters / Transcript
- Mini-player on scroll
Loading priorities
Establish what is critical for the user’s first impression:
- Player frame and first frame of video — highest priority
- Title and channel
- Recommendations (so the user has options)
- Comments (below the fold; defer)
- Transcript / chapters (defer until requested)
Critical CSS inlined. Player JS prioritized. Comments and recommendations lazy-loaded after the player is interactive.
The player
- HLS / DASH adaptive streaming; Shaka Player or HLS.js for non-Safari
- Adaptive bitrate algorithm balances buffer health, bandwidth estimate, and screen size
- Ads are inserted via VAST/SSAI; player handles ad pods seamlessly
- Captions (sidecar VTT, multi-language, auto-generated fallback)
- Picture-in-Picture support via the browser API
- Video element timestamps drive everything else (chapter highlight, transcript scroll)
Recommendations rail
- Server returns ranked thumbnails + metadata
- Render skeletons immediately; swap as data arrives
- Lazy-load thumbnails with Intersection Observer
- Recommendation rotation as user scrolls or watches longer
Comments
- Lazy-load when scrolled into view
- Cursor-paginated; “Show more replies” pattern
- Sort: top, newest
- Live updates via WebSocket while watching
- (See the standalone comments-thread frontend interview question for the data model)
Live chat (live streams only)
- WebSocket to chat server
- Auto-scroll if user is at the bottom; pause if scrolled up
- Throttle render to 30fps under heavy chat load (1000+ msg/sec)
- Virtualize the message list
- Super Chat highlights, moderator messages, etc.
Mini-player
- Activates when user scrolls past the player
- Or when user navigates to a different page (Polymer-era YouTube popularized this)
- Persists video state across route changes (the video keeps playing)
- Implementation: hoist the video element to a portal that survives unmount/mount of the page component
State management
- Player state (current time, paused, volume, quality) is global — accessible to chapters, transcript, mini-player
- Auth and user data global
- Page-specific data (comments, recommendations) local to the page
- Pattern: small global store (Redux, Zustand, or Context) for cross-cutting state; React Query for server data
Routing and back/forward
- SPA navigation between videos — but the player should not unmount on every nav (mini-player pattern)
- URL parameters drive state (timestamp, list, autoplay)
- Browser back returns to the previous video, including its scroll position
Performance
- Critical metric: time-to-first-frame (the user sees something playing)
- Code-split aggressively — comments and live chat are large bundles
- Pre-fetch the next likely video on hover / focus
- Service Worker caches static assets and the player shell
- Minimize CLS — reserve space for thumbnails and ad slots
Mobile considerations
- Vertical layout: player → title → metadata → recommendations → comments
- Pinch-to-zoom video in fullscreen
- Battery-aware: lower frame rate on background tabs, pause when truly hidden
- Mobile data warning before high-quality stream
Accessibility
- Player has full keyboard control (Space, Arrow, F, M, C)
- Captions visible and stylable
- Transcript navigable with assistive tech
- Comments form is a labeled
<form>
What separates senior from staff
Senior: decomposes the page and discusses lazy loading. Staff: discusses the mini-player as a state-survival problem (portal hoisting), the player-state-as-global pattern, and the live chat throttling under load. Principal candidates touch on the recommendation telemetry feedback loop and the role of the watch page in YouTube’s engagement metrics.
Frequently Asked Questions
How do I handle ads without breaking the experience?
Server-side ad insertion (SSAI) gives a single seamless stream; client-side (CSAI) inserts ads at boundaries with brief pauses. Most large platforms use SSAI; CSAI is easier to implement.
What about the autoplay-next-video flow?
End-screen overlay 5 seconds before video ends; countdown to next; user can cancel. Implementation is mostly UI; the next video is pre-fetched.
How do I avoid jank when the recommendations rail loads?
Reserve the layout area; use skeleton placeholders that match final dimensions. Avoid loading data after the player has settled if you can request in parallel.