Twitter/X Interview Guide 2026: Timeline Algorithms, Real-Time Search, and Content at Scale

Twitter/X Interview Guide 2026: Timeline Algorithms, Real-Time Systems, and Content Moderation at Scale

Twitter/X has undergone massive changes since Elon Musk’s acquisition in 2022, including significant headcount reduction (~80%) and a complete rebuild of many systems. The engineering team is now smaller and more focused on performance and monetization. This guide covers what to expect in SWE interviews at X (formerly Twitter) in 2026.

The X/Twitter Interview Process (2026)

Post-acquisition, X’s interview process is less formalized than traditional FAANG:

Recruiter/sourcing call — often direct outreach from engineering managers
Technical screen (1 hour) — coding + architecture discussion
Onsite (3–4 rounds, compressed schedule):
- 2× coding (medium-hard, emphasis on performance and scale)
- 1× system design (timeline, search, or real-time messaging)
- 1× engineering manager / culture fit

Culture note: X values “hardcore” engineers who can work long hours on hard problems. Interview culture expects demonstrated productivity and shipping mentality over process.

Core Algorithms: Timeline and Feed

Twitter’s Open-Source Timeline Algorithm

Twitter open-sourced their recommendation algorithm in 2023. Key components:

from dataclasses import dataclass, field
from typing import List, Dict, Optional
import math

@dataclass
class Tweet:
    id: int
    author_id: int
    text: str
    timestamp: float
    like_count: int = 0
    retweet_count: int = 0
    reply_count: int = 0
    view_count: int = 0
    has_media: bool = False
    language: str = 'en'

@dataclass
class UserContext:
    user_id: int
    following_ids: List[int]
    interests: List[str]
    engagement_history: Dict[int, str]  # tweet_id -> action

class TimelineRanker:
    """
    Simplified model of Twitter's timeline ranking.

    Real Twitter uses a two-stage system:
    1. Candidate generation: fetch 1500 candidates from:
       - In-network (following, followers-of-followers)
       - Out-of-network (trending, similar users, topics)
    2. Heavy ranker: ML model scoring each candidate
    3. Heuristic filters: dedupe, balance in/out-network, author diversity

    The ranking model uses ~48M parameter neural network with
    features covering user engagement history, tweet quality signals,
    author trust scores, and topic relevance.
    """

    def __init__(self):
        self.engagement_weights = {
            'like': 1.0,
            'retweet': 2.0,
            'reply': 3.0,
            'quote': 2.5,
            'profile_click': 0.5,
            'link_click': 1.5,
        }

    def score_tweet(
        self,
        tweet: Tweet,
        viewer: UserContext,
        current_time: float
    ) -> float:
        """
        Multi-factor tweet relevance score.
        """
        # 1. Social graph signal (is this from someone you follow?)
        social_score = 1.0 if tweet.author_id in viewer.following_ids else 0.3

        # 2. Engagement rate (quality signal)
        impressions = max(tweet.view_count, 1)
        engagement_rate = (
            tweet.like_count * 1.0 +
            tweet.retweet_count * 2.0 +
            tweet.reply_count * 3.0
        ) / impressions
        engagement_score = min(1.0, engagement_rate * 100)

        # 3. Recency decay (half-life = 2 hours for breaking news feel)
        age_hours = (current_time - tweet.timestamp) / 3600
        half_life = 2.0
        recency_score = math.exp(-age_hours * math.log(2) / half_life)

        # 4. Media boost (tweets with images/video get higher engagement)
        media_boost = 1.3 if tweet.has_media else 1.0

        # 5. User engagement history with author
        author_affinity = 1.5 if any(
            tweet_id for tweet_id in viewer.engagement_history
            # simplified: check if user has engaged with content from this author
        ) else 1.0

        return (
            social_score * 0.30 +
            engagement_score * 0.25 +
            recency_score * 0.25 +
            (media_boost - 1) * 0.10 +
            (author_affinity - 1) * 0.10
        )

    def generate_timeline(
        self,
        viewer: UserContext,
        candidate_tweets: List[Tweet],
        current_time: float,
        limit: int = 200
    ) -> List[Tweet]:
        """
        Score and rank all candidate tweets for viewer's timeline.

        Time: O(C * F) where C=candidates, F=features per tweet
        """
        scored = [
            (self.score_tweet(t, viewer, current_time), t)
            for t in candidate_tweets
        ]
        scored.sort(reverse=True)

        # Author diversity constraint: max 2 consecutive tweets per author
        result = []
        consecutive_by_author: Dict[int, int] = {}

        for score, tweet in scored:
            if len(result) >= limit:
                break
            count = consecutive_by_author.get(tweet.author_id, 0)
            if count < 2:
                result.append(tweet)
                consecutive_by_author[tweet.author_id] = count + 1
            else:
                consecutive_by_author[tweet.author_id] = 0  # reset after gap

        return result

Distributed Rate Limiting at Twitter Scale

import time
from collections import defaultdict
from threading import Lock

class TokenBucketRateLimiter:
    """
    Token bucket algorithm for API rate limiting.
    Twitter API: 1500 requests per 15 minutes per app.

    Token bucket:
    - Bucket capacity = max_requests
    - Tokens refill at rate = max_requests / window_seconds
    - Each request consumes 1 token
    - If bucket empty: reject request

    Advantage over fixed window: allows short bursts up to capacity
    while maintaining average rate constraint.

    Twitter uses Redis for distributed token bucket across API servers.
    """

    def __init__(self, capacity: int, refill_rate: float):
        """
        capacity: max tokens (burst limit)
        refill_rate: tokens per second
        """
        self.capacity = capacity
        self.refill_rate = refill_rate
        self.buckets: Dict[str, Dict] = defaultdict(
            lambda: {'tokens': capacity, 'last_refill': time.time()}
        )
        self.lock = Lock()

    def allow_request(self, key: str, tokens_needed: int = 1) -> bool:
        """
        Check if request is allowed; consume tokens if so.
        Thread-safe via lock (use Redis EVAL script in distributed setting).

        Time: O(1)
        """
        with self.lock:
            bucket = self.buckets[key]
            now = time.time()

            # Refill tokens based on elapsed time
            elapsed = now - bucket['last_refill']
            new_tokens = elapsed * self.refill_rate
            bucket['tokens'] = min(self.capacity, bucket['tokens'] + new_tokens)
            bucket['last_refill'] = now

            if bucket['tokens'] >= tokens_needed:
                bucket['tokens'] -= tokens_needed
                return True
            return False

    def get_reset_time(self, key: str) -> float:
        """Seconds until bucket is full again."""
        with self.lock:
            bucket = self.buckets[key]
            deficit = self.capacity - bucket['tokens']
            return deficit / self.refill_rate if deficit > 0 else 0

System Design: Twitter Search

Common X/Twitter question: “Design Twitter’s real-time search — results must appear within seconds of a tweet being posted.”

"""
Twitter Real-Time Search Architecture:

Tweet Posted
    |
[Ingestion Kafka Topic]
    |
[Real-Time Indexing Service]
  - Tokenizes tweet text
  - Extracts hashtags, mentions, entities
  - Writes to real-time index (Earlybird — Twitter's custom Lucene)
  - Earlybird: in-memory inverted index, TTL-based eviction (7 days)
    |
[Search Query Service]
  - Parse query (boolean operators, hashtag/mention filters)
  - Fan out to all Earlybird shards (by time range)
  - Merge and rank results
  - Apply safety filters (spam, NSFW)

Key design decisions:
1. In-memory index: tweets are ephemeral; no need for persistent indexing
2. Time-partitioned shards: each shard covers a time window
3. Top-K aggregation: each shard returns top-K; merge globally
4. Relevance signals: engagement counts updated asynchronously
5. Personalization: rerank based on user's following graph

Scaling challenge: 6000 tweets/second peak
Solution: Earlybird replicas, consistent hashing, parallel fan-out
"""

X/Twitter Engineering Culture (2026)

Post-Musk X is radically different from pre-2022 Twitter:

High velocity: Features shipped in days, not months; less process
Small teams: Most teams are 3–8 engineers owning large surface areas
Performance obsession: Engineering blog frequently posts about latency, memory, and cost wins
“Hardcore”: Expect long hours during major product launches

Compensation (2025 data)

Level	Base	Total Comp (est.)
SWE	$150–190K	$200–280K
Senior SWE	$190–230K	$280–380K
Staff SWE	$230–270K	$350–500K

X Corp. is now privately held. Equity is illiquid and uncertain. Compensation should be evaluated primarily on cash. Verify current comp data with levels.fyi.

Interview Tips

Real-time systems: Twitter is fundamentally a real-time platform; know Kafka, stream processing, pub/sub
Performance focus: Expect questions about latency, memory efficiency, and throughput optimization
Open source: Twitter open-sourced their timeline algorithm; reading it shows genuine interest
Culture awareness: Research recent changes honestly; show you can thrive in a fast-changing environment
LeetCode: Medium-hard; graph algorithms and sliding window patterns common

Practice problems: LeetCode 355 (Design Twitter), 295 (Median Data Stream), 362 (Design Hit Counter), 981 (Time Based Key-Value Store).