CrackML by @ml.with.umang
Interview questions / ML System Design
ML System Design interview question

Design Nearby Places Recommendations

Design an end-to-end system for recommending nearby places beyond simply sorting by distance.

hardsystem designEvidence 77/1001 source reportMeta

The 60-second answer

Start with location/privacy constraints, intent, freshness, and the product objective such as useful visits rather than clicks alone. Retrieve geographically eligible candidates, then rank using travel time, preferences, context, quality, popularity, open-now status, and novelty.

Build the answer in this order

1
Frame the problem

Start with location/privacy constraints, intent, freshness, and the product objective such as useful visits rather than clicks alone.

2
Design the data path

Retrieve geographically eligible candidates, then rank using travel time, preferences, context, quality, popularity, open-now status, and novelty.

3
Choose the modeling stack

Handle sparse/new users and new places with contextual/content priors plus controlled exploration.

4
Serve, evaluate, iterate

Evaluate recall, NDCG/engagement, saves/visits, negative feedback, geographic slices, latency, and marketplace fairness.

A useful interview mental model

This is the shape of a strong answer—not a script to memorize.

01Requirements
02Data
03Model / Retrieval
04Serving
05Monitor

Senior-level signal

  • Senior answers discuss exploration, geographic supply bias, and privacy-preserving location handling.
  • Include real-time availability/freshness and distinguish retrieval misses from ranking mistakes.

What the interviewer is really testing

Product framing, data design, modeling choices, serving constraints, reliability, evaluation, and explicit trade-offs.

Likely follow-up questions

What changes at 10× traffic or data volume?
Which failure mode would you monitor first in production?
How would you evaluate this offline and online before rollout?

Common weak-answer patterns

  • Jumping to a model before defining the product contract.
  • Listing components without bottlenecks, metrics, or failure handling.
  • Ignoring data quality, serving latency, monitoring, and iteration.