A personalized home page is a viewer-scoped composition of independently loadable modules. The service chooses eligible modules and issues a versioned layout receipt; the browser validates that receipt, reserves every slot, schedules compatible renderers, and lets each slot advance without changing order or crossing the viewer's cache boundary.
A static marketing page can be cached as one document. A personalized discovery page cannot. One person may see “Continue watching,” another may see “New near you,” and an anonymous visitor may see a public editorial collection. The modules may depend on different services, images, experiments, permissions, and freshness rules.
The difficult part is not making a responsive card grid. It is preserving one coherent page while composition, module data, images, experiments, consent, and navigation evolve at different speeds.
Clarify what the home page is allowed to decide
Start by listing module families: hero, continue activity, recommendations, editorial shelf, live event, recently viewed, saved items, category shortcuts, promotion, and account notices. Ask which modules are personalized, which are public, which are mandatory, and which may disappear when empty or unavailable.
Clarify whether the service controls eligibility and order only, or also supplies layout spans, headings, actions, and data endpoints. Define a strict vocabulary. A server may request media-shelf@3; it must not send arbitrary JavaScript, CSS, HTML, or an internal React import path.
Write measurable budgets for shell response time, first useful module, image bytes, layout movement, module timeout, simultaneous fetches, total loaded modules, renderer-version mismatch, experiment exposure, and recovery after one service fails. “Make discovery feel fast” is not a testable requirement.
The public interview prompt
Design a responsive personalized home and discovery page for signed-in and anonymous visitors. It renders heterogeneous modules selected by a composition service, supports experiments and ranking, isolates partial failures, and remains useful on slow or intermittent networks.
Explain:
- module descriptors, layout receipts, viewer scope, renderer versions, and experiment assignments;
- the boundary between server-owned eligibility and browser-owned interaction and rendering;
- shell rendering, module scheduling, geometry reservation, image priority, and stale-response guards;
- public, reusable, cohort, and viewer-private cache layers;
- independent loading, empty, timeout, incompatible, offline, and retry states;
- meaningful DOM order, headings, landmarks, focus, touch targets, localization, and reduced motion;
- assignment versus exposure analytics, consent, privacy, security, observability, and rollout;
- tests that prove stable slots, stable assignments, correct cache scope, and graceful degradation.
What the premium solution covers
The complete solution defines a constrained composition contract and follows one layout receipt from the public shell through prioritized module hydration. It shows how a magazine-like page can fill without moving its registration marks, how one experiment assignment travels through a plugboard, how cache strata prevent identity leakage, and how a failed tile remains local. A deterministic lab turns module and network assumptions into transfer, concurrency, and useful-paint estimates.