Design place-of-interest ML system

Quick Overview

Design place-of-interest ML system evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design place-of-interest ML system

Company: Meta

Role: Software Engineer

Category: ML System Design

Difficulty: hard

Interview Round: Onsite

Design a machine learning system that recommends places of interest (POIs) to users. Specify: (a) product goals and key requirements (personalization, freshness, latency, scale), (b) data sources (map metadata, reviews, check-ins, GPS pings, events), labeling strategy (defining positives, counterfactual logging, debiasing for position/exposure), and feature sets (user, POI, context, interaction, geographic features), (c) a two-stage architecture with candidate generation (e.g., embeddings/ANN) and ranking (e.g., GBDT or deep models), plus a re-ranker for diversity/novelty, (d) training pipeline (batch + streaming updates, feature store, backfills) and online serving (feature retrieval, caching, latency budgets, fallbacks), (e) exploration/exploitation strategy (bandits or epsilon-greedy) for cold start and long-term learning, (f) evaluation plan with offline metrics (AUC, NDCG, coverage) and online A/B metrics (CTR, save/visit rate, dwell), and (g) privacy, abuse/spam prevention, and geo-specific fairness considerations.

Overview: Design place-of-interest ML system evaluates ML product requirements, data/labeling, modeling, serving architecture, evaluation, monitoring, and trade-offs in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Community answers

Answer by devinliao046

Geohash to force retrieval of local businesses
Meta logo
Meta
Jul 17, 2025
hardSoftware EngineerOnsiteML System Design
16
0

Design place-of-interest ML system

Design a POI (Places of Interest) Recommendation System

Context

Design a global POI recommender for a mobile maps/feed product that suggests nearby places (e.g., restaurants, attractions) across surfaces such as a home feed, map viewport, and search results. The system must support personalization, freshness, and high scale while meeting strict latency targets.

Specify

(a) Product goals and key requirements:

  • Personalization: individualized to user tastes, intents, and context
  • Freshness: reflect open/closed status, trending, events, new places
  • Latency: responsive on mobile; include p50/p95 budgets
  • Scale: global POIs, high QPS, multi-region deployment

(b) Data and features:

  • Data sources: map metadata, reviews, check-ins, GPS pings, events
  • Labeling strategy: define positives/negatives, counterfactual logging, debias for position/exposure
  • Feature sets: user, POI, context, interaction, geographic features

(c) Architecture:

  • Two-stage retrieval: candidate generation (embeddings/ANN) and ranking (GBDT or deep)
  • Re-ranker for diversity and novelty

(d) Training and serving:

  • Batch + streaming updates, feature store, backfills
  • Online serving: feature retrieval, caching, latency budgets, fallbacks

(e) Exploration/exploitation:

  • Strategy (e.g., bandits, epsilon-greedy) for cold start and long-term learning

(f) Evaluation plan:

  • Offline metrics (AUC, NDCG, coverage)
  • Online A/B metrics (CTR, save/visit rate, dwell)

(g) Trust & safety:

  • Privacy, abuse/spam prevention, geo-specific fairness considerations

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • ML-specific data, model, evaluation, serving, and monitoring choices.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?