Questions d'entretien Meituan

Les entretiens Meituan sont réputés pour leur rigueur, mélangeant des défis algorithmiques profonds avec une conception système pratique et des questions orientées business. Le processus comprend généralement plusieurs rounds axés sur le codage, la conception système et l'adéquation comportementale, avec un accent sur la résolution de problèmes réels et la compréhension des activités principales de Meituan comme la livraison de repas, les voyages et les services locaux. Les candidats doivent s'attendre à un mélange de profondeur technique et d'alignement avec les valeurs de Meituan de focalisation client, de réflexion à long terme et d'amélioration continue.

Commencer un entretien simulé gratuit

Sur quoi portent les entretiens chez Meituan

Codage et Algorithmes

Vous ferez face à des problèmes de niveau moyen à difficile de LeetCode, souvent avec une touche liée aux opérations de Meituan (par exemple, optimisation d'itinéraire de livraison, ordonnancement). Attendez-vous à une utilisation fréquente de structures de données comme les arbres, les graphes et la programmation dynamique.

Conception Système

Concevez des systèmes à grande échelle comme des plateformes de livraison de repas ou de logistique en temps réel. Les questions testent les compromis, l'évolutivité et la gestion d'un grand nombre d'utilisateurs concurrents. L'accent est mis sur les systèmes distribués, le cache et le partitionnement de bases de données.

Comportemental et Adéquation aux Valeurs

Meituan valorise 'Le Client d'Abord', 'Réflexion à Long Terme' et 'Embrasser le Changement'. Attendez-vous à des questions sur vos projets passés, échecs, résolution de conflits et comment vous vous alignez avec ces principes. Souvent formulées comme 'Parlez-moi d'une fois où...'.

Sens des Affaires

On peut vous demander d'analyser un scénario commercial, comme améliorer le taux de complétion des commandes ou réduire le coût de livraison. Ils veulent des ingénieurs qui comprennent comment les décisions techniques impactent les métriques business.

Questions d'entretien courantes chez Meituan

Étant donné une liste de points de livraison (latitude/longitude) et un lieu de départ, trouvez l'itinéraire le plus court pour visiter tous les points et revenir.

Ce qu'une bonne réponse couvre

Problème NP-difficile => heuristique pour évolutivité
Utiliser la distance Haversine pour les coordonnées
Approche du plus proche voisin suivie d'optimisation 2-opt
Complexité O(n^2) pour l'heuristique, O(n^2) par itération 2-opt
Gestion de la symétrie des distances et du retour au point de départ

Voir un exemple de réponse

Le problème du voyageur de commerce (TSP) avec des coordonnées géographiques est NP-difficile, donc pour des listes de taille modérée, on utilise une heuristique. La distance entre deux points est calculée avec la formule de Haversine pour tenir compte de la courbure terrestre. Une approche simple est l'algorithme du plus proche voisin : partir du lieu de départ, puis à chaque étape aller au point non visité le plus proche. Ensuite, on peut améliorer l'itinéraire avec l'heuristique 2-opt qui échange deux arêtes pour réduire la distance totale, répétée jusqu'à convergence. La complexité temporelle est O(n^2) pour la construction de l'itinéraire initial et O(n^2) par itération 2-opt. Un piège à éviter est de supposer que la matrice des distances est symétrique (elle l'est pour des coordonnées). Il faut aussi gérer le retour au point de départ comme une étape supplémentaire. Pour de très grands ensembles (n > 1000), des méthodes comme l'algorithme de Christofides ou le recuit simulé peuvent être envisagés.

Solution de référencepython

import math
import itertools

# Calcul de la distance Haversine entre deux points (lat, lon) en degrés
def haversine(p1, p2):
    R = 6371  # rayon terrestre en km
    lat1, lon1 = math.radians(p1[0]), math.radians(p1[1])
    lat2, lon2 = math.radians(p2[0]), math.radians(p2[1])
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    a = math.sin(dlat/2)**2 + math.cos(lat1)*math.cos(lat2)*math.sin(dlon/2)**2
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
    return R * c

# Algorithme du plus proche voisin pour TSP avec retour
# pts : liste des points (lat, lon), départ : indice du départ
# Retourne (chemin, distance) où chemin est une liste d'indices visités

def nearest_neighbor_tsp(pts, start):
    n = len(pts)
    visited = [False]*n
    chemin = [start]
    visited[start] = True
    total_dist = 0.0
    current = start
    for _ in range(n-1):
        nearest = None
        min_dist = float('inf')
        for i in range(n):
            if not visited[i]:
                d = haversine(pts[current], pts[i])
                if d < min_dist:
                    min_dist = d
                    nearest = i
        visited[nearest] = True
        chemin.append(nearest)
        total_dist += min_dist
        current = nearest
    # Retour au départ
    total_dist += haversine(pts[current], pts[start])
    chemin.append(start)
    return chemin, total_dist

# Exemple d'utilisation
points = [(48.8566, 2.3522), (45.7640, 4.8357), (43.2965, 5.3698)]
depart = 0
chemin, dist = nearest_neighbor_tsp(points, depart)
print("Itinéraire:", chemin)
print("Distance totale:", dist)

# Note : Pour améliorer, appliquer 2-opt après (non montré ici)

Concevez un système de suivi de commandes en temps réel pour des millions d'utilisateurs, en considérant la latence, la cohérence et la tolérance aux pannes.
Ce qu'une bonne réponse couvre
- Faible latence via WebSockets et cache Redis
- Cohérence éventuelle avec versioning ou horodatage
- Sharding horizontal des bases de données (p. ex. Cassandra)
- Tolérance aux pannes : réplication et files de messages (Kafka)
- Architecture événementielle pour traitement asynchrone
Voir un exemple de réponse
Pour concevoir un système de suivi de commandes en temps réel pour des millions d'utilisateurs, il faut prioriser la faible latence et la disponibilité tout en maintenant une cohérence suffisante. L'architecture repose sur des services indépendants : les clients mobiles se connectent via WebSockets à un service de notification qui pousse les mises à jour d'état. Les commandes sont stockées dans une base de données NoSQL comme Cassandra, partitionnée par région ou ID de commande pour l'évolutivité. Pour la cohérence, chaque événement de changement d'état (commande préparée, en livraison, livrée) est horodaté et versionné, permettant une cohérence éventuelle. Les événements sont produits sur Kafka pour être consommés par les services de notification et de journalisation. Pour la tolérance aux pannes, chaque composant est déployé avec plusieurs réplicas, et Kafka assure la durabilité des événements. Un cache Redis en mémoire stocke l'état des commandes actives pour une lecture rapide. Le compromis clé est entre fraîcheur des données (cohérence forte) et latence : on accepte une courte fenêtre d'incohérence pour éviter les blocages. En cas de panne, le système peut être dégradé en affichant le dernier état connu.

Implémentez un cache avec politique d'éviction LRU supportant les opérations get et put en temps moyen O(1).

Ce qu'une bonne réponse couvre

Utiliser un dictionnaire (hashmap) pour l'accès O(1)
Maintenir une liste doublement chaînée pour l'ordre d'utilisation
Les opérations get et put mettent à jour l'ordre (déplacer en tête)
Supprimer le nœud de queue en cas de dépassement de capacité
Implémentation avec sentinelles pour éviter les cas limites

Voir un exemple de réponse

L'implémentation d'un cache LRU (Least Recently Used) nécessite une combinaison d'un dictionnaire pour un accès rapide et d'une liste doublement chaînée pour maintenir l'ordre des clés par utilisation récente. La liste permet de déplacer un nœud en tête en O(1) et de supprimer le dernier nœud (le moins récemment utilisé) également en O(1). Le dictionnaire stocke pour chaque clé un pointeur vers le nœud correspondant dans la liste. Lors d'un get, on vérifie si la clé existe ; si oui, on déplace le nœud en tête et on retourne sa valeur. Lors d'un put, si la clé existe, on met à jour la valeur et on déplace en tête ; sinon, on crée un nouveau nœud, on l'ajoute en tête, et si la capacité est dépassée, on supprime le nœud de queue et on efface la clé du dictionnaire. Les sentinelles (tête et queue factices) simplifient la gestion des bords. La complexité temporelle moyenne est O(1) pour get et put.

Solution de référencepython

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):
        self.cap = capacity
        self.cache = {}  # dict clé -> noeud
        # Sentinelles pour éviter les vérifications de None
        self.head = Node(0, 0)  # tête (le plus récent)
        self.tail = Node(0, 0)  # queue (le moins récent)
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):
        # Supprime un noeud de la liste
        prev = node.prev
        nxt = node.next
        prev.next = nxt
        nxt.prev = prev

    def _add(self, node):
        # Ajoute un noeud juste après la tête (côté récent)
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        if key in self.cache:
            node = self.cache[key]
            self._remove(node)
            self._add(node)
            return node.val
        return -1

    def put(self, key, value):
        if key in self.cache:
            node = self.cache[key]
            self._remove(node)
            node.val = value
            self._add(node)
        else:
            if len(self.cache) >= self.cap:
                # Supprime le moins récent (juste avant tail)
                lru = self.tail.prev
                self._remove(lru)
                del self.cache[lru.key]
            new_node = Node(key, value)
            self._add(new_node)
            self.cache[key] = new_node

Vous êtes responsable de l'amélioration du système de recommandation pour la livraison de repas de Meituan. Comment personnaliseriez-vous les recommandations tout en assurant la diversité ?
Ce qu'une bonne réponse couvre
- Personnalisation via filtrage collaboratif et contenu
- Utiliser le contexte (heure, météo, localisation) pour affiner
- Assurer la diversité avec des algorithmes de reclassement (MMR)
- Contrainte d'exploration vs exploitation : A/B test
- Surveillance des métriques de diversité et de satisfaction
Voir un exemple de réponse
Pour améliorer le système de recommandation de livraison de repas de Meituan, la personnalisation doit combiner plusieurs signaux : l'historique des commandes, les préférences implicites (recherches, clics), et le contexte (heure du repas, météo, localisation). On peut utiliser une approche hybride : un modèle de filtrage collaboratif (MF) pour capturer les goûts similaires, et un modèle basé sur le contenu (catégories, prix, popularité) pour les nouveaux utilisateurs. Pour la diversité, on ne doit pas seulement recommander les plats les plus pertinents, mais aussi varier les restaurants et types de cuisine. Une technique consiste à utiliser un reclassement par similarité maximale marginale (MMR) qui pénalise les éléments trop similaires à ceux déjà recommandés. On peut aussi imposer des quotas par catégorie (par ex., pas plus de 2 plats du même restaurant). Un compromis important est entre exploitation (recommandations sûres) et exploration (nouveaux plats). On peut utiliser l'apprentissage par renforcement ou des A/B tests pour ajuster les paramètres. Il faut surveiller des métriques comme le taux de clics, la diversité (entropie des catégories) et la satisfaction à long terme.
Parlez-moi d'une fois où vous avez dû faire un compromis entre rapidité et qualité. Comment avez-vous décidé et quel a été le résultat ?
Ce qu'une bonne réponse couvre
- Contexte : développement d'une fonctionnalité avec délai serré
- Compromis : tests automatisés complets vs livraison rapide
- Décision : prioriser les tests critiques et reporter les non-fonctionnels
- Résultat : livraison dans les temps avec quelques bugs mineurs
- Leçon : communication avec l'équipe pour ajuster les attentes
Voir un exemple de réponse
Dans un projet précédent, nous devions livrer une fonctionnalité de recherche améliorée pour une plateforme e-commerce. Le délai était très serré en raison d'une campagne marketing imminente. Je devais choisir entre une implémentation rapide avec des tests minimaux (priorisant la vitesse) ou une version plus robuste avec des tests complets mais risquant de manquer la date limite. J'ai analysé les risques : les zones critiques étaient la pertinence des résultats et la stabilité du backend. J'ai donc décidé de couvrir ces zones avec des tests unitaires et d'intégration, tout en reportant les tests de performance et de charge après le lancement. J'ai communiqué ma décision au responsable produit et à l'équipe QA, en explicitant les risques résiduels. La fonctionnalité a été livrée à temps. Il y a eu quelques bugs dans les cas d'utilisation avancés, mais ils ont été rapidement corrigés après le lancement. La campagne s'est bien déroulée, et nous avons ensuite ajouté les tests manquants. Cette expérience m'a appris l'importance de prioriser les fonctionnalités critiques et de maintenir une communication transparente sur les compromis.
Comment concevriez-vous un système de coupons/remises évolutif capable de gérer des ventes flash sans planter ?
Ce qu'une bonne réponse couvre
- Préparation en amont : mise à jour des stocks dans Redis avant la vente flash
- Limitation du trafic avec un token bucket distribué (p. ex. Redis rate limiter)
- File d'attente des commandes pour lisser la charge (Kafka, RabbitMQ)
- Idempotence des demandes pour éviter les doubles traitements
- Dégradation gracieuse en cas de surcharge : présenter un message d'attente
Voir un exemple de réponse
Pour concevoir un système de coupons/remises évolutif capable de gérer des ventes flash sans planter, il faut anticiper les pics de trafic. Premièrement, la disponibilité des coupons est préchargée dans un cache Redis avec des compteurs atomiques pour chaque type de coupon. Pour éviter l'écrasement du serveur, on met en place un limiteur de débit distribué (token bucket) au niveau de l'API, qui rejette les requêtes en excès avec un code 429 (Too Many Requests). Les demandes acceptées sont placées dans une file d'attente asynchrone (Kafka ou RabbitMQ) pour être traitées de manière asynchrone. Le traitement inclut la vérification de l'éligibilité et la réservation du coupon avec des opérations atomiques dans Redis. Pour éviter les doubles réservations, chaque demande contient un identifiant unique (idempotence), ce qui permet de détecter et ignorer les doublons. Les bases de données relationnelles sont utilisées pour la persistance finale avec des transactions optimistes. En cas de charge extrême, on peut dégrader gracieusement en affichant une file d'attente virtuelle ou un message de réessai. Un monitoring en temps réel des métriques (taux de succès, latence) permet de réagir rapidement.
Décrivez une situation où vous étiez en désaccord avec votre manager sur une direction technique. Comment avez-vous géré cela ?
Ce qu'une bonne réponse couvre
- Contexte : divergence sur la migration vers une architecture microservices
- Action : présenter des données de performance et coûts estimés
- Compromis : proposer un prototype pour valider les gains
- Résultat : adoption partielle avec transition progressive
- Leçon : respecter l'expérience du manager tout en défendant ses idées
Voir un exemple de réponse
Lors d'un projet de refonte d'un système monolithique, mon manager préférait une approche incrémentale consistant à améliorer le monolithe existant, tandis que je pensais qu'une migration vers des microservices apporterait une meilleure scalabilité et une indépendance des équipes. Pour gérer ce désaccord, j'ai préparé une analyse comparative montrant les bénéfices potentiels en termes de temps de déploiement et de tolérance aux pannes, ainsi que les coûts de développement et d'infrastructure. J'ai proposé de construire un prototype de microservice pour un sous-domaine non critique (par exemple, le service de notifications) et de le comparer avec l'approche monolithique sur des métriques mesurables (latence, débit). Mon manager a accepté le prototype. Après trois semaines, les résultats ont montré une amélioration significative de la scalabilité pour cette partie. Nous avons alors décidé de migrer progressivement les autres services, en commençant par ceux qui bénéficieraient le plus de l'indépendance. Cette expérience m'a appris à fonder mes arguments sur des données et à faire preuve de flexibilité en proposant des compromis concrets.
Étant donné un grand ensemble de données d'avis d'utilisateurs, concevez un système pour détecter et filtrer les faux avis en temps réel.
Ce qu'une bonne réponse couvre
- Différenciation par le comportement : fréquence, horaires, IP
- Analyse textuelle : sentiment, similarité, répétitions
- Détection de communautés (sybil) via graphe des utilisateurs
- Flux en temps réel avec Kafka/Storm/Flink
- Utilisation de modèles ML supervisés et non supervisés
Voir un exemple de réponse
Pour détecter et filtrer les faux avis en temps réel sur un grand volume de données, on combine plusieurs techniques. En premier lieu, on extrait des features basées sur le comportement : fréquence de soumission, nombre d'avis par utilisateur, heures d'activité inhabituelles, utilisation de proxies ou VPN. Ensuite, une analyse textuelle calcule la similarité entre avis (cosinus TF-IDF), la tonalité (sentiment) et la présence de phrases répétitives qui peuvent indiquer du spam. On peut aussi construire un graphe social des utilisateurs pour détecter des communautés d'usurpateurs (sybil). Pour le traitement en temps réel, on utilise un pipeline de streaming avec Kafka pour ingérer les avis, puis un processeur comme Flink qui applique des règles heuristiques (par ex., tolérance de 5 avis identiques par IP) et un modèle de classification ML (régression logistique ou réseau de neurones) entraîné sur des échantillons étiquetés. Les avis suspects sont mis en quarantaine pour une révision manuelle ou automatiquement rejetés selon le seuil de confiance. Le système doit être évolutif : on partitionne les données par ID de produit ou utilisateur et on déploie le traitement sur plusieurs nœuds. Un défi est de réduire les faux positifs, car un avis authentique peut ressembler à un spam ; on peut utiliser un second modèle pour la reclassification.

Conseils pour se préparer

Entraînez-vous sur des problèmes LeetCode difficiles en vous concentrant sur le parcours de graphes (par exemple, Dijkstra, A*) et la programmation dynamique, car Meituan utilise souvent des scénarios de livraison/logistique.
Pour la conception système, étudiez les architectures à grande échelle comme celles des applications de covoiturage ou de livraison de repas. Soyez prêt à discuter des compromis entre cohérence, disponibilité et latence.
Alignez vos réponses comportementales sur les valeurs fondamentales de Meituan : client d'abord, focalisation sur l'impact à long terme et adoption de l'amélioration itérative. Utilisez des exemples spécifiques de votre expérience.
Préparez-vous à discuter de métriques business : comprenez comment les décisions d'ingénierie affectent les taux de conversion, les délais de livraison et la rétention des utilisateurs. Utilisez des chiffres et des KPI dans vos réponses.
Faites des entretiens simulés avec un chronomètre : les entretiens Meituan sont rapides. Entraînez-vous à penser à voix haute sous pression, en particulier pour le codage et la conception.

Questions fréquentes

Combien de rounds y a-t-il dans le processus d'entretien de Meituan ?

Généralement 3 à 5 rounds : 1 à 2 entretiens téléphoniques de codage, 1 à 2 rounds sur site de conception système et comportemental, et un entretien RH final. Certains postes ajoutent un exercice à domicile ou un round inter-équipes.

Quel est le niveau de difficulté des questions de codage ?

Moyen à difficile sur LeetCode. Attendez-vous à des problèmes de graphes (plus court chemin, variantes TSP) et de programmation dynamique. Les problèmes ont souvent un contexte réel lié à la livraison, la logistique ou l'ordonnancement.

Combien de temps dure l'ensemble du processus ?

Du premier entretien à l'offre, cela peut prendre 2 à 4 semaines, selon le niveau du poste et l'urgence. Chaque round dure généralement 45 à 60 minutes avec peu de pauses entre les rounds.

Que valorise le plus Meituan chez les candidats ?

De solides compétences en résolution de problèmes, la capacité à penser en systèmes et un état d'esprit centré client. Ils valorisent les ingénieurs pratiques capables de traduire les problèmes business en solutions techniques.

Comment puis-je me démarquer lors d'un entretien Meituan ?

Montrez une compréhension approfondie de l'activité de Meituan (livraison de repas, services en magasin, voyages). Reliez vos solutions à des scénarios réels de Meituan, discutez des compromis et démontrez une attitude 'je le fais' avec une communication claire.

Pratiquez les questions style Meituan avec un retour IA instantané

Téléchargez votre CV et Offersly lance un entretien simulé sur mesure, évalue vos réponses sur la pertinence, la profondeur, la clarté et la justesse, et vous montre exactement quoi améliorer.

Télécharger le CV pour commencer Parcourir toutes les questions d'entretien

Questions d'entretien Meituan

Sur quoi portent les entretiens chez Meituan

Codage et Algorithmes

Conception Système

Comportemental et Adéquation aux Valeurs

Sens des Affaires

Questions d'entretien courantes chez Meituan

Étant donné une liste de points de livraison (latitude/longitude) et un lieu de départ, trouvez l'itinéraire le plus court pour visiter tous les points et revenir.

Ce qu'une bonne réponse couvre

Problème NP-difficile => heuristique pour évolutivité
Utiliser la distance Haversine pour les coordonnées
Approche du plus proche voisin suivie d'optimisation 2-opt
Complexité O(n^2) pour l'heuristique, O(n^2) par itération 2-opt
Gestion de la symétrie des distances et du retour au point de départ

Voir un exemple de réponse

Solution de référencepython

import math
import itertools

# Calcul de la distance Haversine entre deux points (lat, lon) en degrés
def haversine(p1, p2):
    R = 6371  # rayon terrestre en km
    lat1, lon1 = math.radians(p1[0]), math.radians(p1[1])
    lat2, lon2 = math.radians(p2[0]), math.radians(p2[1])
    dlat = lat2 - lat1
    dlon = lon2 - lon1
    a = math.sin(dlat/2)**2 + math.cos(lat1)*math.cos(lat2)*math.sin(dlon/2)**2
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
    return R * c

# Algorithme du plus proche voisin pour TSP avec retour
# pts : liste des points (lat, lon), départ : indice du départ
# Retourne (chemin, distance) où chemin est une liste d'indices visités

def nearest_neighbor_tsp(pts, start):
    n = len(pts)
    visited = [False]*n
    chemin = [start]
    visited[start] = True
    total_dist = 0.0
    current = start
    for _ in range(n-1):
        nearest = None
        min_dist = float('inf')
        for i in range(n):
            if not visited[i]:
                d = haversine(pts[current], pts[i])
                if d < min_dist:
                    min_dist = d
                    nearest = i
        visited[nearest] = True
        chemin.append(nearest)
        total_dist += min_dist
        current = nearest
    # Retour au départ
    total_dist += haversine(pts[current], pts[start])
    chemin.append(start)
    return chemin, total_dist

# Exemple d'utilisation
points = [(48.8566, 2.3522), (45.7640, 4.8357), (43.2965, 5.3698)]
depart = 0
chemin, dist = nearest_neighbor_tsp(points, depart)
print("Itinéraire:", chemin)
print("Distance totale:", dist)

# Note : Pour améliorer, appliquer 2-opt après (non montré ici)

Concevez un système de suivi de commandes en temps réel pour des millions d'utilisateurs, en considérant la latence, la cohérence et la tolérance aux pannes.

Ce qu'une bonne réponse couvre

Faible latence via WebSockets et cache Redis
Cohérence éventuelle avec versioning ou horodatage
Sharding horizontal des bases de données (p. ex. Cassandra)
Tolérance aux pannes : réplication et files de messages (Kafka)
Architecture événementielle pour traitement asynchrone

Voir un exemple de réponse

Pour concevoir un système de suivi de commandes en temps réel pour des millions d'utilisateurs, il faut prioriser la faible latence et la disponibilité tout en maintenant une cohérence suffisante. L'architecture repose sur des services indépendants : les clients mobiles se connectent via WebSockets à un service de notification qui pousse les mises à jour d'état. Les commandes sont stockées dans une base de données NoSQL comme Cassandra, partitionnée par région ou ID de commande pour l'évolutivité. Pour la cohérence, chaque événement de changement d'état (commande préparée, en livraison, livrée) est horodaté et versionné, permettant une cohérence éventuelle. Les événements sont produits sur Kafka pour être consommés par les services de notification et de journalisation. Pour la tolérance aux pannes, chaque composant est déployé avec plusieurs réplicas, et Kafka assure la durabilité des événements. Un cache Redis en mémoire stocke l'état des commandes actives pour une lecture rapide. Le compromis clé est entre fraîcheur des données (cohérence forte) et latence : on accepte une courte fenêtre d'incohérence pour éviter les blocages. En cas de panne, le système peut être dégradé en affichant le dernier état connu.

Implémentez un cache avec politique d'éviction LRU supportant les opérations get et put en temps moyen O(1).

Ce qu'une bonne réponse couvre

Utiliser un dictionnaire (hashmap) pour l'accès O(1)
Maintenir une liste doublement chaînée pour l'ordre d'utilisation
Les opérations get et put mettent à jour l'ordre (déplacer en tête)
Supprimer le nœud de queue en cas de dépassement de capacité
Implémentation avec sentinelles pour éviter les cas limites

Voir un exemple de réponse

Solution de référencepython

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):
        self.cap = capacity
        self.cache = {}  # dict clé -> noeud
        # Sentinelles pour éviter les vérifications de None
        self.head = Node(0, 0)  # tête (le plus récent)
        self.tail = Node(0, 0)  # queue (le moins récent)
        self.head.next = self.tail
        self.tail.prev = self.head

    def _remove(self, node):
        # Supprime un noeud de la liste
        prev = node.prev
        nxt = node.next
        prev.next = nxt
        nxt.prev = prev

    def _add(self, node):
        # Ajoute un noeud juste après la tête (côté récent)
        node.prev = self.head
        node.next = self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key):
        if key in self.cache:
            node = self.cache[key]
            self._remove(node)
            self._add(node)
            return node.val
        return -1

    def put(self, key, value):
        if key in self.cache:
            node = self.cache[key]
            self._remove(node)
            node.val = value
            self._add(node)
        else:
            if len(self.cache) >= self.cap:
                # Supprime le moins récent (juste avant tail)
                lru = self.tail.prev
                self._remove(lru)
                del self.cache[lru.key]
            new_node = Node(key, value)
            self._add(new_node)
            self.cache[key] = new_node

Vous êtes responsable de l'amélioration du système de recommandation pour la livraison de repas de Meituan. Comment personnaliseriez-vous les recommandations tout en assurant la diversité ?

Ce qu'une bonne réponse couvre

Personnalisation via filtrage collaboratif et contenu
Utiliser le contexte (heure, météo, localisation) pour affiner
Assurer la diversité avec des algorithmes de reclassement (MMR)
Contrainte d'exploration vs exploitation : A/B test
Surveillance des métriques de diversité et de satisfaction

Voir un exemple de réponse

Pour améliorer le système de recommandation de livraison de repas de Meituan, la personnalisation doit combiner plusieurs signaux : l'historique des commandes, les préférences implicites (recherches, clics), et le contexte (heure du repas, météo, localisation). On peut utiliser une approche hybride : un modèle de filtrage collaboratif (MF) pour capturer les goûts similaires, et un modèle basé sur le contenu (catégories, prix, popularité) pour les nouveaux utilisateurs. Pour la diversité, on ne doit pas seulement recommander les plats les plus pertinents, mais aussi varier les restaurants et types de cuisine. Une technique consiste à utiliser un reclassement par similarité maximale marginale (MMR) qui pénalise les éléments trop similaires à ceux déjà recommandés. On peut aussi imposer des quotas par catégorie (par ex., pas plus de 2 plats du même restaurant). Un compromis important est entre exploitation (recommandations sûres) et exploration (nouveaux plats). On peut utiliser l'apprentissage par renforcement ou des A/B tests pour ajuster les paramètres. Il faut surveiller des métriques comme le taux de clics, la diversité (entropie des catégories) et la satisfaction à long terme.

Parlez-moi d'une fois où vous avez dû faire un compromis entre rapidité et qualité. Comment avez-vous décidé et quel a été le résultat ?

Ce qu'une bonne réponse couvre

Contexte : développement d'une fonctionnalité avec délai serré
Compromis : tests automatisés complets vs livraison rapide
Décision : prioriser les tests critiques et reporter les non-fonctionnels
Résultat : livraison dans les temps avec quelques bugs mineurs
Leçon : communication avec l'équipe pour ajuster les attentes

Voir un exemple de réponse

Dans un projet précédent, nous devions livrer une fonctionnalité de recherche améliorée pour une plateforme e-commerce. Le délai était très serré en raison d'une campagne marketing imminente. Je devais choisir entre une implémentation rapide avec des tests minimaux (priorisant la vitesse) ou une version plus robuste avec des tests complets mais risquant de manquer la date limite. J'ai analysé les risques : les zones critiques étaient la pertinence des résultats et la stabilité du backend. J'ai donc décidé de couvrir ces zones avec des tests unitaires et d'intégration, tout en reportant les tests de performance et de charge après le lancement. J'ai communiqué ma décision au responsable produit et à l'équipe QA, en explicitant les risques résiduels. La fonctionnalité a été livrée à temps. Il y a eu quelques bugs dans les cas d'utilisation avancés, mais ils ont été rapidement corrigés après le lancement. La campagne s'est bien déroulée, et nous avons ensuite ajouté les tests manquants. Cette expérience m'a appris l'importance de prioriser les fonctionnalités critiques et de maintenir une communication transparente sur les compromis.

Comment concevriez-vous un système de coupons/remises évolutif capable de gérer des ventes flash sans planter ?

Ce qu'une bonne réponse couvre

Préparation en amont : mise à jour des stocks dans Redis avant la vente flash
Limitation du trafic avec un token bucket distribué (p. ex. Redis rate limiter)
File d'attente des commandes pour lisser la charge (Kafka, RabbitMQ)
Idempotence des demandes pour éviter les doubles traitements
Dégradation gracieuse en cas de surcharge : présenter un message d'attente

Voir un exemple de réponse

Pour concevoir un système de coupons/remises évolutif capable de gérer des ventes flash sans planter, il faut anticiper les pics de trafic. Premièrement, la disponibilité des coupons est préchargée dans un cache Redis avec des compteurs atomiques pour chaque type de coupon. Pour éviter l'écrasement du serveur, on met en place un limiteur de débit distribué (token bucket) au niveau de l'API, qui rejette les requêtes en excès avec un code 429 (Too Many Requests). Les demandes acceptées sont placées dans une file d'attente asynchrone (Kafka ou RabbitMQ) pour être traitées de manière asynchrone. Le traitement inclut la vérification de l'éligibilité et la réservation du coupon avec des opérations atomiques dans Redis. Pour éviter les doubles réservations, chaque demande contient un identifiant unique (idempotence), ce qui permet de détecter et ignorer les doublons. Les bases de données relationnelles sont utilisées pour la persistance finale avec des transactions optimistes. En cas de charge extrême, on peut dégrader gracieusement en affichant une file d'attente virtuelle ou un message de réessai. Un monitoring en temps réel des métriques (taux de succès, latence) permet de réagir rapidement.

Décrivez une situation où vous étiez en désaccord avec votre manager sur une direction technique. Comment avez-vous géré cela ?

Ce qu'une bonne réponse couvre

Contexte : divergence sur la migration vers une architecture microservices
Action : présenter des données de performance et coûts estimés
Compromis : proposer un prototype pour valider les gains
Résultat : adoption partielle avec transition progressive
Leçon : respecter l'expérience du manager tout en défendant ses idées

Voir un exemple de réponse

Lors d'un projet de refonte d'un système monolithique, mon manager préférait une approche incrémentale consistant à améliorer le monolithe existant, tandis que je pensais qu'une migration vers des microservices apporterait une meilleure scalabilité et une indépendance des équipes. Pour gérer ce désaccord, j'ai préparé une analyse comparative montrant les bénéfices potentiels en termes de temps de déploiement et de tolérance aux pannes, ainsi que les coûts de développement et d'infrastructure. J'ai proposé de construire un prototype de microservice pour un sous-domaine non critique (par exemple, le service de notifications) et de le comparer avec l'approche monolithique sur des métriques mesurables (latence, débit). Mon manager a accepté le prototype. Après trois semaines, les résultats ont montré une amélioration significative de la scalabilité pour cette partie. Nous avons alors décidé de migrer progressivement les autres services, en commençant par ceux qui bénéficieraient le plus de l'indépendance. Cette expérience m'a appris à fonder mes arguments sur des données et à faire preuve de flexibilité en proposant des compromis concrets.

Étant donné un grand ensemble de données d'avis d'utilisateurs, concevez un système pour détecter et filtrer les faux avis en temps réel.

Ce qu'une bonne réponse couvre

Différenciation par le comportement : fréquence, horaires, IP
Analyse textuelle : sentiment, similarité, répétitions
Détection de communautés (sybil) via graphe des utilisateurs
Flux en temps réel avec Kafka/Storm/Flink
Utilisation de modèles ML supervisés et non supervisés

Voir un exemple de réponse

Pour détecter et filtrer les faux avis en temps réel sur un grand volume de données, on combine plusieurs techniques. En premier lieu, on extrait des features basées sur le comportement : fréquence de soumission, nombre d'avis par utilisateur, heures d'activité inhabituelles, utilisation de proxies ou VPN. Ensuite, une analyse textuelle calcule la similarité entre avis (cosinus TF-IDF), la tonalité (sentiment) et la présence de phrases répétitives qui peuvent indiquer du spam. On peut aussi construire un graphe social des utilisateurs pour détecter des communautés d'usurpateurs (sybil). Pour le traitement en temps réel, on utilise un pipeline de streaming avec Kafka pour ingérer les avis, puis un processeur comme Flink qui applique des règles heuristiques (par ex., tolérance de 5 avis identiques par IP) et un modèle de classification ML (régression logistique ou réseau de neurones) entraîné sur des échantillons étiquetés. Les avis suspects sont mis en quarantaine pour une révision manuelle ou automatiquement rejetés selon le seuil de confiance. Le système doit être évolutif : on partitionne les données par ID de produit ou utilisateur et on déploie le traitement sur plusieurs nœuds. Un défi est de réduire les faux positifs, car un avis authentique peut ressembler à un spam ; on peut utiliser un second modèle pour la reclassification.

Conseils pour se préparer

Entraînez-vous sur des problèmes LeetCode difficiles en vous concentrant sur le parcours de graphes (par exemple, Dijkstra, A*) et la programmation dynamique, car Meituan utilise souvent des scénarios de livraison/logistique.

Pour la conception système, étudiez les architectures à grande échelle comme celles des applications de covoiturage ou de livraison de repas. Soyez prêt à discuter des compromis entre cohérence, disponibilité et latence.

Alignez vos réponses comportementales sur les valeurs fondamentales de Meituan : client d'abord, focalisation sur l'impact à long terme et adoption de l'amélioration itérative. Utilisez des exemples spécifiques de votre expérience.

Préparez-vous à discuter de métriques business : comprenez comment les décisions d'ingénierie affectent les taux de conversion, les délais de livraison et la rétention des utilisateurs. Utilisez des chiffres et des KPI dans vos réponses.

Faites des entretiens simulés avec un chronomètre : les entretiens Meituan sont rapides. Entraînez-vous à penser à voix haute sous pression, en particulier pour le codage et la conception.

Questions fréquentes

Combien de rounds y a-t-il dans le processus d'entretien de Meituan ?

Quel est le niveau de difficulté des questions de codage ?

Combien de temps dure l'ensemble du processus ?

Du premier entretien à l'offre, cela peut prendre 2 à 4 semaines, selon le niveau du poste et l'urgence. Chaque round dure généralement 45 à 60 minutes avec peu de pauses entre les rounds.