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
|Home/ML System Design/Meta
Meta logo
Meta
Jul 17, 2025
hardSoftware EngineerOnsiteML System Design
14
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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...