For a listener with no listening history, what decides which rung of a podcast feed's fallback ladder serves the request?
answer
- a chain, not a flag
- each rung states its precondition
- first rung whose signal exists wins
- re-checked per request, not per session
- log the rung that served
basics
~10 sA signal test on the request, not the account's age. Each rung declares a precondition; the funnel serves the first rung whose precondition holds, re-checked on every request, and logs which rung answered.
solid answer
~50 sThe ladder is an ordered chain of retrieval arrangements, each with an explicit guard. The top rung needs a listener vector resting on enough completed listens; the middle rung needs only a stated onboarding topic or a single completed listen and retrieves topic-scoped popular and content-similar shows; the bottom rung needs nothing and serves a precomputed popular list per locale. The funnel evaluates the guards in order and takes the first that passes, so a listener climbs the moment the signal exists — mid-session, not at the next daily rebuild. Two things make this operable: the served rung is logged beside the request so a complaint about a generic feed is answerable, and the bottom rung is treated as a real serving path with its own cache and availability, because it is the one that answers when everything else is empty.
code
pseudocode · 13 linesMIN_LISTENS_FOR_VECTOR = 5
function candidateSet(request):
listener = profile(request.listenerId)
if listener.vector != null and listener.completedListens >= MIN_LISTENS_FOR_VECTOR:
return retrieve(behaviouralSource, listener.vector, k = 400), rung = "personalized"
if listener.onboardingTopics is not empty or listener.completedListens >= 1:
seeds = listener.onboardingTopics union topicsOf(listener.recentListens)
return retrieve(topicSource, seeds, k = 400), rung = "topic"
return retrieve(popularSource, request.locale, k = 400), rung = "global"go deeper
Recall that a recommender must still answer for someone it knows nothing about, and that the answer comes from a cheaper source rather than from the personalized one.
Explain the ladder as ordered guards over retrieval sources: what each rung requires, what it reads, and why the check happens on every request rather than once per session.
Show the operating side: the rung logged on each request, an alert on the fallback share, a margin on the guard so it does not flap, and a terminal rung with its own cache and availability story.
Frame how much generic serving the product will tolerate: each extra rung adds a code path to own, and a guard set high buys relevance at the price of a longer generic first session.
## What a rung actually is A cold-start fallback ladder is not a flag on a user record. It is an **ordered list of retrieval arrangements**, and each rung is a triple: a *precondition* the request must satisfy, a *candidate source* the retrieval stage reads, and a statement of *what the scoring stage is allowed to do* with what comes back. Writing a rung down means writing all three; a rung with a candidate source but no stated precondition is not a rung, it is a hope. The listener side of cold start is the case where the top rung's precondition fails: a listener who signed up minutes ago has no behavioural vector, because there is nothing to encode. The ladder's job is to answer the request anyway, with something defensible, and to leave a trace of which arrangement answered. ## The guard is a signal test, not a timer The common mistake is to gate rungs on **account age** — "after seven days, use the personalized path". Age is not the thing the top rung needs. A listener can hold an account for a month and have played nothing; the encoder still has no input. The guard has to read the signal the rung actually consumes: | rung | precondition on the request | candidate source | what it costs | |---|---|---|---| | personalized | a listener vector exists and rests on at least the minimum completed listens | approximate nearest-neighbour retrieval over the behavioural space | full funnel latency and per-candidate scoring cost | | topic | at least one onboarding topic pick, or one completed listen | topic-scoped popular shows plus content-similar neighbours of what was played | cheap; relevance is coarse and shared across many listeners | | global | none — this rung must always be answerable | a precomputed popular list per locale, served from cache | almost free; identical for every cold listener in that locale | The three rungs are ordered by how much listener-specific signal they require, which is also, not coincidentally, the order of decreasing cost. ## Climbing mid-session Because the guards read per-request state, the decision is re-evaluated on every request. That matters more than it sounds: a listener who taps a show from the global rung and finishes an episode has, within minutes, produced the signal the topic rung wants. If the rung were chosen once at session start, the whole first session would be served from global popularity even though the listener told you something in its first two minutes. Re-evaluating per request has one cost — the decision can flap around the boundary, one listen short and then one listen over. Two cures, both cheap: - require the guard to be met **with margin** in one direction (enter at five listens, fall back below three); - cache the rung decision for a short window keyed by the listener, so a page of requests is served consistently. ## What the heavy ranker does with a null listener A rung is not only a retrieval choice. If the second-stage scoring model consumes listener-side features that are all null for this request, its output is not a weak score, it is an arbitrary one. So each rung also names the scoring arrangement: either the model was trained with those nulls present and their absence is itself a feature, or the rung skips the heavy scorer and orders its candidates by a cheap prior — topic affinity, recency of publication, completion rate of the show. Saying "we fall back on retrieval and rank normally" is the answer that fails the follow-up. ## Instrument the ladder 1. **Log the rung that served**, with the request identifier and the guard that failed, on every request. Without it, "my feed is generic" is unanswerable. 2. **Alert on the fallback share.** The proportion of requests served below the top rung is a stable number in normal operation; a jump usually means the feature that feeds the guard stopped updating, not that a cohort of new listeners arrived. 3. **Watch how long listeners sit on the bottom rung.** A cohort that never climbs is either a guard set too high or a global rung too generic to produce the first listen the guard wants. ## Where it goes wrong - A missing terminal rung: every rung has a precondition, so a request can fall through to nothing and the feed renders empty. - The bottom rung treated as a curiosity rather than a serving path, so nobody notices when its precomputed list goes stale or empty. - A single "is cold" boolean on the profile, computed nightly, instead of per-request guards — the listener stays cold for a day after their first listen. - Gating on age, which lets a silent listener onto a rung whose input does not exist.
- How does the funnel decide a listener has graduated off the topic rung?By the same guard, read from the other side: the top rung's precondition — a listener vector resting on at least the minimum completed listens — now passes, so the next request takes it. Graduation is not a separate job or a nightly sweep. Give the guard a margin, entering at a higher listen count than it exits at, so a listener hovering at the boundary does not alternate between two very different feeds request by request.
- What should happen if the bottom rung's precomputed popular list is empty or stale?It is the terminal rung, so it needs its own guarantee rather than a fallback of its own. Precompute it per locale on a schedule, serve it from a cache with a long time-to-live so a failed refresh degrades to yesterday's list instead of nothing, and treat an empty result as an incident: at that point the feed has no answer at all. Serving a stale popular list is a far smaller harm than serving an empty page.
saying these in an interview costs you the question
- Gates the rungs on account age rather than on the signal each rung consumes
- Stores one nightly is-cold flag instead of checking guards per request
- Assumes the heavy ranker still scores usefully when every listener feature is null
- Leaves the served rung unlogged, so the fallback share is invisible
- Designs no terminal rung, so a request can fall through to an empty feed