Lesson 29 of 30
Every lesson in this track has covered one piece of the methodology or one piece of a worked example. This is the whole thing, start to finish, on a single realistic prompt — the interview framework applied in order, out loud.
14 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
Question 1 of 3
Why does the real-time layer in the walkthrough use SSE instead of WebSockets for the new-posts notification?
Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
This lesson doesn't teach a new concept. It's the synthesis: a full, realistic mock interview transcript for the prompt "Design the frontend for a Twitter-like feed," narrated phase by phase using the interview framework this track opened with — clarifying requirements, rough estimation, an architecture sketch, the data/API/caching layer, and the real-time consideration. Every decision below reuses a concept this track already built, named explicitly at the moment it applies, the way it should actually sound in a real 40-minute round.
Phase 1 — Clarifying requirements. Candidate: "Before I sketch anything — is this web, mobile, or both? Does the feed need to work offline, even in a limited read-only way? And when a followed account posts something new, does it need to appear in real time, or is a manual refresh acceptable?" Interviewer: "Web only, no offline requirement, and yes — new posts from followed accounts should surface without a manual refresh." That last answer already tells the candidate the real-time question later in the round is going to matter.
Phase 2 — Rough estimation. A brief, qualitative pass, not a precise calculation: a feed like this serves a read-heavy workload (far more scrolling and viewing than posting), each page of the feed needs to load fast on a cold start, and the dataset it scrolls through is effectively unbounded and constantly growing. That shape — read-heavy, unbounded, growing — is what rules a few architectural options in and out before the sketch even starts.
Phase 3 — Architecture sketch. This is where the earlier component-architecture reasoning comes in: a top-level Feed container owns the paginated list of post ids and the fetching logic; each Post renders from a normalized store lookup by id, not from a full post object passed down through props, so the same post rendered in the feed and in a post-detail view stays in sync automatically. A NewPostsBanner sits above the list, decoupled from Feed's scroll state, ready to react once the real-time layer (phase 5) has something to tell it.
Phase 4 — Data, API, and caching layer. The API tradeoff here favors a simple, purpose-built REST endpoint over GraphQL's flexibility — the feed has one well-known shape, so overfetching-avoidance isn't buying much, and a dedicated endpoint keeps caching simpler. Pagination is cursor-based, not offset — this dataset has posts constantly inserted at the front, exactly the case where offset silently shifts rows between requests. And the cache is normalized: each post is stored once, keyed by id, so a like or edit made from the post-detail view is reflected instantly back in the feed, without a second fetch.
Phase 5 — The real-time "new posts" consideration. Circling back to what the interviewer flagged in phase 1: new posts shouldn't auto-insert at the top while someone is mid-scroll, since that yanks their reading position out from under them — the "N new posts" banner pattern from this track's news-feed lesson is the right move here. And the mechanism behind that banner is a real-time-choice decision on its own: the feed doesn't need a bidirectional channel, since the client never pushes anything back over it, so SSE is the lighter, sufficient choice over a WebSocket — the banner lights up when a server-sent event says new posts exist, without opening a channel the client will never write to.
Phase 1: Clarifying requirements — asking about platform, offline needs, and real-time expectations before designing anything.
"Design a social feed" is one of the most commonly asked frontend system design prompts precisely because it touches nearly everything this track covers at once — this walkthrough is what a strong, structured, complete answer to it actually sounds like end to end.