Rank Home Search Results Without a Text Query

Design a machine-learning ranker for home search results. The search has no free-text query, and an eligible candidate set is already provided. Focus on ranking those candidates rather than generating or filtering the candidate inventory. ### Constraints & Assumptions - The input includes the current search context and eligible homes. Clarify which context fields and user-history signals are available. - There is no query text to embed or match against listing descriptions as the primary query representation. - The ranker may use listing attributes, contextual signals, and permitted user history, but must distinguish features available at ranking time from future outcomes. - Define product objectives and guardrails before selecting labels or model architecture. No traffic or latency target is provided. ### Clarifying Questions to Ask - Is the primary outcome a successful booking, a qualified engagement, or another trip-level result? - What context is available, such as dates, party size, location constraints, and previously selected filters? - Are the candidates already checked for availability and hard constraints, and can those facts change before booking? - How much history is available for new users and new homes? ### Part 1 — Data and features Define training examples, labels, negative examples, and features for context, user, home, and their interactions. #### What This Part Should Cover - Logged impressions and their positions, subsequent outcomes, and timestamp-correct joins. - The effect of exposure and position bias on labels and negatives. - Features that express intent without free text and fallbacks for sparse-history entities. ### Part 2 — Model and serving Choose a baseline and a stronger ranking model, then describe the online feature and scoring path. #### What This Part Should Cover - An objective aligned with the product goal and a clear reason for the model choice. - Bounded candidate scoring, feature freshness, missing-feature behavior, and a fallback ranking. - Separation of ranker scores from hard eligibility and explicitly defined business constraints. ### Part 3 — Evaluation and online debugging Explain offline evaluation, controlled online evaluation, and investigation of an online regression. #### What This Part Should Cover - Ranking metrics, time-based evaluation, and slices for cold start and search context. - Product metrics and guardrails that can reject a misleading click improvement. - Debugging of feature skew, candidate changes, delayed outcomes, and exposure feedback. ```hint Intent can be structured The absence of query text removes one input channel. Examine how search parameters, session actions, and home attributes interact to reveal the current trip's needs. ``` ### What a Strong Answer Covers - A complete data-to-model-to-serving plan that stays within the given candidate-ranking scope. - Explicit evaluation and debugging plans, not only a feature list or model name. - Treatment of bias, cold start, freshness, and the distinction between proxy engagement and a successful trip outcome. ### Follow-up Questions - How would you detect a model that increases clicks but reduces completed bookings? - How would you evaluate a new home with no interaction history without permanently burying it?