Katkat

Rank Home Search Results Without a Text Query

AirbnbMachine Learning Engineer · Onsite

Last updated

Design a home-search ranker without query text, covering structured intent, training bias, cold start, online evaluation, and production debugging.

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.

Hints

Hint 1

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.

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?