How the interviewer opens it
“Design an RSS reader that collects updates from external feeds and tracks each subscriber's unread items. Balance update freshness against source request limits and service cost.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- User actions and feed formats
- Users and subscriptions
- Feed scale and active feeds
- Freshness
- Source limits
- Read and write traffic
- Response sizes and retention
- Latency
- Consistency, availability, and durability
- Content behavior and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Subscribe to and unsubscribe from RSS and Atom feeds.
- View recent items from one feed or a combined timeline.
- Mark individual items as read or unread. Mark all current items in one selected feed as read.
- Collect feed updates within freshness targets when source limits permit.
Usually out of scope
- Extract full articles from linked websites.
- Search for or recommend articles.
- Support private feeds that require source credentials.
- Keep items beyond the retention period.
What interviewers ask about
- Feed update times and source limits
- One source can host many feeds. Freshness targets compete with shared request limits, and quiet feeds can consume requests without producing new items.
- Repeated, revised, and missing items
- Feeds provide weak identity and limited history. Retries can create duplicates, while a crash or long outage can permanently hide items.
- Unread items across subscribers and devices
- Popular feeds make per-subscriber writes expensive. Individual changes, per-feed mark-all-read, and device retries must agree about which items remain unread.
Common mistakes
- Create one fetch schedule for every subscription instead of every distinct feed.
- Assume conditional requests remove source request limits.
- Choose a fixed interval without checking its cost or freshness.
- Copy every new item into every subscriber's unread list.
- Treat a mutable publication date as an item identity or read boundary.
- Assume feeds expose complete history after an outage.
The bar by level
- Senior (L5/E5)
- Derives the poll budget and identifies impossible freshness targets. Designs bounded fetch recovery and atomic ingestion. Handles watermark exceptions, per-feed mark-all-read, and concurrent device changes.
- Staff (L6+/E6+)
- Defines service behavior when source limits defeat freshness targets. Addresses ambiguous identity and missing source history. Bounds timeline cost, count maintenance, and read-state cleanup. For the two-region follow-up only, the candidate defines feed ownership and read consistency during a network partition.