Meituan Interview Questions

What Meituan interviews focus on

Common Meituan interview questions

• Given a list of delivery points (lat/lng) and a starting location, find the shortest route to visit all points and return.
  What a strong answer covers

  • Traveling Salesman Problem (TSP), NP-hard, exact solutions only feasible for small n.
  • Heuristics like Nearest Neighbor (O(n^2)) and 2-opt improvement used for scalability.
  • Consider real-world constraints: time windows, capacity, traffic; use constructive heuristics followed by local search.
  • For Meituan, route optimization must balance optimality with computational cost due to high frequency of requests.

  View a sample answer

  This is the classic Traveling Salesman Problem. Since it's NP-hard, for large n we need heuristics. A typical approach starts with a constructive heuristic like Nearest Neighbor, then improves with 2-opt or simulated annealing. For small n (e.g., ≤ 10), we can use dynamic programming (Held-Karp) or brute force. In a real system, we must also handle constraints like time windows and vehicle capacity (CVRPTW). We might precompute distances using geohashing or route APIs. The tradeoff is between solution quality and compute time; we can tune the iteration count for 2-opt. Below is a simple Nearest Neighbor implementation.

  import math
  
  def nearest_neighbor_route(points, start_idx=0):
      n = len(points)
      visited = [False]*n
      route = [start_idx]
      visited[start_idx] = True
      curr = start_idx
      for _ in range(n-1):
          min_dist = float('inf')
          next_idx = None
          for j in range(n):
              if not visited[j]:
                  d = math.hypot(points[curr][0]-points[j][0], points[curr][1]-points[j][1])
                  if d < min_dist:
                      min_dist = d
                      next_idx = j
          route.append(next_idx)
          visited[next_idx] = True
          curr = next_idx
      # return to start
      route.append(start_idx)
      return route

• Design a real-time order tracking system for millions of users, considering latency, consistency, and fault tolerance.
  What a strong answer covers

  • Must support millions of concurrent users with low latency (sub-second) for position updates and status changes.
  • Eventual consistency acceptable for order status; strong consistency needed for critical transitions (e.g., delivered).
  • Use sharded databases, Redis for caching active orders, and Kafka for event streaming.
  • WebSocket/SSE for real-time push; client-side fallback polling with exponential backoff.
  • Fault tolerance via replication, graceful degradation (e.g., stale data if backend down).

  View a sample answer

  The system needs to ingest location updates from delivery drivers (high write throughput) and push status to users (read + push). We'll have an API gateway that routes to an Order Service. Each order's state machine is stored in a sharded PostgreSQL (by order_id). For real-time location, we use a Redis cluster with per-order keys (TTL), updated by drivers via WebSocket. The Order Service publishes events (order placed, picked up, delivered) to Kafka. A Tracking Service consumes these and pushes notifications via WebSocket connections held by users. To scale WebSocket connections, we use a distributed pub/sub (e.g., Redis Pub/Sub or Kafka per region). For consistency, we use idempotent writes and exactly-once semantics for critical events. In case of failure, we rely on driver apps to retry and clients to poll. Read replicas for historical queries.

• Implement a cache with LRU eviction policy that supports get and put operations in O(1) average time.
  What a strong answer covers

  • O(1) average time for get and put operations.
  • Use a doubly linked list to maintain access order and a hashmap for key-to-node mapping.
  • On get: move node to head. On put: if key exists, update value and move to head; else, add new node at head; if over capacity, remove tail node and its map entry.
  • Thread safety requires locks (e.g., mutex in Python, but often we implement for single-threaded context; for multi-threaded use threading.Lock).
  • Time complexity: O(1) average; space O(capacity).

  View a sample answer

  An LRU cache evicts the least recently used item when capacity is full. We can implement with a hash map that maps keys to nodes in a doubly linked list. The list order reflects usage: most recent at head, least recent at tail. get(key): if exists, move its node to head and return value; else -1. put(key, value): if key exists, update node's value and move to head; else, create new node, add to head, insert into map; if size > capacity, remove tail node from list and map. The key is to use a dummy head/tail to avoid null checks. For concurrency, we'd need a lock around operations. Below is a Python implementation.

  class DLinkedNode:
      def __init__(self, key=0, value=0):
          self.key = key
          self.value = value
          self.prev = None
          self.next = None
  
  class LRUCache:
      def __init__(self, capacity: int):
          self.capacity = capacity
          self.cache = {}
          self.head = DLinkedNode()
          self.tail = DLinkedNode()
          self.head.next = self.tail
          self.tail.prev = self.head
  
      def _add_node(self, node):
          node.prev = self.head
          node.next = self.head.next
          self.head.next.prev = node
          self.head.next = node
  
      def _remove_node(self, node):
          prev = node.prev
          nxt = node.next
          prev.next = nxt
          nxt.prev = prev
  
      def _move_to_head(self, node):
          self._remove_node(node)
          self._add_node(node)
  
      def _pop_tail(self):
          res = self.tail.prev
          self._remove_node(res)
          return res
  
      def get(self, key: int) -> int:
          if key in self.cache:
              node = self.cache[key]
              self._move_to_head(node)
              return node.value
          return -1
  
      def put(self, key: int, value: int) -> None:
          if key in self.cache:
              node = self.cache[key]
              node.value = value
              self._move_to_head(node)
          else:
              new_node = DLinkedNode(key, value)
              self.cache[key] = new_node
              self._add_node(new_node)
              if len(self.cache) > self.capacity:
                  tail = self._pop_tail()
                  del self.cache[tail.key]

• You are responsible for improving the recommendation system for Meituan's food delivery. How would you personalize recommendations while ensuring diversity?
  What a strong answer covers

  • Personalization via collaborative filtering (user-item interactions) and content-based features (restaurant categories, price, cuisine).
  • Address cold start with contextual bandits or hybrid models.
  • Diversity: use MMR (Maximal Marginal Relevance) or determinantal point processes to re-rank recommendations.
  • Online learning to adapt to user appetite changes; A/B testing to evaluate metrics.
  • Tradeoff: personalization may lead to filter bubble; diversity ensures exploration and user satisfaction.

  View a sample answer

  For food delivery, recommendations should balance personalization and diversity. I'd build a two-stage system: first, candidate generation using matrix factorization (e.g., ALS) and content-based similarity (e.g., TF-IDF on menu items). Second, rank candidates with a gradient-boosted tree model using features like user history, time of day, weather. Then apply a diversity re-ranker like MMR which scores each item by a linear combination of relevance and novelty (dissimilarity to already selected items). For cold-start users, use contextual bandits to explore new restaurants. For diversity, we can also include constraints like no more than 2 similar cuisines in top 5. Metrics: personalization is measured by CTR or order rate; diversity by entropy of categories in recommendations.

• Tell me about a time you had to make a trade-off between speed and quality. How did you decide and what was the outcome?
  What a strong answer covers

  • Situation: Tight deadline for a critical feature with incomplete test coverage.
  • Task: Deliver a reliable feature on time while maintaining code quality.
  • Action: Prioritized core functionality, wrote unit/integration tests for critical paths, deferred non-essential features and deep testing to subsequent sprints.
  • Result: Feature shipped on schedule with acceptable defect rate; after launch, we monitored and fixed issues rapidly.

  View a sample answer

  In a previous role, we had to release a payment integration before a major promotion. The team faced a trade-off between speed (to meet the deadline) and quality (thorough testing). I decided to use risk-based testing: identify critical paths (e.g., successful payment, error handling) and ensure those were fully tested. We documented known risks for edge cases and postponed comprehensive load testing. After release, we set up real-time monitoring and a hotfix process. The outcome was successful: the feature handled peak traffic without downtime, though a few minor bugs were caught and fixed within hours. This approach taught me the importance of clear communication about trade-offs and having a rollback plan.

• How would you design a scalable coupon/discount system that can handle flash sales without crashing?
  What a strong answer covers

  • Flash sales cause high concurrency; need to prevent over-selling and handle race conditions.
  • Use pre-generated coupon codes stored in Redis, decrement atomic counters with Lua scripts.
  • Rate limiting per user and per IP using Redis counters with sliding window.
  • Asynchronous redemption: user claims coupon via lightweight API, then a background worker processes the assignment.
  • Fault tolerance: idempotency keys, queue persistence, circuit breaker.

  View a sample answer

  Design a coupon system for flash sales: First, pre-generate a pool of coupon codes and store them in a Redis set. During flash sale, users hit a claim endpoint. Use a Lua script that does: check if user has already claimed (to prevent duplicate), get a code from the set, decrement the set size, record user-coupon mapping. This is atomic. For rate limiting, use a sliding window counter per user. Since Redis is single-threaded, Lua scripts are fast. But to handle millions, we can shard coupons by region. After claiming, push a message to Kafka for asynchronous assignment (e.g., send email, update database). Use idempotency keys to avoid double processing. If Redis goes down, we fall back to a database-based queue. Circuit breakers prevent cascading failures.

• Describe a situation where you disagreed with your manager on technical direction. How did you handle it?
  What a strong answer covers

  • Situation: Manager advocated for a monolithic architecture for a new service; I favored microservices.
  • Task: Align on technical direction that balances scalability and team velocity.
  • Action: Prepared a data-driven comparison of both approaches focusing on expected traffic, team size, and deployment frequency.
  • Result: Agreed to start with a modular monolith with clear interfaces, then extract services as needed. This reduced initial complexity while allowing future scalability.

  View a sample answer

  My manager proposed building the new recommendation engine as a monolith to speed up development. I argued for microservices because the service would need to scale independently for different components (user profile, item scoring). I gathered data: expected peak QPS, team size (5 engineers), and past deployment issues. I proposed a compromise: build a modular monolith with well-defined API boundaries, so we can extract services later without major refactoring. This satisfied the manager's desire for speed while addressing my scalability concerns. In the end, we successfully delivered on time, and later extracted the scoring service when traffic grew. This taught me to frame disagreements in terms of business outcomes and to seek incremental solutions.

• Given a large dataset of user reviews, design a system to detect and filter fake reviews in real-time.
  What a strong answer covers

  • Real-time detection requires low latency (seconds) for feedback to users or moderators.
  • Features: text embeddings, user behavior patterns (e.g., burst of reviews, high rating variance), metadata (IP geolocation, device fingerprint).
  • Use streaming ML pipeline: Kafka for input, feature extraction with Flink/Spark Streaming, model inference via TensorFlow Serving.
  • Model: ensemble of logistic regression for easily detectable patterns and a neural network for complex cases; also rule-based filters for known attack signatures.
  • Scale: horizontally duplicate consumers, use stateful processing for user history, and manual review queue for low-confidence cases.

  View a sample answer

  To detect fake reviews in real-time, we need a pipeline that processes reviews as they are submitted. Ingest via Kafka. For each review, compute features: text embeddings (e.g., from a pretrained BERT model), user features (account age, number of reviews, average rating), and review-specific features (rating deviation from restaurant average, time since last review). Use Flink to join with user history. Run inference using a lightweight model (Logistic Regression for speed) and a deeper model (LSTM) for text; combine scores. If confidence is low, send to a human review queue. High confidence fake reviews are flagged or blocked immediately. For scaling, we partition by user_id and replicate the model servers. We also maintain a blacklist of IPs and device IDs. For model updates, we use online learning or periodic retraining.

Tips to prepare

• Practice LeetCode hard problems focusing on graph traversal (e.g., Dijkstra, A*) and dynamic programming, as Meituan often uses delivery/logistics scenarios.
• For system design, study high-scale architectures like those of ride-sharing or food delivery apps. Be ready to discuss trade-offs between consistency, availability, and latency.
• Align your behavioral answers with Meituan's core values: customer first, focus on long-term impact, and embrace iterative improvement. Use specific examples from your experience.
• Prepare to discuss business metrics: understand how engineering decisions affect conversion rates, delivery times, and user retention. Use numbers and KPIs in your answers.
• Mock interview with a timer: Meituan interviews are fast-paced. Practice thinking aloud under time pressure, especially for coding and design.

Frequently asked