Free lesson · ML System Design Interviews

Personalized News Feed: Problem & Discovery

Medium7 min readmachine-learningml-system-designinterview-prep

Introduction

Imagine you're at a massive conference with 10,000 people. Every attendee is talking, pitching projects, and networking. You can't listen to everyone. So what do you do? You choose to attend sessions and conversations based on:

• Topics you care about (your interests)
• People you know (your network)
• What's trending right now (what others find valuable)
• Time of day (morning keynotes vs. evening parties)

A personalized news feed does exactly this for social media. It's a ranking system that shows each user the posts most likely to engage them—a curated experience from millions of possibilities.

What We're Building

We're designing a system for a social media platform (like Facebook, LinkedIn, or Twitter) that decides which posts to show each user when they open the app. Instead of showing posts in chronological order (oldest to newest), we rank them by predicted engagement.

Business Goals

1. Increase user engagement – Users spend more time, click more, comment more
2. Maximize satisfaction – Show relevant, high-quality content
3. Balance fairness – Don't create filter bubbles that lock users into one viewpoint
4. Support creators – Help good content reach audiences without heavy spending

Why This Matters

• User value: Users see content they actually care about
• Creator value: Quality content gets visibility
• Business value: Longer sessions = more ad impressions = more revenue

Mock Interview: Problem Discovery

Exchange 1: Understanding Scope

Candidate: I need to clarify what we're personalizing. Are we building a feed for a new platform with millions of users, or optimizing an existing system?

Interviewer: Good question. Assume we're building the feed system for a Twitter-like platform with 10 million daily active users, 500 million posts per day, and existing infrastructure for storing user data.

Candidate: So we're ranking from 500 million posts to pick maybe 20-50 for a user's feed?

Interviewer: Exactly. We can't evaluate all 500M—we need a two-stage process. How would you approach it?

Exchange 2: Content Types

Candidate: What types of content are in the feed? Just text posts?

Interviewer: Good assumption to question. We have text posts, images, videos, retweets, and ads. Each has different engagement patterns. Would you treat them the same?

Candidate: No, video might get more engagement time, ads might have different metrics. Should we have separate models per content type, or one unified model?

Interviewer: That's a trade-off. One unified model is simpler to maintain but might lose nuance. Multiple models are more complex but specialized. What would you choose for a launch?

Candidate: For launch, I'd start with one unified model but include content type as a feature. As we scale, we can experiment with separate models.

Interviewer: Smart—defer optimization. Keep going.

Exchange 3: Ranking Criteria

Candidate: What does "engagement" mean? Just clicks?

Interviewer: What do you think matters?

Candidate: Probably multiple signals: clicks, likes, comments, shares. But they might have different weights. A share is probably more valuable than a like.

Interviewer: True. How do you weight them?

Candidate: We could set weights based on business goals—maybe 1x for clicks, 2x for comments (more effort), 3x for shares (viral). Or we learn them from data.

Interviewer: Learning from data is better. But notice the implicit assumption—you're counting binary events. What about a post someone reads for 5 minutes vs. scrolls past in 0.5 seconds?

Candidate: Good point. Maybe we should also track time spent, scroll depth? Those are implicit engagement signals.

Interviewer: Exactly. That's position bias—people see high-ranked posts longer, so they might engage more. How do you handle that?

Exchange 4: Real-Time vs. Batch

Candidate: When do we compute the feed? Real-time when the user opens the app, or pre-computed batches?

Interviewer: What's the trade-off?

Candidate: Real-time is fresher but slower. Batches are faster but outdated if a viral post drops.

Interviewer: Right. So a hybrid?

Candidate: Maybe pre-compute candidate lists in batch (which posts could be relevant), then rank them in real-time with fresh signals. Could be sub-second that way.

Interviewer: How often do you update the pre-computed candidates?

Candidate: Every few minutes or when a major event happens. And real-time ranking happens when the user requests the feed.

Interviewer: Good. What about users following trending hashtags?

Exchange 5: Personalization & Cold Start

Candidate: How do we personalize for brand-new users with no history?

Interviewer: That's the cold start problem. What's your approach?

Candidate: We could default to trending posts, popular creators, or content from people they follow. For recommendation, we might use content-based features (topic) if we don't have user behavior yet.

Interviewer: And for a new post with no engagement signals?

Candidate: Similar issue. We'd rely on author popularity, post features (topic, freshness), and content quality signals.

Interviewer: How do you measure content quality without engagement data?

Candidate: Maybe text quality (grammar, length), author history, or community flags. But initially, we'd show it to a small sample and let engagement signals guide it.

Interviewer: That's a bootstrap strategy. Good. Keep it in mind for later.

Exchange 6: Scale & System Resources

Candidate: With 10 million daily active users and 500 million posts, what latency are we targeting?

Interviewer: Good question. What would you propose?

Candidate: I'd assume <500ms for a user to see their feed. Ideally <200ms.

Interviewer: Why that number?

Candidate: Research shows users perceive <200ms as instant. Beyond 500ms, people leave. Also, network latency eats time, so the service itself should be fast.

Interviewer: OK. What about compute cost? We can't run a complex model for every request.

Candidate: That's why the two-stage approach works. Candidate generation is fast retrieval, ranking narrows it down. And caching helps—maybe cache feeds for a few minutes.

Interviewer: What if two users with the same interests request feeds 1 minute apart?

Candidate: If we cache for 5 minutes, the second user gets a cached result. Saves compute, acceptable staleness.

Interviewer: And if a viral post emerges?

Exchange 7: Metrics & Success

Candidate: How do we measure success?

Interviewer: What metrics matter?

Candidate: Click-through rate (CTR), time spent, daily active users. Maybe also like/comment/share rates. And negative metrics like unfollow rate or people reporting spam.

Interviewer: Good. And offline, for model evaluation?

Candidate: We'd split into training/validation and test on held-out data. Metrics like AUC for binary classification, or NDCG if we're ranking.

Interviewer: Why NDCG?

Candidate: Because the order matters. A feed with the best post ranked fifth is worse than best post ranked first, even if the same posts are there. NDCG captures that.

Interviewer: Exactly. Keep going with NDCG as your ranking metric.

Exchange 8: Fairness & Diversity

Candidate: Are there any fairness constraints?

Interviewer: What do you think could go wrong?

Candidate: We might create filter bubbles where users only see posts confirming their views. Or new creators can't reach audiences. Or some user groups get worse content.

Interviewer: How would you mitigate these?

Candidate: We could diversify the feed—not all posts from the same topic or creator. We could boost new content or creators. And measure diversity as a metric alongside engagement.

Interviewer: Good instincts. For now, assume we optimize primarily for engagement but track diversity. We'll address fairness in future iterations.

Functional Requirements

Non-Functional Requirements

Key Design Challenges

1. Scale

500 million posts daily. Can't evaluate all for every user. Need fast candidate retrieval.

2. Position Bias

Posts shown higher are clicked more. How do you learn true relevance vs. ranking artifact?

3. Feedback Loop

Promoted posts get more engagement, which trains the model to promote them further. Risk of feedback loops and filter bubbles.

4. Cold Start

New users, new posts, new topics—no engagement data yet. How do you bootstrap personalization?

5. Multi-Objective

Optimize for clicks, likes, comments, shares, time spent. They conflict. How do you balance?

6. Real-Time Freshness

Viral posts emerge within seconds. Pre-computed candidates become stale. Need real-time scoring.

7. Fairness & Creator Economy

Small creators get less visibility. Can you promote quality without purely engagement-driven ranking?

High-Level System Design (Text Sketch)

User Opens App
    |
    v
[Request Feed]
    |
    v
+---------------------------+
|  Candidate Generation     |
|  (retrieval-based)        |
|                           |
|  - User's network         |
|  - Trending posts         |
|  - Interest-based         |
|  Result: ~500 posts       |
+---------------------------+
    |
    v
+---------------------------+
|  Feature Engineering      |
|                           |
|  - User features          |
|  - Post features          |
|  - Context features       |
+---------------------------+
    |
    v
+---------------------------+
|  Ranking Model            |
|  (ML scoring)             |
|                           |
|  Predict engagement score |
|  Result: ~50 scored posts |
+---------------------------+
    |
    v
+---------------------------+
|  Diversity & Filtering    |
|                           |
|  - Remove near-dups       |
|  - Balance topics         |
|  - Add ads                |
+---------------------------+
    |
    v
[Return Feed to User]

Component Breakdown

• Candidate Generation: Fast retrieval from 500M posts to ~500 candidates (retrieval index, heuristics, cache)
• Feature Store: Precomputed user/post features for speed
• Ranking Model: Neural net or boosted trees, ~10-100ms latency
• Filtering: Remove duplicates, balance diversity
• Caching: Cache popular feeds, trending lists

Next Steps

In the following sections, we'll:

1. Frame this as an ML problem (predict engagement probability)
2. Design features and handle data challenges
3. Build and train ranking models
4. Evaluate offline and online
5. Deploy and monitor

Summary Callouts

💡 Tip: Always start by understanding business goals, not jumping to technical solutions. "Increase engagement" is vague—does that mean clicks, time, creators' success?

📝 Note: Two-stage ranking (candidate → ranking) is standard for large-scale recommendation. It's not about perfection; it's about speed and practicality.

⚠️ Watch out: Engagement metrics can misalign with user satisfaction. High CTR on sensational posts might hurt long-term retention.

🎯 Interviewer's Perspective: Interviewers want to see you ask clarifying questions, think about trade-offs, and acknowledge complexity. Avoid premature optimization.

Back to ML System Design Interviews