Preguntas de entrevista en Meituan

En qué se centran las entrevistas de Meituan

Preguntas comunes en entrevistas de Meituan

• Dada una lista de puntos de entrega (lat/lng) y una ubicación de inicio, encuentra la ruta más corta para visitar todos los puntos y regresar.
  Lo que cubre una buena respuesta

  • Modelar el problema como una instancia del Problema del Viajante de Comercio (TSP) con retorno al origen.
  • Para conjuntos pequeños (<20 puntos) usar programación dinámica (Held-Karp) con complejidad O(2^n * n^2).
  • Para conjuntos grandes usar heurísticas como vecino más cercano (O(n^2)) y mejorar con 2-opt o algoritmos genéticos.
  • Considerar la distancia de Haversine para lat/lng y posibles restricciones de tráfico o tiempo de entrega.
  • Evaluar la solución mediante simulación con datos reales para ajustar la precisión vs. tiempo de cómputo.

  Ver respuesta de ejemplo

  El problema es una variante del TSP (Traveling Salesman Problem) donde debemos visitar todos los puntos de entrega y regresar al inicio. Para un número reducido de puntos, podemos usar el algoritmo de Held-Karp con programación dinámica, que tiene complejidad O(2^n * n^2) y da la solución óptima. Sin embargo, para decenas o cientos de puntos, es impracticable; entonces recurrimos a heurísticas como el vecino más cercano (greedy), que construye una ruta paso a paso con complejidad O(n^2). Para mejorar la calidad, aplicamos optimización local como 2-opt, que intercambia aristas para reducir la longitud total. También podemos usar algoritmos genéticos o simulated annealing para obtener soluciones casi óptimas. Es importante usar la fórmula de Haversine para calcular distancias geodésicas entre coordenadas lat/lng, y si hay restricciones de tiempo de entrega, debemos modelarlas como ventanas de tiempo. La elección del algoritmo depende del tamaño del problema y de la precisión requerida; en producción es común combinar una heurística rápida con una optimización posterior.

• Diseña un sistema de seguimiento de pedidos en tiempo real para millones de usuarios, considerando latencia, consistencia y tolerancia a fallos.
  Lo que cubre una buena respuesta

  • Requisitos: baja latencia (<100ms), alta consistencia (orden visible para usuario), tolerancia a fallos y escalabilidad horizontal.
  • Usar WebSocket para comunicación en tiempo real con push desde servidor a usuarios.
  • Particionar datos por order_id en varias bases de datos (sharding) para manejar millones de pedidos.
  • Implementar un broker de mensajes (Kafka) para desacoplar las actualizaciones de estado y garantizar durabilidad.
  • Cachear estado actual en Redis con expiración para consultas rápidas y reducir carga en BD.

  Ver respuesta de ejemplo

  Para diseñar un sistema de seguimiento de pedidos en tiempo real para millones de usuarios, necesitamos latencia baja (por debajo de 100ms) y alta consistencia, ya que el usuario debe ver el estado correcto de su pedido. Usaremos WebSocket para comunicación bidireccional, permitiendo que el servidor envíe actualizaciones al instante. Los pedidos se particionarán por order_id usando un algoritmo de hash consistente, distribuyendo la carga en varias bases de datos (por ejemplo, MySQL o PostgreSQL). Cada vez que un repartidor actualiza el estado, se envía un mensaje a Kafka con el order_id y el nuevo estado. Un consumidor actualiza la base de datos y publica el cambio en un canal de Redis Pub/Sub para notificar a los servidores WebSocket correspondientes. Para tolerancia a fallos, replicamos los datos en al menos dos nodos y usamos un líder-seguidor con failover automático. El sharding asegura que la carga de lectura/escritura se distribuye horizontalmente. Además, cacheamos el estado actual en Redis para consultas frecuentes, reduciendo la latencia y la presión sobre la BD. Para mantener la consistencia, usamos confirmación de escritura (quorum) y versiones de datos (optimistic locking).

• Implementa un caché con política de desalojo LRU que soporte operaciones get y put en tiempo promedio O(1).
  Lo que cubre una buena respuesta

  • Usar una estructura de datos combinada: HashMap para acceso O(1) + lista doblemente enlazada para orden de uso.
  • La lista enlazada mantiene el orden de acceso: el más recientemente usado al frente, el menos al final.
  • En get: mover el nodo accedido al frente. En put: si existe, actualizar valor y mover al frente; si no, agregar al frente; si se excede capacidad, eliminar el último.
  • Todas las operaciones (get/put) deben ser O(1) en tiempo promedio usando referencias a nodos en el HashMap.
  • Implementar métodos auxiliares addToHead, removeNode, y popTail para reutilizar lógica.

  Ver respuesta de ejemplo

  Para implementar un caché LRU con operaciones O(1), combinamos un diccionario (HashMap) con una lista doblemente enlazada. El diccionario mapea claves a nodos de la lista, permitiendo acceso directo. La lista mantiene el orden de uso: los nodos más recientemente usados están cerca de la cabeza, y los menos recientes cerca de la cola. En la operación get(clave), si la clave existe, movemos su nodo a la cabeza y devolvemos el valor. En put(clave, valor), si la clave ya existe, actualizamos el valor y movemos el nodo a la cabeza. Si es nueva, creamos un nodo, lo agregamos a la cabeza y lo insertamos en el diccionario. Si el tamaño excede la capacidad, eliminamos el nodo de la cola (el menos recientemente usado) y lo borramos del diccionario. Mantenemos punteros a cabeza y cola para que las inserciones y eliminaciones sean O(1). Es importante manejar casos borde cuando la lista está vacía o tiene un solo elemento. Esta implementación es estándar y cumple con los requisitos de tiempo promedio O(1).

  class Node:
      def __init__(self, key, val):
          self.key = key
          self.val = val
          self.prev = None
          self.next = None
  
  class LRUCache:
      def __init__(self, capacity: int):
          self.cap = capacity
          self.cache = {}  # mapa clave -> nodo
          # Nodos ficticios para evitar comprobaciones de null
          self.head = Node(0, 0)
          self.tail = Node(0, 0)
          self.head.next = self.tail
          self.tail.prev = self.head
  
      def _add_to_head(self, node):
          # Inserta nodo justo después de head
          node.prev = self.head
          node.next = self.head.next
          self.head.next.prev = node
          self.head.next = node
  
      def _remove_node(self, node):
          # Elimina nodo de la lista
          prev = node.prev
          nxt = node.next
          prev.next = nxt
          nxt.prev = prev
  
      def get(self, key: int) -> int:
          if key in self.cache:
              node = self.cache[key]
              self._remove_node(node)
              self._add_to_head(node)
              return node.val
          return -1
  
      def put(self, key: int, value: int) -> None:
          if key in self.cache:
              node = self.cache[key]
              node.val = value
              self._remove_node(node)
              self._add_to_head(node)
          else:
              if len(self.cache) >= self.cap:
                  # Eliminar el nodo de la cola (menos reciente)
                  lru = self.tail.prev
                  self._remove_node(lru)
                  del self.cache[lru.key]
              new_node = Node(key, value)
              self.cache[key] = new_node
              self._add_to_head(new_node)
  
  # Complejidad temporal: O(1) para get y put.
  # Complejidad espacial: O(capacidad) para almacenar claves y nodos.

• Eres responsable de mejorar el sistema de recomendación para la entrega de comida de Meituan. ¿Cómo personalizarías las recomendaciones asegurando diversidad?
  Lo que cubre una buena respuesta

  • Personalización mediante filtrado colaborativo (usuarios similares) y basado en contenido (preferencias de cocina).
  • Incorporar contexto (hora del día, clima, historial reciente) para recomendar platos adecuados.
  • Usar MMR (Maximum Marginal Relevance) para equilibrar relevancia y diversidad en la lista de recomendaciones.
  • Considerar métricas de negocio como márgenes de ganancia y rotación de inventario.
  • A/B testing para validar cambios y evitar sesgos de popularidad.

  Ver respuesta de ejemplo

  Para personalizar las recomendaciones en Meituan, combinamos filtrado colaborativo y basado en contenido. El filtrado colaborativo encuentra usuarios con patrones de pedidos similares y recomienda lo que les gustó; el basado en contenido analiza las preferencias del usuario por tipo de cocina, ingredientes o restaurantes. Además, el contexto es crucial: no es lo mismo pedir a las 8 am que a las 9 pm; podemos usar características como hora del día, día de la semana, clima y ubicación actual para ajustar las recomendaciones. Para asegurar diversidad, aplicamos el algoritmo MMR (Maximum Marginal Relevance), que selecciona ítems que son relevantes pero también diferentes entre sí, evitando que todas las sugerencias sean del mismo tipo. También es importante incluir diversidad de precios y restaurantes. Desde el punto de vista del negocio, podemos favorecer platos con mayor margen o que necesiten promoción, pero sin descuidar la satisfacción del usuario. Evaluamos los cambios mediante A/B testing, midiendo tasas de clics, conversión y tiempo de permanencia. Un desafío es evitar el sobreajuste a datos pasados; por eso aplicamos regularización y exploramos con recomendaciones aleatorias ocasionalmente.

• Cuéntame sobre una ocasión en la que tuviste que hacer una compensación entre velocidad y calidad. ¿Cómo decidiste y cuál fue el resultado?
  Lo que cubre una buena respuesta

  • Situación: sprint con fecha límite ajustada, debía elegir entre implementar tests unitarios completos o entregar funcionalidad a tiempo.
  • Tarea: desarrollar un nuevo módulo de pagos para una tienda online.
  • Acción: prioricé los tests para las partes críticas (cálculo de impuestos, integración con pasarela) y omití tests de UI menos relevantes.
  • Resultado: el módulo se entregó a tiempo, con tests que detectaron un bug grave en producción antes del lanzamiento.
  • Lección: la compensación fue aceptable porque la calidad de las partes críticas no se sacrificó; la velocidad se ganó en áreas de menor riesgo.

  Ver respuesta de ejemplo

  En un proyecto anterior, tenía que entregar un nuevo módulo de pagos en dos semanas. El equipo de QA estaba sobrecargado y yo debía decidir si invertir tiempo en escribir tests unitarios exhaustivos o simplemente integrar y probar manualmente. Opté por una compensación: escribí tests unitarios solo para las funcionalidades más críticas: cálculo de impuestos, validación de tarjetas y comunicación con el gateway de pago. Para el resto (UI, mensajes de error), confié en pruebas manuales rápidas. Esto me permitió cumplir con el plazo. Durante las pruebas de integración, los tests unitarios detectaron un error en el redondeo de impuestos que habría causado pérdidas significativas. Si hubiera intentado cubrir todo con tests, habría retrasado la entrega. El resultado fue positivo: el módulo funcionó correctamente en producción y el cliente quedó satisfecho. Aprendí que es importante identificar qué partes del sistema tienen mayor impacto y enfocar los esfuerzos de calidad allí, dejando áreas menos críticas para pruebas posteriores. Esta compensación entre velocidad y calidad fue estratégica y basada en riesgos.

• ¿Cómo diseñarías un sistema de cupones/descuentos escalable que pueda manejar ventas flash sin colapsar?
  Lo que cubre una buena respuesta

  • Pre-generar códigos de cupón con firma HMAC para evitar falsificación y distribuirlos en lotes.
  • Usar un contador atómico en Redis para limitar la cantidad de canjes en tiempo real.
  • Implementar idempotencia en el servicio de canje para evitar duplicados debido a reintentos.
  • Arquitectura orientada a eventos con cola de mensajes (Kafka) para desacoplar la validación del canje.
  • Escalar horizontalmente el servicio de canje y usar rate limiting por usuario y global.

  Ver respuesta de ejemplo

  Para un sistema de cupones escalable para ventas flash, necesitamos manejar picos de tráfico. Primero, pre-generamos los códigos de cupón con un HMAC (firma) para garantizar su autenticidad y los almacenamos en una base de datos. Durante la venta flash, los usuarios solicitan canjear un cupón. El servicio de canje valida la firma y luego usa un contador atómico en Redis (por ejemplo, DECR) para verificar si aún hay cupones disponibles. Redis es rápido y consistente para este propósito. Para evitar que un mismo cupón se canjee dos veces, implementamos idempotencia: cada solicitud lleva un ID único (nonce) y el servicio registra los nonces ya usados en Redis con TTL. Si el nonce ya existe, se rechaza la solicitud. La validación exitosa publica un mensaje en Kafka con los detalles del canje; un consumidor actualiza la base de datos de forma asíncrona. Esto desacopla la escritura de la alta concurrencia. Escalamos el servicio de canje horizontalmente, usando un balanceador de carga. Además, aplicamos rate limiting por usuario (por ejemplo, máximo 5 canjes por segundo) y global (máximo 10000 por segundo) usando un token bucket en Redis. La base de datos principal (MySQL) se particiona por cupón o por usuario para evitar puntos calientes. Finalmente, monitoreamos la latencia y la tasa de errores para ajustar dinámicamente los límites.

• Describe una situación en la que no estuviste de acuerdo con tu gerente sobre la dirección técnica. ¿Cómo lo manejaste?
  Lo que cubre una buena respuesta

  • Situación: gerente quería implementar una solución monolítica rápida para un nuevo producto; yo prefería microservicios para escalabilidad futura.
  • Tarea: diseñar la arquitectura de un sistema de gestión de inventario.
  • Acción: preparé un documento con pros y contras de cada enfoque, incluyendo costos y plazos estimados.
  • Resultado: acordamos un compromiso: usar un monolito modular que permita extraer servicios gradualmente.
  • Lección: la comunicación basada en datos y el respeto por las prioridades del negocio facilitaron el acuerdo.

  Ver respuesta de ejemplo

  En mi rol anterior, mi gerente propuso desarrollar un sistema de gestión de inventario como un monolito para acelerar el time-to-market. Yo argumenté que debido a los planes de expansión a varios países, los microservicios serían más adecuados para escalar y mantener equipos independientes. Programé una reunión y presenté un análisis comparativo: el monolito reduciría el tiempo de desarrollo inicial en un 20%, pero los microservicios nos ahorrarían costos de mantenimiento a largo plazo y permitirían escalar componentes de forma independiente. Discutimos los riesgos de deuda técnica. Mi gerente estaba preocupado por los plazos ajustados, así que propuse un compromiso: construir un monolito modular, con interfaces bien definidas entre módulos, de modo que en el futuro pudiéramos extraer servicios sin reescribir todo. Esto nos permitió lanzar a tiempo y luego, durante los siguientes trimestres, migrar partes críticas a microservicios. La experiencia me enseñó que es importante escuchar las preocupaciones del negocio y buscar soluciones intermedias. Mantener una comunicación abierta y basada en datos ayudó a llegar a un consenso sin dañar la relación laboral.

• Dado un gran conjunto de datos de reseñas de usuarios, diseña un sistema para detectar y filtrar reseñas falsas en tiempo real.
  Lo que cubre una buena respuesta

  • Preprocesamiento: extraer características textuales (longitud, palabras emocionales, patrones de spam) y metadatos (usuario nuevo, IP, dispositivo).
  • Modelo supervisado (Random Forest o red neuronal) entrenado con reseñas etiquetadas como auténticas o falsas.
  • Enfoque basado en grafos para detectar grupos de cuentas que reseñan siempre los mismos restaurantes (astroturfing).
  • Arquitectura en tiempo real: usar Kafka para ingesta, Spark Streaming para procesar y actualizar modelos en línea.
  • Feedback loop: los usuarios pueden reportar reseñas sospechosas, que se usan para reentrenar el modelo periódicamente.

  Ver respuesta de ejemplo

  Para detectar reseñas falsas en tiempo real, primero extraemos características de cada reseña: longitud del texto, uso de superlativos, presencia de palabras clave de spam, y también metadatos como antigüedad de la cuenta, frecuencia de reseñas, IP y dispositivo. Entrenamos un modelo supervisado (por ejemplo, Random Forest o LSTM) con un conjunto etiquetado de reseñas auténticas y falsas. Además, usamos un enfoque basado en grafos: construimos un grafo bipartito entre usuarios y restaurantes, y aplicamos detección de comunidades para identificar grupos que reseñan sistemáticamente los mismos lugares (posible astroturfing). La arquitectura en tiempo real utiliza Kafka para ingerir reseñas, y Spark Streaming o Flink para aplicar el modelo y las reglas heurísticas en cada reseña entrante. Las reseñas clasificadas como falsas se marcan y se envían a un equipo de revisión. También implementamos un sistema de feedback donde los usuarios pueden reportar reseñas; esas reseñas se almacenan y se usan periódicamente para reentrenar el modelo. Para escalar, el modelo se puede servir con una API REST usando un balanceador de carga y réplicas del modelo. Monitoreamos la precisión y recall del detector, y ajustamos los umbrales para minimizar falsos positivos y negativos.

Consejos para prepararse

• Practica problemas difíciles de LeetCode centrados en recorrido de grafos (por ejemplo, Dijkstra, A*) y programación dinámica, ya que Meituan a menudo usa escenarios de entrega/logística.
• Para diseño de sistemas, estudia arquitecturas a gran escala como las de aplicaciones de viajes compartidos o entrega de comida. Prepárate para discutir compensaciones entre consistencia, disponibilidad y latencia.
• Alinea tus respuestas conductuales con los valores fundamentales de Meituan: cliente primero, enfoque en impacto a largo plazo y adoptar la mejora iterativa. Usa ejemplos específicos de tu experiencia.
• Prepárate para discutir métricas de negocio: comprende cómo las decisiones de ingeniería afectan las tasas de conversión, tiempos de entrega y retención de usuarios. Usa números y KPIs en tus respuestas.
• Realiza entrevistas simuladas con cronómetro: las entrevistas de Meituan son de ritmo rápido. Practica pensar en voz alta bajo presión de tiempo, especialmente para codificación y diseño.

Preguntas frecuentes