Recommendation System — Interview Perspective

Strong answer direction: confirm the surface, confirm whether personalization or a trending baseline is the immediate goal, clarify how many candidate sources and whether embedding/ANN retrieval are expected, and explicitly set model-training internals, specific ANN libraries, and named third-party systems as out of scope. What interviewer tests: whether you can bound an intentionally huge problem instead of trying to design everything. Read deeper: Scope.

Strong answer direction: state the formulas — recommendation QPS, ranking scores/sec, event ingest/sec, feature reads/sec, retrieval fan-out, impression volume — rather than memorized figures, and use the fact that impression volume usually dwarfs click volume to justify why exposure logging is its own subsystem. What interviewer tests: whether your numbers actually inform your design choices. Read deeper: Capacity Estimation.

Strong answer direction: at any real catalog size, scoring every item with an expensive model on every request cannot fit a request-time latency budget — candidate generation exists specifically to shrink the search space first, cheaply, before ranking spends its budget on a bounded set. What interviewer tests: whether you understand candidate generation and ranking as genuinely distinct stages, not a formality. Read deeper: Candidate Generation.

Strong answer direction: a click alone can't distinguish 'the user saw this and ignored it' from 'the user never had a chance to see this.' Logging generated, returned, rendered/exposed, and consumed states separately is what makes later analysis and exploration trustworthy. What interviewer tests: whether you understand selection bias as a first-class correctness concern, not an analytics nice-to-have. Read deeper: Impression & Exposure Logging.

• What if the client never reports a rendered impression for an item the server returned? — Treat 'returned' as lower-confidence than 'rendered' until the client confirms it or a timeout passes — see Missing Impression Events.

Strong answer direction: key aggregation on event-time, not processing-time; define an explicit grace window for late arrivals; and don't assume an event collector's sequence IDs establish any order beyond a narrow per-connection or per-session scope. What interviewer tests: whether you conflate 'when the pipeline saw it' with 'when it happened.' Read deeper: Event-Time vs. Processing-Time.

Strong answer direction: every event carries a stable ID, and every consumer (profile builder, popularity aggregator) is idempotent by construction, keying off that ID rather than trusting exactly-once delivery from the transport. What interviewer tests: whether your replay/recovery story is actually safe to use, not just theoretically available. Read deeper: Event Replay & Idempotency.

Strong answer direction: a durable long-term profile (interests, category affinity), a bounded recent-history window (not the full lifetime log), a short-lived session overlay, and policy/eligibility context — but not every ranking feature; context and item features are fetched separately at request time. What interviewer tests: whether you'll let the profile object grow unboundedly instead of keeping it a fast, predictable lookup. Read deeper: Profile State Model.

Strong answer direction: a profile record that keeps absorbing every feature anyone might someday want stops being a fast, predictable lookup and starts becoming a second, poorly-versioned feature store — broader feature needs go through explicit, batched Feature Store reads instead. What interviewer tests: whether you can draw a clean boundary between profile state and feature-store state. Read deeper: Full Profile vs Targeted Feature Fetching.

Strong answer direction: the request fans out in parallel to several sources, each honoring a shared contract (input, index version, timeout, quota, provenance); results are merged, deduplicated, and eligibility-filtered before handoff to ranking — no single source's raw score is trusted at face value against another source's. What interviewer tests: whether you can describe the mechanics, not just the word 'retrieval.' Read deeper: Candidate Source Contract and Candidate Merge & Deduplication.

Strong answer direction: it's one candidate source among several — embeddings are built or refreshed periodically, an approximate nearest-neighbor index is published from them, and at request time a query embedding retrieves nearest candidate IDs that flow into the same merge step as every other source. A new item has no embedding until the next index build, which is why cold-start-item handling exists separately. What interviewer tests: whether you'll overstate what one retrieval technique can do on its own. Read deeper: Embedding / ANN Retrieval.

• Exact or approximate nearest-neighbor search? — Approximate once catalog size makes exact search latency-prohibitive — see Exact vs Approximate Vector Retrieval.

Strong answer direction: no single retrieval technique covers cold-start users, cold-start items, and steady-state relevance equally well; independent sources also give a natural fallback when one degrades or times out. What interviewer tests: whether you see multi-source retrieval as a resilience decision, not just a relevance one. Read deeper: Single-Source vs Multi-Source Retrieval.

Strong answer direction: once candidate volume is large enough that the expensive main model's cost becomes the binding latency constraint, a cheaper pre-ranker trims the set first so the main model only spends its budget on already-promising candidates. At smaller scale, single-stage ranking is a perfectly reasonable starting point. What interviewer tests: whether you add complexity because it solves a real budget problem, not preemptively. Read deeper: Multi-Stage Ranking.

Strong answer direction: no — they're relative signals useful for ordering candidates within one request, not calibrated probabilities, and comparing raw scores across requests or model versions isn't meaningful without explicit calibration work. What interviewer tests: whether you'll overclaim what a ranking score actually means. Read deeper: Post-Ranking & Re-ranking.

Strong answer direction: the model, the feature schema, and the candidate index all version independently, and the serving path checks compatibility before trusting a response — on a mismatch, fall back to a known-compatible combination rather than scoring with mismatched assumptions, since a mismatch can still return 200 while quietly degrading quality. What interviewer tests: whether you've thought about version drift as a real production failure mode. Read deeper: Ranking Model & Index Version Compatibility.

Strong answer direction: better framed as three related concerns — feature definitions/metadata (the semantic contract), offline feature data (training/backfill), and online feature data (low-latency serving) — that share a contract rather than one monolithic store. This reduces, but does not fully eliminate, train/serve skew. What interviewer tests: whether you understand the feature store as an architectural contract rather than a single component. Read deeper: Feature Online/Offline Consistency.

Strong answer direction: a training example for time T is only valid if every feature it uses was actually available at or before T — joining current feature values against historical labels instead leaks future information into training, which often makes offline metrics look better while live performance quietly underperforms. What interviewer tests: whether you can name a real training-data-correctness failure mode, not just 'skew' vaguely. Read deeper: Feature Point-in-Time Correctness.

Strong answer direction: shift the candidate-source mix toward popularity retrieval, content/metadata-based retrieval, and any onboarding signals, rather than sources that need interaction history — ranking still runs, just with weaker personalized features. What interviewer tests: whether cold start is a first-class branch of the same pipeline, not a bolted-on exception. Read deeper: Cold Start: New Users.

Strong answer direction: metadata/content-based retrieval and reserved exploration slots give it a path into candidate pools before it accumulates interaction history or embedding-index presence; without a deliberate mechanism, popularity- and interaction-based sources will structurally never surface it. What interviewer tests: whether you remember item-side cold start, which is easy to forget after covering new users. Read deeper: Cold Start: New Items.

Strong answer direction: cache whole responses for hot, reusable combinations plus feature/item-metadata lookups, with TTLs scoped by user/surface/locale — but a cached response still has to pass the final eligibility recheck (availability, policy, privacy) before shipping, since caches and the indexes behind them can go stale. What interviewer tests: whether you'll let caching quietly become a correctness shortcut. Read deeper: Recommendation Cache.

Strong answer direction: request coalescing so only one request recomputes while others wait, plus soft TTLs with background refresh, applied by design rather than as a reactive fix after an incident. What interviewer tests: whether you've thought about the failure mode before being asked about it directly. Read deeper: Recommendation Cache Stampede.

Strong answer direction: a real-time signal processor captures fresh events into a short-lived session overlay, which the serving path merges with the durable profile at request time — bounded in influence and lifetime so one accidental click can't rewrite long-term preferences. What interviewer tests: whether the fast path complements the durable profile instead of replacing it. Read deeper: Real-Time Session Overlay.

Strong answer direction: most durable-profile fields don't need per-event freshness, and continuous streaming infrastructure for all of them costs far more than reserving it for the narrow session-overlay case that genuinely needs it. What interviewer tests: whether you can justify a freshness decision by cost and benefit, not just by what sounds more impressive. Read deeper: Precompute vs Real-Time.

Strong answer direction: reserve a bounded, measured slice of exposure for exploration, cap category/creator concentration in post-ranking, and track coverage metrics — treated as a deliberate architecture decision with a measurable near-term relevance cost, not just a warning to keep in mind. What interviewer tests: whether you can name concrete mechanisms instead of saying 'add some diversity.' Read deeper: Exploration vs. Exploitation.

Strong answer direction: without knowing what the system chose to expose, it can't tell whether an item's low engagement means genuine disinterest or simply a lack of exposure — impression logging and exploration are two halves of the same selection-bias problem. What interviewer tests: whether you connect these two concepts instead of treating them as unrelated bullet points. Read deeper: Impression & Exposure Logging.

Strong answer direction: train/build, offline validation, register with an explicit version, shadow against live traffic without affecting the response, canary/A-B on a small real-traffic slice, then expand — with a rollback path retained at every stage, since offline metrics don't always predict live behavior. What interviewer tests: whether you have a concrete lifecycle, not just 'deploy the new model.' Read deeper: Model Deployment & Rollout.

Strong answer direction: build the new version alongside the old one, validate it against size/coverage/quality checks, switch reads over with a single atomic pointer update, and retain the old version briefly for instant rollback — never mutate a live index in place. What interviewer tests: whether you recognize a bad index publication as a full-catalog-quality incident. Read deeper: Candidate Index Publication.

Strong answer direction: assignment must be a deterministic, sticky function of stable identifiers so the same user stays in the same variant, and the variant must propagate into the impression log on every logged event — otherwise treatment and control data mix silently, or outcomes can't be attributed at all. What interviewer tests: whether you see experiment infrastructure as part of the architecture, not just a data-science afterthought. Read deeper: Experiment Assignment & Logging.

Strong answer direction: each page can trigger an independent candidate-generation-and-ranking cycle, and if anything upstream shifted between requests (a cache refresh, an index update), the same item can resurface or reorder. A pagination cursor that pins the candidate or seen-item set for the session's life prevents it. What interviewer tests: whether you've considered multi-page consistency at all, since most candidates only design for a single response. Read deeper: Recommendation Pagination & Session Consistency.

Strong answer direction: shed load by reducing candidate count or switching to a cheaper fallback model/pre-ranker, and scale the fleet horizontally — the cause could be feature-hydration latency, model-server saturation, GC pauses, or candidate-count growth, so detection needs to distinguish which. What interviewer tests: whether your degraded mode preserves a useful response instead of timing out the page. Read deeper: Ranking Service Latency.

Strong answer direction: distinguish unavailable, stale, partially missing, and version-mismatched — the response differs for each, and a stale snapshot is not automatically safe if the affected features are eligibility- or privacy-related, since those still need a current-state recheck regardless of feature-store health. What interviewer tests: whether you'll wave away 'feature store is down' as one failure mode instead of several with different risk profiles. Read deeper: Feature Store Failure.

Strong answer direction: a bad model rollout, a version mismatch, a candidate source silently dominating the pool, or a stale index can all degrade relevance while every service keeps returning 200 — which is exactly why recommendation-quality observability (engagement relative to impressions, exposure concentration, new-item coverage, experiment health) has to exist as its own monitoring category, separate from system-health metrics. What interviewer tests: whether you understand that 'everything is green' is not sufficient evidence the product is working well. Read deeper: Quality Regression With No Errors.

Strong answer direction: a deleted item or an out-of-stock product can remain in a candidate index or cache after the catalog changes; if the mandatory post-filter eligibility recheck is skipped, or itself reads stale data, the item reaches the response. Availability and existence are hard eligibility constraints, not ranking features to be downweighted. What interviewer tests: whether you treat the final recheck as mandatory rather than optional. Read deeper: Eligibility Filtering and Deleted Item Still Recommended.

Strong answer direction: same core — profiles, multi-source candidate generation, multi-stage ranking, feature store, real-time overlay — with more emphasis on continue-watching state, session recency, household viewing skew, and catalog freshness around new releases; watch-completion signals matter a lot for the feedback loop. What interviewer tests: whether you can adapt emphasis without redesigning the architecture from scratch.

Strong answer direction: same core stack, with heavier emphasis on very large item/creator scale, fast-moving trends, short-session intent shifts, and stronger diversity/anti-feedback-loop guardrails — candidate generation and ranking are still the story, just under stronger scale and freshness pressure.

Strong answer direction: same architecture, but the serving constraints shift toward catalog availability, inventory, region, price, and purchase intent — the eligibility/policy layer and out-of-stock handling matter more heavily on the hot path than in a pure content-consumption feed.

Strong answer direction: same fundamentals again — event collection, profiles, multi-source retrieval, ranking, feature-store consistency, real-time session updates — with stronger freshness needs, creator-consumer graph effects, and a careful balance between close-connection relevance, discovery, and trend amplification via exploration and diversity controls.