jacobsapps · November 19, 2025 14:43
diff --git a/gistfile1.txt b/gistfile1.txt
 ## News Feed System Design – Practice Transcript

 ### 1. Problem & Scope
 - **Interviewer:** *“Is this a standalone MVP or part of the main app? What infra are you leaning on?”*  
  **Candidate:** Integrating into the existing Meta app, using the shared GraphQL-over-HTTP stack with generated Swift models. Focus on iOS client, but define backend touchpoints as needed.
 - **Interviewer:** *“Any scope constraints?”*  
  **Candidate:** Ads, posting flows, and heavy offline persistence are out for v1. Must plug into feature flags, analytics, and the experimentation framework.

 ### 2. Functional / Non-Functional Requirements
 - **Interviewer:** *“List the requirements explicitly.”*  
  **Candidate:**  
  - Functional: endless feed of text & image posts, like/comment/share actions, consume-only (no drill-ins yet).  
  - Non-functional: 60 FPS scrolling, paginated fetching with aggressive prefetching, skeleton placeholders to hide latency, no local caching beyond potential action sync.  
  - Future extensibility reserved for ads, additional media types, and posting.

 ### 3. High-Level Design
 - **Interviewer:** *“Describe the network/API contracts and modular layout.”*  
  **Candidate:**  
  - GraphQL feed query returning batches (~20 items) via cursor/ID pagination; GraphQL mutations for likes/comments/shares routed through an optional sync service to survive app termination.  
  - Prefetch metadata ahead of media; actions should be resilient even if network drops.  
  ![Module boundary](modules.png)  
  - `FeedImpl` implements the feature; `FeedAPI` exposes the surface so other modules depend only on interfaces. Shared networking/DI/UI infrastructure is injected via this boundary.

 - **Interviewer:** *“Walk me through the internal layers.”*  
  **Candidate:**  
  ![Feed architecture](design.png)  
  - Networking service executes GraphQL queries/mutations; optional sync queue retries writes.  
  - Pagination manager issues cursor requests; standalone prefetcher grabs upcoming metadata/media.  
  - Repository mediates between data sources and MVVM UI.  
  - `FeedViewController` hosts a diffable `UICollectionView` with text/image cells supplied by the UI library. UIKit chosen for control; Texture is a fallback if 60 FPS becomes difficult.

 ### 5. Drill-Down Discussion
 - **Interviewer:** *“Explain pagination/prefetching in detail.”*  
  **Candidate:** Cursor-based pagination keyed by feed-item IDs; fetch 20 items per batch and schedule the next fetch when the user nears the end. Scroll velocity dictates how many items/pages to prefetch; metadata is always fetched ahead, media is preloaded via the image cache/prefetcher, and skeleton rows fill gaps if users outrun the network.
 - **Interviewer:** *“What happens when requests fail?”*  
  **Candidate:** Simple mode: optimistic UI with rollback + toast on failure. Advanced mode: persistent sync queue (e.g., Core Data) with exponential backoff and flush-on-foreground. Feed fetch failures raise a “no network” banner while allowing continued scrolling over skeleton placeholders.

 ### 5. Wrap-Up
 - **Interviewer:** *“Summarize the design choices.”*  
  **Candidate:** MVVM + repository for clarity, diffable collection view for smooth updates, skeleton loading + prefetching to maintain 60 FPS, GraphQL pagination plus mutations routed through optional sync service, no on-device feed persistence in v1, UIKit-first with Texture as contingency, ads/posting saved for future iterations.

 ### Interviewer Feedback (Meta Rubric)
 - **Problem Navigation:** Good job clarifying integration constraints and ruling out ads/posting, but the requirements discussion arrived piecemeal—next time enumerate functional/non-functional lists before diving deeper. Proactively surface analytics/feature flag hooks and ranking dependencies so the interviewer sees you steering scope end-to-end.

 - **Solution Design:** Clear module split (FeedAPI vs FeedImpl) and understandable MVVM/repository architecture. High-level flow covers pagination, sync, and UI concerns, but provide more detail on API contracts (GraphQL schema fields, cursor types, error payloads) and highlight how ads or other teams could plug into the feed later to show extensibility.

 - **Technical Excellence:** Strong discussion of prefetching, scroll velocity, skeletons, and optimistic UI vs sync queue trade-offs. To strengthen this pillar, add concrete technology choices (e.g., Combine vs delegation, image caching strategy, schema evolution) and cover a second deep dive (testing, experimentation, or instrumentation) so you demonstrate breadth.

 - **Technical Communication:** Diagrams and explanations were clear, but time management needs tightening—too much time on prefetching meant fewer minutes for other subsystems. Aim to summarize sooner, answer follow-ups concisely, and keep a running outline so both interviewer and candidate stay aligned on what’s been covered.
	## News Feed System Design – Practice Transcript

	### 1. Problem & Scope
	- Interviewer: “Is this a standalone MVP or part of the main app? What infra are you leaning on?”
	Candidate: Integrating into the existing Meta app, using the shared GraphQL-over-HTTP stack with generated Swift models. Focus on iOS client, but define backend touchpoints as needed.
	- Interviewer: “Any scope constraints?”
	Candidate: Ads, posting flows, and heavy offline persistence are out for v1. Must plug into feature flags, analytics, and the experimentation framework.

	### 2. Functional / Non-Functional Requirements
	- Interviewer: “List the requirements explicitly.”
	Candidate:
	- Functional: endless feed of text & image posts, like/comment/share actions, consume-only (no drill-ins yet).
	- Non-functional: 60 FPS scrolling, paginated fetching with aggressive prefetching, skeleton placeholders to hide latency, no local caching beyond potential action sync.
	- Future extensibility reserved for ads, additional media types, and posting.

	### 3. High-Level Design
	- Interviewer: “Describe the network/API contracts and modular layout.”
	Candidate:
	- GraphQL feed query returning batches (~20 items) via cursor/ID pagination; GraphQL mutations for likes/comments/shares routed through an optional sync service to survive app termination.
	- Prefetch metadata ahead of media; actions should be resilient even if network drops.
	![Module boundary](modules.png)
	- `FeedImpl` implements the feature; `FeedAPI` exposes the surface so other modules depend only on interfaces. Shared networking/DI/UI infrastructure is injected via this boundary.

	- Interviewer: “Walk me through the internal layers.”
	Candidate:
	![Feed architecture](design.png)
	- Networking service executes GraphQL queries/mutations; optional sync queue retries writes.
	- Pagination manager issues cursor requests; standalone prefetcher grabs upcoming metadata/media.
	- Repository mediates between data sources and MVVM UI.
	- `FeedViewController` hosts a diffable `UICollectionView` with text/image cells supplied by the UI library. UIKit chosen for control; Texture is a fallback if 60 FPS becomes difficult.

	### 5. Drill-Down Discussion
	- Interviewer: “Explain pagination/prefetching in detail.”
	Candidate: Cursor-based pagination keyed by feed-item IDs; fetch 20 items per batch and schedule the next fetch when the user nears the end. Scroll velocity dictates how many items/pages to prefetch; metadata is always fetched ahead, media is preloaded via the image cache/prefetcher, and skeleton rows fill gaps if users outrun the network.
	- Interviewer: “What happens when requests fail?”
	Candidate: Simple mode: optimistic UI with rollback + toast on failure. Advanced mode: persistent sync queue (e.g., Core Data) with exponential backoff and flush-on-foreground. Feed fetch failures raise a “no network” banner while allowing continued scrolling over skeleton placeholders.

	### 5. Wrap-Up
	- Interviewer: “Summarize the design choices.”
	Candidate: MVVM + repository for clarity, diffable collection view for smooth updates, skeleton loading + prefetching to maintain 60 FPS, GraphQL pagination plus mutations routed through optional sync service, no on-device feed persistence in v1, UIKit-first with Texture as contingency, ads/posting saved for future iterations.

	### Interviewer Feedback (Meta Rubric)
	- Problem Navigation: Good job clarifying integration constraints and ruling out ads/posting, but the requirements discussion arrived piecemeal—next time enumerate functional/non-functional lists before diving deeper. Proactively surface analytics/feature flag hooks and ranking dependencies so the interviewer sees you steering scope end-to-end.

	- Solution Design: Clear module split (FeedAPI vs FeedImpl) and understandable MVVM/repository architecture. High-level flow covers pagination, sync, and UI concerns, but provide more detail on API contracts (GraphQL schema fields, cursor types, error payloads) and highlight how ads or other teams could plug into the feed later to show extensibility.

	- Technical Excellence: Strong discussion of prefetching, scroll velocity, skeletons, and optimistic UI vs sync queue trade-offs. To strengthen this pillar, add concrete technology choices (e.g., Combine vs delegation, image caching strategy, schema evolution) and cover a second deep dive (testing, experimentation, or instrumentation) so you demonstrate breadth.

	- Technical Communication: Diagrams and explanations were clear, but time management needs tightening—too much time on prefetching meant fewer minutes for other subsystems. Aim to summarize sooner, answer follow-ups concisely, and keep a running outline so both interviewer and candidate stay aligned on what’s been covered.
No results found