A lived day on a feed-ranking team. The feed is a funnel of posts you can walk beside, with the ten published engagement weights hung over the ranker; four teammates speak in their own voices and you make each call before the scene answers.
The brief it was built from
One day as a machine-learning engineer on a large social network's feed-ranking team, from the morning stand-up to an evening incident: a failed experiment, a ranking regression after a model push, a code review, and a design choice between a fast first-pass ranker and a heavier one. Teammates speak in their own voices and the visitor makes each call before seeing how it plays out. Built from the platform's open-sourced recommendation code and public documentation, with any internal practice clearly labelled a scenario, and ending with a roadmap of skills and habits.
What is real, and what is a scenario
Real data
- The shape of the For You feed pipeline in X's open-sourced code: candidates from several sources, feature hydration (about 6,000 features), scoring and ranking with a model, filters and heuristics (author diversity, previously seen posts, blocked or muted authors, feedback fatigue), then mixing, ending in a page of 50 (home-mixer README; ScoredTweetsParam.scala)
- The candidate fetch defaults in the file as fetched on 2026-10-18: 600 in-network, 400 from the tweet mixer, 300 from the user-tweet-entity graph and 100 from the follow-recommendation service, 1,400 in all; the default page size is 50
- The heavy ranker's ten predicted engagement types and their published weights (April 5, 2023 snapshot): like 0.5, repost 1.0, reply 13.5, good profile click 12.0, watch half a video 0.005, reply engaged by the author 75.0, good click 11.0, two-minute conversation 10.0, negative feedback −74.0, report −369.0; the score is the weighted sum of the predicted probabilities, and the weights file can be changed at any time
- The heavy ranker is a neural network (a parallel MaskNet) whose outputs are probabilities between 0 and 1, one per engagement type
- The light ranker in the open-sourced code is a logistic regression described as a simplified version of the heavy ranker that can run on a greater number of posts; the README calls it an old part of the stack being replaced
- How many posts are scored per candidate source is a configurable setting in the open-sourced code (the 'quality factor' parameters), not a constant
- The open-sourced code includes a backup pipeline for the For You feed if the scored-posts pipeline fails
- Aggregate features in the open-sourced feature list are counts over windows of time, for example over 50 days
- The weighted-sum arithmetic, the interval maths on the readout screen's picture and the page-quality curve are computed in the page from the stated assumptions (model.js, run under Node as a check)
Scenario & assumptions
- The team (Meera, Tomas, Noor, Kofi), the company, the day, the stand-up, the readout, the push, the pull request and every line anyone speaks are a labelled scenario. They are roles, not real people, and the social network in the story is not named
- The open-sourced code is X's, published in 2023 and since changed (the file fetched for this build already differs from the April 2023 README); production today differs, and no claim is made about any company's internal practice. The scenario team simply works on a system shaped like the published one
- The experiment's numbers (replies +2.1%, hides, mutes and blocks +4.5%, time spent +0.6%, seven-day return −0.1%, and their intervals) are invented for the story
- The two posts and every predicted probability for them are illustrative. The 'new model keeps X% of the negative signal' slider is a simulation of a model that has lost its negative-feedback labels; that this happens, and the 32% crossover, follow from the invented probabilities and the real weights
- The pull request is a sketch, not code from any real system; that a feature can be computed differently in training and serving is a well-known pitfall, stated here without a citation because sources could not be reached from the build environment
- The first-pass ranker is a scenario: the pool of 5,000 posts, the 0.012 ms per candidate for the first pass, 0.2 ms per candidate for the heavy model, the 200 ms and 350 ms scoring budgets, and the noise in each ranker's estimate are assumptions. Page quality (the share of the best possible top 50 that reaches the page) comes from a seeded simulation, not a measurement
- Evening load: scoring-fleet utilisation of 0.35 at 700 scored posts on an ordinary evening, a match night 60% above it, a simple queueing curve for how waiting grows as the fleet fills, a 1.5x capacity gain and 25 minutes to add machines are all assumptions
- Guardrail metrics, rolling back before diagnosing, shedding load by scoring fewer posts, and alarms on predicted against observed rates are common industry practice described in plain words, not claims about any named company
- The meters (trust in the numbers, what is at risk) are illustrative, and the calls counted in the outro reflect the choices this page offers, not an assessment of skill
- Five minutes is the autoplay pace; making the choices takes longer
What you leave with
- Pair every metric you push with a guardrail you refuse to let fall, and read an interval clear of zero as real even when it is the wrong result
- The feed score is a weighted sum of predicted probabilities: know the weights and which way each pushes
- When a number jumps after a push, roll back first and diagnose second; a hand-tuned weight hides a broken model
- Ask whether a new feature is computed the same way in training and in serving before you trust an offline gain
- A cheap first pass should find the good posts, not order them, and latency should be measured at the evening peak, not on a quiet afternoon
- Turn the failure you caught by feel into an alarm, and know which lever (weights, model, scoring cap, fallback) you are pulling
Sources
- The Algorithm: README (X's open-sourced recommendation algorithm) The For You feed's stages, the component table (candidate sources, light ranker, heavy ranker, home-mixer, visibility filters) and that about 50% of posts come from the in-network source. Fetched 2026-10-18.
- Home Mixer README The For You stages (candidate generation, feature hydration of about 6,000 features, scoring and ranking, filters and heuristics such as author diversity and feedback fatigue, mixing) and the backup reverse-chronological pipeline in case scored posts fail. Fetched 2026-10-18.
- ScoredTweetsParam.scala (home-mixer scored posts parameters) The per-source fetch defaults (600, 400, 300, 100), the configurable max-posts-to-score parameters, and the default page size of 50, as the file stood on 2026-10-18.
- Heavy Ranker README (the-algorithm-ml) The ten predicted engagement types, their weights as of April 5, 2023, the weighted-sum formula, that the weights can be adjusted at any time, and the disclaimer that the open-sourced model may differ from production. Fetched 2026-10-18.
- Heavy Ranker features (FEATURES.md) Aggregate features defined over windows of time, for example 'count.50.days.count'.
- Earlybird light ranker README The light ranker is a logistic regression, a simplified version of the heavy ranker that can run on a greater number of posts; described as an old part of the stack being replaced.
- MaskNet: Introducing Feature-Wise Multiplication to CTR Ranking Models by Instance-Guided Mask The architecture family the heavy ranker README names. Cited as named in the README; the paper itself was not fetched in this run.
3D with three.js (MIT) · Recommendation code and documentation: X's the-algorithm and the-algorithm-ml repositories (AGPL-3.0); facts and the published weights are cited, no code is copied · Narration voice: Kokoro-82M v1.0, voice af_heart (kokoro-onnx 0.6.1). Apache-2.0 (Kokoro-82M weights).
Security & identity
Original
Life with a product
From request #1
Decisions
Original