Created
November 19, 2025 14:34
-
-
Save jacobsapps/9f42a4e963736f28484e54f0eb71ceef to your computer and use it in GitHub Desktop.
News Feed System Design Practice
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ## News Feed System Design Practice | |
| **Candidate:** Clarifies that the feature integrates into the existing Meta app, asks about networking style (REST/gRPC/GraphQL) and the boundary between iOS and backend responsibilities. | |
| **Interviewer:** Confirms integration, explains that the app uses GraphQL over HTTP with generated Swift models, and that the candidate can describe backend touchpoints as needed. | |
| **Candidate:** States initial assumptions: no ads in v1, infinite scroll with paginated data, no on-device feed persistence yet, but feature flags/analytics hooks are required. | |
| **Interviewer:** Accepts assumptions and requests an explicit list of functional and non-functional requirements. | |
| **Candidate:** Defines requirements—feed supports text/image posts with like/comment/share, infinite scroll, pagination, 60 FPS target, skeleton loaders, aggressive prefetching, out-of-scope posting/ads/offline. | |
| **Interviewer:** Approves scope and asks for architecture/data-flow details. | |
| **Candidate:** Outlines GraphQL contracts: feed query returning batches of ~20 items keyed by cursor/ID, mutations for likes/comments/shares routed through an optional sync service to handle retries; highlights that actions should persist even if the app closes mid-request. | |
| **Interviewer:** Requests the high-level client architecture. | |
|  | |
| **Candidate:** Presents module diagram—`FeedImpl` implements the feature while exposing `FeedAPI` so other modules depend only on the interface. Emphasizes need for modularity given a 25-person pod. | |
| **Interviewer:** Asks for internal design details. | |
|  | |
| **Candidate:** Walks through architecture: networking service handles GraphQL queries/mutations, sync service optionally queues mutations, pagination manager issues cursor queries, standalone prefetcher grabs upcoming content, repository abstracts data access for MVVM layer, `FeedViewController` hosts a diffable `UICollectionView` with text/image cells, UI library supplies shared components, notes Texture as future option if UIKit can’t hold 60 FPS. | |
| **Interviewer:** Selects pagination/prefetching for a deep dive. | |
| **Candidate:** Describes cursor-based pagination keyed by feed-item IDs, fetching 20 items per request, adjusting prefetch distance based on scroll velocity, using skeleton rows if users outrun network, metadata fetched ahead while images are cached via the prefetcher. | |
| **Interviewer:** Requests failure-handling strategy. | |
| **Candidate:** Discusses two approaches: (1) optimistic UI with immediate rollback/toast on failure, (2) full sync service persisting pending mutations with exponential backoff; highlights logging/observability needs and suggests starting with the simple version unless a proven sync service already exists. Explains surfacing “no network” UI if feed fetching stalls. | |
| **Interviewer:** Asks for final summary. | |
| **Candidate:** Recaps: MVVM + repository + diffable collection view, skeleton loading + prefetching to maintain 60 FPS, GraphQL pagination plus mutations routed through optional sync service, no on-device feed persistence in v1, ads can later be modeled as feed cells, UIKit-first with possible Texture fallback. Mentions future work (posting flows, comment drill-ins, analytics). | |
| **Interviewer:** Ends interview and later provides feedback separately. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment