Meta JavaScript Frontend Developer Interview Questions & Answers

At a high level, the frontend should let users open Stories, move through one creator’s items, continue to the next creator, and return to the feed without losing context. I would use the diagram’s CSR single-page design with an initial HTML shell, route-based code splitting, and a StoryViewer component tree. URL, local, shared, remote, and persisted browser state have separate jobs. Media is prefetched carefully. The main trade-off is smooth playback versus extra bandwidth and memory.

The goal is to make Instagram Stories feel fast and continuous in the browser. A user can enter from the Stories tray, an avatar, or a deep link. The main challenge is coordinating media playback, progress timing, navigation, network work, and saved position without wasting bandwidth or memory. I would explain the design through rendering, routes and components, state, data flow, failure handling, accessibility, and safe release controls.

• Should Stories work well on slow mobile networks and desktop browsers?
• How much offline viewing should the browser support?
• Should users resume the same Story after reopening the viewer?
• Are keyboard, screen-reader, RTL, and reduced-motion behaviors required?
• Can the browser prefetch a few upcoming Stories?

The browser gets static assets through the CDN and loads the HTML shell plus JavaScript from the web application path. I would use the diagram’s CSR single-page approach with hydration of the initial shell. After that, route changes stay inside the browser.

Route-based code splitting loads only JavaScript needed for the current route. The service worker can cache the shell, selected data, and media for offline use.

The main routes are /, /stories, /stories/:userId, and a not-found route. The Story Viewer Page contains StoryViewer, ProgressBar, MediaPlayer, TapZones, TopBar, ReplyBar, and ErrorBoundary.

URL state keeps userId, storyIndex, source, and ref. Local UI state keeps playing, muted, fullscreen, loading, error, reply, and progress values. Shared client state keeps activeUserId, storiesByUser, seenMap, theme, and accessibility preferences.

Remote data contains users, Story metadata, media URLs, and viewer interactions. IndexedDB keeps cached Stories. localStorage keeps preferences. sessionStorage keeps navigation state for session restore.

The tray uses GET /api/v1/feed/stories. Opening a creator uses GET /api/v1/stories/{userId}. Story data includes fields such as storyId, type, media URL, thumbnail URL, duration, timestamp, and seen state.

MediaPlayer loads image or video media from the Media CDN. The browser prefetches the next two or three Stories from the current creator and the first Story from following creators. When progress finishes, it moves to the next Story. After the creator ends, it can move to the next user’s first unseen Story.

Views use POST /api/v1/stories/view. Replies use POST /api/v1/stories/reply. Analytics uses POST /api/v1/analytics/event. Analytics is separate from viewer correctness.

Initial loading shows a skeleton. Partial data shows available Stories. An empty result shows the empty state. Media loading shows buffered progress. A media error can retry, skip, or use a fallback. An expired Story shows the expired state.

On slow or offline networks, cached Stories can remain available with an offline banner. When navigation makes an old request unnecessary, the browser should cancel that work when possible and ignore late results that no longer match the active Story. Background tabs pause playback and preserve position. Resumed sessions restore that position.

The viewer revokes object URLs after dismissal and releases media on unload. It also limits decoded frames to control memory.

The viewer uses ARIA roles, labels, live regions, visible focus, and a focus trap. Arrow keys move between Stories. Space or Enter controls playback. Escape exits. Responsive layouts support phones, tablets, and desktop screens. RTL layouts and locale-aware strings support different languages.

Client error reporting captures JavaScript errors and rejected work. Performance monitoring uses Core Web Vitals and custom metrics. Feature flags support gradual rollout, and a remote kill switch supports safe rollback.

At a high level, I would make locale part of the product state and load only the translations each route needs. The first page can use SSR or SSG, then hydration attaches browser behavior. The router preserves locale during navigation. The client i18n runtime resolves message IDs, formatting, plural rules, fallbacks, and RTL layout. Bundles are cached through the CDN, browser cache, and service worker. The trade-off is better speed and offline support versus more cache and version complexity.

The goal is to give every user the same product experience in their language and regional format. The hard part is keeping many routes and independently developed components consistent. We also need small bundles, safe fallbacks, RTL support, offline behavior, and smooth locale changes. I would divide the design into locale selection, rendering, message loading, formatting, delivery, and safe operations. The browser owns locale state and presentation. Remote systems stay outside the frontend boundary.

• Do we need SSR, SSG, or both for first-page rendering?
• Must previously loaded translations work offline?
• How many locales and RTL languages must we support?
• Can users choose a locale, or only use automatic detection?
• Can components and translation bundles be released at different times?

I would resolve locale in a clear order. The URL wins first, such as /fr/products. Next comes the user setting. Then we can use the Accept-Language header or device locale.

The selected locale becomes active client state. It can also be saved in a cookie, localStorage, or IndexedDB. Applying it early avoids briefly showing the wrong language.

The diagram uses hybrid SSR or SSG with hydration. SSR or SSG provides HTML and critical messages for the first page. Hydration means attaching browser behavior to that HTML.

The router keeps locale in the path or domain. During navigation, it preserves the locale and can prefetch the next route's code and messages. The page shell controls language, direction, font, and other global UI settings.

Independently developed components and the design system use message IDs instead of hard-coded translations. The client i18n runtime owns active locale state, message lookup, ICU message formatting, plural and gender rules, and fallback behavior.

For example, ar-EG can fall back to ar, then en. Numbers use Intl.NumberFormat. Dates use Intl.DateTimeFormat. Relative time uses Intl.RelativeTimeFormat. Lists use Intl.ListFormat. Interpolated values are escaped by default, so translated content does not become raw HTML.

Translation resources are split by route and locale. Code splitting means loading only the code and messages needed now. A dynamic import loads the locale bundle, and an in-memory cache keeps it ready for reuse.

The delivery path uses versioned bundles, CDN delivery, browser caching, and a cache-first service worker. Cache keys include locale, namespace, and version. This protects compatibility when a component and translation bundle are released at different times. Previously cached locales can still work offline.

While messages load, the UI can show a skeleton. If some keys are missing, available content can still render while the fallback chain supplies safe text. Missing keys and failures go to error reporting and monitoring.

RTL pages use dir="rtl", logical CSS such as margin-inline, BiDi isolation, and mirrored directional icons. Accessibility checks cover lang, dir, labels, screen-reader text, and focus order.

Developer tooling extracts message IDs from JavaScript, TypeScript, JSX, and HTML. Typed IDs and CI checks catch missing or unused messages. Translation Management handles translation review and approval. Pseudolocales such as en-XA and ar-XB expose layout and RTL problems before release.

Testing covers message units, LTR and RTL visuals, and end-to-end locale switching. Analytics and monitoring track missing keys and locale usage. Success metrics include coverage, missing rate, and bundle size. Feature flags support rollout by locale and quick rollback. A strangler migration can move legacy messages gradually to ICU formatting. Auth or identity and Content or CMS remain external boundaries rather than browser-owned services.

At a high level, this dashboard helps an analyst see where new users register and how that changes over time. I would use CSR with a pre-rendered shell, then load map, summary, and location data in the browser. Filters and map state live in the URL, while remote data uses a client cache. Old requests are canceled when filters change. The main trade-off is freshness versus speed, so cached data can stay visible while a background refresh runs.

The goal is to help an analyst understand where newly registered users come from. The hard frontend problem is keeping filters, map zoom, URL state, cached remote data, tables, and failure states consistent. I would use a pre-rendered application shell and CSR for the interactive dashboard. Remote systems stay outside the frontend boundary. I would explain the design through routes and components, state ownership, data fetching, resilience, accessibility, and performance.

• How fresh must registration data be?
• Which filters must be shareable through the URL?
• How large can the location dataset become?
• Do users need the last viewed data while offline?
• What accessibility and localization requirements apply?

The main view is /dashboard/map. The shell also links to /dashboard, /dashboard/table, and /dashboard/export. The global filter bar controls time range, granularity, location, source, plan, and other filters.

Those values, plus map view, sorting, and paging, belong in URL state. This makes a filtered dashboard shareable and bookmarkable.

The dashboard shell owns navigation and the global filter bar. The map page contains the map widget, summary cards, recent locations, and a selected-location detail panel. The recent-locations table is also a keyboard- and screen-reader-accessible non-map view.

Each widget handles its own loading or failure state. This isolates failures, so one broken widget does not have to remove the whole dashboard.

Temporary UI state holds open panels, the active tab, and map interaction state. Shared client state holds the user profile, permissions, normalized cached data, update timestamps, and feature flags. IndexedDB or localStorage stores saved views, offline data, and user preferences.

Remote results remain remote data, not permanent browser truth. Cached results can become stale, meaning they may be older than the newest server result.

The browser requests aggregate counts and per-location data from the Analytics API. Filter changes start a new request and cancel old work with AbortController. The client also ignores results that no longer match the active filters.

At low zoom, the map shows clustered or aggregated counts. More detail appears as the user zooms in. The Geo API supports geographic lookup, while the Map Tiles CDN supplies map tiles or styles.

Background refresh revalidates cached data without first clearing useful content. HTTP caching and the browser cache own reusable network responses and static assets. The service worker owns app-shell and offline fallback behavior.

Initial and loading states use a shell or skeletons. Empty means no users match the filters. Partial means some widgets succeeded while others failed. Stale keeps the last useful data visible with a freshness indicator.

Malformed data uses a safe fallback and is reported. Aborted requests do not show an error. Offline mode shows cached data when available. Permission-denied views hide sensitive details, while the remote system remains responsible for real authorization.

The page uses semantic HTML, ARIA where needed, keyboard navigation, focus management, screen-reader labels, high contrast, and localization support. Desktop can use several columns, tablet can stack sections, and mobile uses a simpler single-column layout.

For large datasets, I would cluster map markers, virtualize long tables, lazy load heavy widgets, limit DOM nodes, and clean up event listeners. Code splitting means loading only the JavaScript needed for the current route or widget.

I would measure network delay with DNS, connection, TTFB, transfer, and API timing. Processing timing covers parsing, validation, transformation, and state updates. Paint timing covers style, layout, paint, composition, FPS, and long tasks. Error reporting, Web Vitals, feature flags, gradual rollout, and a kill switch support safe releases.

At a high level, the page must keep live video smooth while comments arrive quickly and sometimes out of order. I would use a CSR single-page app on /watch/live/{videoId} with separate Video Player, Comment Composer, Comment Stream, and Moderation Actions. Initial history uses the Fetch Adapter, while incremental events use WebSocket or SSE. Shared client state orders and deduplicates comments. Virtualization, batching, reconnect, safe rendering, and polite live announcements protect performance and accessibility, with some extra client complexity.

The goal is to let viewers watch Facebook Live and use comments without hurting video playback or browser responsiveness. The difficult part is that comment events can arrive very quickly, arrive twice, arrive out of order, or stop during a weak connection. The browser may also be slow or running in a background tab. I would use a CSR single-page application. I would separate the video, composer, comment stream, moderation controls, state, and transport adapters. Remote systems stay outside the browser as clear external boundaries.

• Should comments default to top or live order?
• How much comment history should load initially?
• What offline reading and sending behavior is expected?
• Can the client use WebSocket or SSE for live updates?
• What accessibility and localization targets must we support?

The route is /watch/live/{videoId}. It opens the Facebook Live Video Page inside the browser SPA.

The Video Player handles HLS or DASH playback and reconnect feedback. The Comment Composer owns text, emoji, mentions, send, cancel, pending state, and retry feedback. The Comment Stream uses virtualization, scroll anchoring, and a new-comment indicator. Moderation Actions expose hide, report, block, and delete flows.

URL state stores videoId, top or live sorting, and the last seen cursor or timestamp. Local UI state stores composer text, focus, open panels, and compact layout choices.

Shared client state stores normalized comments, comment order, pending sends, connection status, feature flags, and locale. Remote data holds paginated history, incremental events, and user or session context. Persisted browser state keeps secure authentication data, optional drafts, the last position, and service-worker cache or offline data.

The Fetch Adapter loads initial history, pagination, and backfill. The Real-time Adapter subscribes through WebSocket or SSE and handles heartbeats, reconnect, subscribe, and unsubscribe.

Each comment uses commentId for identity. The client deduplicates by that id and orders accepted events by (serverTime, id). Because delivery can repeat, applying the same event twice must be safe. Gap detection finds missing events and starts a resync or backfill.

A new comment moves from Compose to Pending with optimistic UI. An acknowledgement moves it to Sent, then Posted. A hidden or deleted comment becomes a tombstone instead of silently changing identity.

If authentication expires, Facebook Auth handles login or token refresh. Pending work waits for recovery instead of pretending it succeeded. After reconnect, the client resumes from its last known position and backfills gaps when needed.

The stream virtualizes rows and batches UI work during bursts. If the viewer is not at the newest comment, scroll anchoring keeps the reading position stable. A new-comment indicator avoids forced scrolling. Under extreme rates, the view can reduce immediate rendering or summarize activity instead of painting every arrival.

Background tabs and slow consumers should reduce unnecessary painting and resync when active again. Text is escaped instead of inserting unsafe HTML. Keyboard navigation, focus management, labels, and polite ARIA live announcements keep the experience usable without overwhelming assistive technology.

Code splitting loads route and component bundles as needed. Assets use CDN delivery and browser caching. The service worker supports the static shell, offline data, and queued replay when browser lifecycle rules allow it. Error Reporting collects client failures. I would measure event-arrival-to-usable-paint, reconnects, drops, FCP, INP, and related page timings. Feature flags support gradual rollout, A/B tests, safe defaults, and rollback.