Questions d'entretien Huawei

Le processus d'entretien de Huawei est réputé pour sa rigueur et sa profondeur, impliquant souvent plusieurs rounds qui testent l'expertise technique, la résolution de problèmes et l'adéquation culturelle. Les candidats rapportent généralement un fort accent sur les fondamentaux, la conception de systèmes et l'alignement avec les valeurs de Huawei de travail acharné et de dévouement. La préparation doit couvrir à la fois des connaissances techniques approfondies et des scénarios comportementaux démontrant la résilience et le travail d'équipe.

Commencer un entretien simulé gratuit

Sur quoi portent les entretiens chez Huawei

Fondamentaux Techniques

Huawei met fortement l'accent sur une solide compréhension des concepts fondamentaux de l'informatique comme les structures de données, les algorithmes, les systèmes d'exploitation et les réseaux. Attendez-vous à des questions approfondies sur ces sujets.

Codage et Résolution de Problèmes

Les candidats sont généralement confrontés à des défis de codage sur un tableau blanc ou une plateforme en ligne, axés sur des algorithmes efficaces et un code propre. Entraînez-vous aux structures de données et motifs algorithmiques courants.

Conception Système

Pour les postes expérimentés, les entretiens de conception système évaluent la capacité à architecturer des systèmes distribués évolutifs. Huawei valorise une connaissance pratique des systèmes à grande échelle, des microservices et des technologies cloud.

Comportemental et Adéquation Culturelle

Huawei recherche des candidats démontrant dévouement, travail d'équipe et un état d'esprit de 'culture de la lutte'. Les questions explorent souvent comment vous gérez la pression, les conflits et les projets à long terme.

Questions d'entretien courantes chez Huawei

Implémentez une fonction pour trouver la plus longue sous-chaîne sans caractères répétés.
Ce qu'une bonne réponse couvre
- Utiliser une fenêtre glissante avec deux pointeurs (gauche et droite).
- Employer une table de hachage pour stocker la dernière position de chaque caractère.
- Mettre à jour le pointeur gauche lorsque un caractère est répété dans la fenêtre.
- Complexité temporelle O(n) et spatiale O(min(n, alphabet)) où alphabet est la taille du jeu de caractères.
- Gérer le cas de la chaîne vide (retourner 0).
Voir un exemple de réponse
Pour trouver la plus longue sous-chaîne sans caractères répétés, on utilise une approche de fenêtre glissante avec deux pointeurs (gauche et droite) et une table de hachage. On parcourt la chaîne avec le pointeur droite, et pour chaque caractère, on vérifie s'il est déjà dans la fenêtre via la table de hachage. Si oui, on déplace le pointeur gauche juste après la dernière occurrence de ce caractère (ou on le maintient s'il est déjà plus loin). On met à jour la position du caractère dans la table et on calcule la longueur maximale. Cette méthode est efficace avec une complexité O(n) en temps et O(min(n, taille de l'alphabet)) en espace. Un piège courant est d'oublier que lorsque l'on rencontre un caractère répété, la nouvelle position de gauche doit être le maximum entre l'ancienne gauche et la dernière occurrence+1 pour éviter de rétrécir la fenêtre incorrectement. Il faut aussi initialiser maximale à 0 et gérer le cas d'une chaîne vide. La solution fonctionne pour tout jeu de caractères (ASCII ou Unicode) si la table de hachage est adaptée.
Solution de référencepython
def longueur_plus_longue_sous_chaine_sans_repetition(s: str) -> int: # Table de hachage pour stocker la dernière position de chaque caractère derniere_position = {} gauche = 0 max_longueur = 0 for droite, caractere in enumerate(s): # Si le caractère est déjà dans la fenêtre, déplacer gauche if caractere in derniere_position and derniere_position[caractere] >= gauche: gauche = derniere_position[caractere] + 1 # Mettre à jour la dernière position du caractère derniere_position[caractere] = droite # Calculer la longueur actuelle et mettre à jour le maximum max_longueur = max(max_longueur, droite - gauche + 1) return max_longueur # Complexité temporelle: O(n) - parcours unique de la chaîne # Complexité spatiale: O(min(n, taille de l'alphabet)) - stockage des positions
Décrivez les différences entre TCP et UDP. Quand utiliseriez-vous chacun ?
Ce qu'une bonne réponse couvre
- TCP est orienté connexion, fiable, avec contrôle de flux et de congestion. UDP est sans connexion et non fiable.
- TCP garantit la livraison et l'ordre des paquets, UDP ne garantit rien (perte possible).
- TCP a une surcharge plus élevée (en-tête 20 octets, accusés de réception), UDP a une faible surcharge (8 octets).
- Utiliser TCP pour des applications où la fiabilité est cruciale (transfert de fichiers, Web, email).
- Utiliser UDP pour des applications en temps réel où la vitesse prime (streaming, jeux en ligne, VoIP).
Voir un exemple de réponse
TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) sont deux protocoles de transport dans la couche 4 du modèle OSI. TCP est orienté connexion : avant d'envoyer des données, une connexion est établie via une poignée de main à trois voies. Il assure la fiabilité par les accusés de réception, la retransmission des paquets perdus et le réordonnancement. Il implémente également un contrôle de flux (évite de submerger le récepteur) et un contrôle de congestion (adapte le débit au réseau). En revanche, UDP est sans connexion : il envoie des datagrammes sans établissement préalable, sans garantie de livraison ni d'ordre. Il n'y a pas de mécanisme de contrôle de flux ou de congestion. La surcharge de TCP est plus importante (en-tête de 20 à 60 octets) tandis que UDP a un en-tête fixe de 8 octets. On choisit TCP pour les applications nécessitant une transmission fiable : HTTP/HTTPS, FTP, email, bases de données. On choisit UDP pour les applications temps réel ou multicast où une perte occasionnelle est acceptable : streaming vidéo/audio, jeux en ligne, VoIP, DNS. Il existe aussi des protocoles hybrides comme QUIC qui utilisent UDP avec une couche de fiabilité au-dessus.
Expliquez comment vous concevriez un système de stockage de fichiers distribué comme HDFS.
Ce qu'une bonne réponse couvre
- Architecture centralisée avec un NameNode (maître) et plusieurs DataNodes (esclaves).
- Les fichiers sont divisés en blocs (par défaut 128 Mo) répliqués sur plusieurs DataNodes pour la tolérance aux pannes.
- Le NameNode gère les métadonnées (arborescence, emplacement des blocs) et les DataNodes stockent les blocs.
- L'écriture : le client contacte le NameNode, qui alloue des DataNodes pour la réplication, puis le client écrit les blocs en pipeline.
- La lecture : le client demande au NameNode les emplacements des blocs, puis lit directement depuis un DataNode proche.
Voir un exemple de réponse
Un système de stockage distribué comme HDFS (Hadoop Distributed File System) est conçu pour stocker de très gros fichiers sur un cluster de machines. L'architecture est de type maître-esclave avec un NameNode (maître) qui gère les métadonnées (arborescence des répertoires, permissions, correspondance entre fichiers et blocs, et emplacement des blocs) et plusieurs DataNodes (esclaves) qui stockent les blocs de données sur le disque. Les fichiers sont divisés en blocs de taille fixe (128 Mo par défaut), et chaque bloc est répliqué sur plusieurs DataNodes (facteur de réplication typique 3) pour assurer la tolérance aux pannes. Le NameNode est le point central : le client interagit d'abord avec lui pour obtenir les emplacements des blocs. Lors de l'écriture, le client contacte le NameNode pour savoir où écrire les blocs ; le NameNode sélectionne des DataNodes pour chaque réplica, et le client écrit les données en pipeline vers le premier DataNode, qui les transmet au suivant, etc. Lors de la lecture, le client demande au NameNode la liste des DataNodes contenant chaque bloc, puis lit le bloc depuis le DataNode le plus proche (généralement le premier de la liste) pour minimiser le trafic réseau. La scalabilité horizontale est obtenue en ajoutant des DataNodes. Le principal défaut est le point unique de défaillance du NameNode ; des solutions comme HDFS HA (High Availability) avec un NameNode secondaire actif-passif existent. D'autres pièges incluent la gestion des petits fichiers (nombreux blocs, pression sur le NameNode) et la latence élevée pour les opérations de métadonnées.
Parlez-moi d'une fois où vous avez eu un conflit avec un membre de l'équipe. Comment l'avez-vous résolu ?
Ce qu'une bonne réponse couvre
- Situation : Projet de refonte d'un module, désaccord sur l'architecture (monolithique vs microservices).
- Tâche : Trouver une solution qui satisfasse les exigences techniques et les préférences de l'équipe.
- Action : Organisation d'une réunion de design, présentation des arguments avec des données de performance, écoute active, compromis sur une architecture hybride.
- Résultat : Solution adoptée par tous, délais respectés, amélioration de la collaboration.
Voir un exemple de réponse
Lors d'un projet de refonte d'un module critique, un collègue insistait pour une approche monolithique tandis que je préférais des microservices pour la scalabilité future. La situation devenait tendue car nous devions livrer rapidement. J'ai proposé une réunion de design dédiée. J'ai préparé des benchmarks montrant que les microservices réduiraient le temps de déploiement de 30% et faciliteraient l'isolation des pannes. J'ai écouté ses préoccupations sur la complexité opérationnelle et le surcoût de la communication inter-services. Nous avons alors convenu d'une architecture hybride : le module serait divisé en deux microservices seulement, avec un mécanisme de communication asynchrone simple, et le reste resterait monolithique. J'ai proposé de gérer la configuration Docker et Kubernetes pour simplifier le déploiement. Le résultat a été une livraison à temps, avec une flexibilité accrue pour les évolutions futures, et une meilleure entente dans l'équipe. Cette expérience m'a appris l'importance de l'écoute active et du compromis basé sur des données.
Écrivez du code pour inverser une liste chaînée de manière itérative et récursive.
Ce qu'une bonne réponse couvre
- Itératif : utiliser trois pointeurs (précédent, courant, suivant) pour inverser les liens.
- Récursif : inverser récursivement la sous-liste à partir du nœud suivant, puis ajuster les pointeurs.
- Complexité temporelle O(n) pour les deux, spatiale O(1) pour l'itératif, O(n) pour le récursif (pile d'appels).
- Attention à ne pas perdre le reste de la liste lors de l'itération.
- La version récursive nécessite un cas de base (liste vide ou un seul nœud).
Voir un exemple de réponse
Pour inverser une liste chaînée, nous avons deux approches principales : itérative et récursive. La version itérative utilise trois pointeurs : précédent (initialisé à None), courant (tête de la liste), et suivant. On parcourt la liste en boucle : à chaque étape, on sauvegarde le nœud suivant, on inverse le lien du nœud courant vers précédent, puis on avance précédent et courant. À la fin, précédent devient la nouvelle tête. La version récursive procède en inversant d'abord le reste de la liste (à partir du nœud suivant), puis en attachant le nœud courant à la fin de la liste inversée. Le cas de base est une liste vide ou un seul nœud (on retourne la tête). Les deux ont une complexité temporelle O(n). L'itératif utilise O(1) d'espace supplémentaire, tandis que le récursif utilise O(n) d'espace de pile. L'implémentation itérative est généralement préférée en production pour éviter les risques de débordement de pile. Un piège courant dans l'itératif est de ne pas correctement mettre à jour les pointeurs, ce qui peut créer des cycles ou perdre des nœuds. Dans la version récursive, il faut s'assurer que la tête de la liste inversée est correctement renvoyée par le dernier appel récursif.
Solution de référencepython
class ListNode: def __init__(self, val=0, next=None): self.val = val self.next = next def reverse_iterative(head: ListNode) -> ListNode: # Itératif : trois pointeurs precedent = None courant = head while courant: suivant = courant.next # sauvegarder le suivant courant.next = precedent # inverser le lien precedent = courant # avancer precedent courant = suivant # avancer courant return precedent # nouvelle tête def reverse_recursive(head: ListNode) -> ListNode: # Récursif : inverser le reste puis attacher # Cas de base : liste vide ou un seul nœud if head is None or head.next is None: return head # Inverser la sous-liste à partir de head.next nouvelle_tete = reverse_recursive(head.next) # Attacher head à la fin de la sous-liste inversée head.next.next = head head.next = None return nouvelle_tete # Complexité temporelle: O(n) pour les deux # Complexité spatiale: O(1) itératif, O(n) récursif (pile)
Comment fonctionne un index de base de données relationnelle ? Décrivez l'index B-tree vs hash.
Ce qu'une bonne réponse couvre
- Un index de base de données accélère les requêtes en permettant un accès rapide aux lignes via des structures de données.
- L'index B-tree organise les données dans un arbre équilibré, adapté aux requêtes de plage (range) et d'égalité.
- L'index hash utilise une table de hachage pour des accès directs par égalité, inefficace pour les plages.
- Le B-tree est l'index par défaut dans la plupart des SGBDR (ordre de grandeur O(log n) pour les opérations).
- Le hash index est utile pour les recherches par clé unique avec une complexité O(1) en moyenne, mais pas de tri.
Voir un exemple de réponse
Un index de base de données relationnelle est une structure de données qui améliore la vitesse des opérations de sélection (SELECT) sur une table, au prix d'espace de stockage supplémentaire et d'une légère dégradation des opérations d'écriture (INSERT, UPDATE, DELETE). Les deux types d'index les plus courants sont le B-tree (arbre B) et le hash (table de hachage). L'index B-tree est un arbre équilibré où chaque nœud contient plusieurs clés et pointeurs vers des enfants. Il maintient les clés triées, ce qui permet de supporter efficacement les requêtes d'égalité (WHERE id = 5) et de plage (WHERE id BETWEEN 10 AND 20) ainsi que les tris (ORDER BY). La complexité temporelle d'une recherche dans un B-tree est O(log n). L'index hash, quant à lui, utilise une fonction de hachage sur la clé pour obtenir une adresse directe dans une table de hachage. Il est très rapide pour les recherches par égalité (O(1) en moyenne), mais ne supporte pas les recherches de plage ou le tri. Il est souvent utilisé pour des index sur des colonnes avec beaucoup de valeurs uniques, comme les clés primaires dans certains moteurs (Memory de MySQL). Le choix entre B-tree et hash dépend donc du type de requêtes : pour des applications avec beaucoup de recherches par plage ou de tris, le B-tree est préférable ; pour des recherches ponctuelles intensives, le hash peut être plus performant. D'autres index existent comme les index bitmap ou GiST pour des besoins spécialisés.
Concevez un système de chat en temps réel similaire à WhatsApp. Discutez de l'architecture, du stockage des données et du passage à l'échelle.
Ce qu'une bonne réponse couvre
- Architecture : clients mobiles/services, serveurs de présence, gestionnaires de messages, stockage persistant.
- Utiliser WebSockets pour la communication en temps réel entre clients et serveurs.
- Stockage des messages : base de données distribuée (Cassandra) pour l'historique, cache Redis pour les messages récents.
- File d'attente de messages (Kafka) pour découpler l'envoi et la réception, assurer l'ordre et la fiabilité.
- Scalabilité : partitionnement des utilisateurs (sharding) par ID, équilibrage de charge, réplication géographique.
Voir un exemple de réponse
Un système de chat en temps réel comme WhatsApp repose sur une architecture client-serveur avec communication persistante via WebSockets. Le système comprend plusieurs composants : un serveur de connexion/gestion de sessions (pour gérer les WebSockets), un serveur de présence (indique si un utilisateur est en ligne), un gestionnaire de messages (qui reçoit un message, le stocke et le transmet au destinataire), et un service de notification push (pour les mobiles en arrière-plan). Les messages sont d'abord envoyés à un serveur via WebSocket, puis stockés dans une base de données distribuée comme Cassandra (pour l'historique) et temporairement dans un cache Redis (pour les messages récents). Un système de files d'attente comme Kafka assure l'ordre FIFO par conversation et permet de découpler les composants pour la résilience. Pour le passage à l'échelle, on partitionne les utilisateurs par ID (hash) sur plusieurs instances de serveur, avec un répartiteur de charge (load balancer) en entrée. La réplication géographique des serveurs réduit la latence. Le stockage des messages doit être dimensionné pour des milliards de messages par jour : on utilise un partitionnement temporel et par utilisateur. La livraison des messages nécessite un mécanisme de confirmation (ack) et de retransmission en cas d'échec. Pour les discussions de groupe, on peut utiliser un fan-out avec copie des messages ou une approche centralisée.
Décrivez un projet ambitieux que vous avez dirigé. Quel était votre rôle et le résultat ?
Ce qu'une bonne réponse couvre
- Situation : Projet de migration d'une application monolithique vers une architecture microservices au sein d'une équipe de 8 personnes.
- Tâche : Diriger la conception, le découpage en services, la mise en place de l'infrastructure et la coordination des développeurs.
- Action : Définition des limites des services basée sur les domaines métier (DDD), choix de technologies (Docker, Kubernetes), organisation en sprints, revues de code régulières.
- Résultat : Migration réussie en 6 mois, amélioration de la scalabilité (capacité à gérer 3x plus de requêtes), déploiements plus rapides (de 2 heures à 10 minutes).
Voir un exemple de réponse
Dans mon précédent poste, j'ai dirigé un projet ambitieux de migration d'une application monolithique vieillissante vers une architecture microservices. L'équipe était composée de 8 développeurs. Mon rôle était de définir la stratégie de découpage, de choisir les technologies et de coordonner les sprints. J'ai commencé par une analyse du domaine métier en utilisant le Domain-Driven Design pour identifier les limites des services. Nous avons ensuite implémenté une infrastructure avec Docker et Kubernetes pour l'orchestration. J'ai mis en place des pipelines CI/CD avec Jenkins pour automatiser les tests et les déploiements. J'ai organisé des revues de code régulières et des sessions de pair programming pour assurer la qualité. Un défi majeur a été de gérer la dette technique héritée et de former l'équipe aux nouvelles technologies. J'ai organisé des ateliers techniques et des démonstrations. Le résultat a été une migration réussie en 6 mois : l'application a pu gérer trois fois plus de requêtes simultanées, les déploiements sont passés de 2 heures à 10 minutes, et l'équipe a gagné en autonomie. Ce projet a considérablement amélioré la performance et la maintenabilité du système.

Conseils pour se préparer

Révisez minutieusement les sujets fondamentaux de l'informatique : structures de données, algorithmes, OS et réseaux.
Entraînez-vous à coder sur un tableau blanc ou dans un éditeur de texte simple sans coloration syntaxique.
Pour la conception système, étudiez les systèmes à grande échelle comme les bases de données distribuées, les équilibreurs de charge et le cache.
Préparez des exemples spécifiques de dépassement d'adversité ou de travail sous des délais serrés pour démontrer la résilience.
Recherchez la culture d'entreprise et les valeurs de Huawei, en particulier les concepts comme 'l'esprit du loup' et le dévouement à la réussite client.

Questions fréquentes

Combien de rounds y a-t-il dans un entretien Huawei ?

Généralement 3 à 5 rounds : un entretien téléphonique initial, 1 à 2 rounds techniques, un round de conception système (pour les postes seniors) et un round RH/comportemental. Certains postes incluent un entretien de groupe.

Quelle est la difficulté des entretiens Huawei ?

Ils sont considérés comme modérément à très difficiles, avec un fort accent sur la profondeur technique et la résolution de problèmes. Attendez-vous à des questions algorithmiques difficiles et des discussions théoriques approfondies.

Combien de temps dure l'ensemble du processus ?

Du premier contact à l'offre, cela peut prendre 2 à 6 semaines selon le poste et le nombre de rounds. Huawei avance souvent rapidement pour les candidats solides.

Que valorise le plus Huawei chez les candidats ?

La compétence technique, la capacité de résolution de problèmes, l'adéquation culturelle avec leur éthique de travail rigoureuse et un état d'esprit 'client d'abord'. Ils valorisent également l'adaptabilité et l'apprentissage continu.

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

Démontrez une connaissance technique approfondie avec des explications claires, montrez votre passion pour la technologie et fournissez des exemples concrets de dépassement de défis. Aligner vos réponses sur les valeurs fondamentales de Huawei aide.

Pratiquez les questions style Huawei 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 Huawei

Sur quoi portent les entretiens chez Huawei

Fondamentaux Techniques

Codage et Résolution de Problèmes

Conception Système

Comportemental et Adéquation Culturelle

Questions d'entretien courantes chez Huawei

Implémentez une fonction pour trouver la plus longue sous-chaîne sans caractères répétés.

Ce qu'une bonne réponse couvre

Utiliser une fenêtre glissante avec deux pointeurs (gauche et droite).
Employer une table de hachage pour stocker la dernière position de chaque caractère.
Mettre à jour le pointeur gauche lorsque un caractère est répété dans la fenêtre.
Complexité temporelle O(n) et spatiale O(min(n, alphabet)) où alphabet est la taille du jeu de caractères.
Gérer le cas de la chaîne vide (retourner 0).

Voir un exemple de réponse

Pour trouver la plus longue sous-chaîne sans caractères répétés, on utilise une approche de fenêtre glissante avec deux pointeurs (gauche et droite) et une table de hachage. On parcourt la chaîne avec le pointeur droite, et pour chaque caractère, on vérifie s'il est déjà dans la fenêtre via la table de hachage. Si oui, on déplace le pointeur gauche juste après la dernière occurrence de ce caractère (ou on le maintient s'il est déjà plus loin). On met à jour la position du caractère dans la table et on calcule la longueur maximale. Cette méthode est efficace avec une complexité O(n) en temps et O(min(n, taille de l'alphabet)) en espace. Un piège courant est d'oublier que lorsque l'on rencontre un caractère répété, la nouvelle position de gauche doit être le maximum entre l'ancienne gauche et la dernière occurrence+1 pour éviter de rétrécir la fenêtre incorrectement. Il faut aussi initialiser maximale à 0 et gérer le cas d'une chaîne vide. La solution fonctionne pour tout jeu de caractères (ASCII ou Unicode) si la table de hachage est adaptée.

Solution de référencepython

def longueur_plus_longue_sous_chaine_sans_repetition(s: str) -> int:
    # Table de hachage pour stocker la dernière position de chaque caractère
    derniere_position = {}
    gauche = 0
    max_longueur = 0

    for droite, caractere in enumerate(s):
        # Si le caractère est déjà dans la fenêtre, déplacer gauche
        if caractere in derniere_position and derniere_position[caractere] >= gauche:
            gauche = derniere_position[caractere] + 1
        # Mettre à jour la dernière position du caractère
        derniere_position[caractere] = droite
        # Calculer la longueur actuelle et mettre à jour le maximum
        max_longueur = max(max_longueur, droite - gauche + 1)

    return max_longueur

# Complexité temporelle: O(n) - parcours unique de la chaîne
# Complexité spatiale: O(min(n, taille de l'alphabet)) - stockage des positions

Décrivez les différences entre TCP et UDP. Quand utiliseriez-vous chacun ?

Ce qu'une bonne réponse couvre

TCP est orienté connexion, fiable, avec contrôle de flux et de congestion. UDP est sans connexion et non fiable.
TCP garantit la livraison et l'ordre des paquets, UDP ne garantit rien (perte possible).
TCP a une surcharge plus élevée (en-tête 20 octets, accusés de réception), UDP a une faible surcharge (8 octets).
Utiliser TCP pour des applications où la fiabilité est cruciale (transfert de fichiers, Web, email).
Utiliser UDP pour des applications en temps réel où la vitesse prime (streaming, jeux en ligne, VoIP).

Voir un exemple de réponse

TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) sont deux protocoles de transport dans la couche 4 du modèle OSI. TCP est orienté connexion : avant d'envoyer des données, une connexion est établie via une poignée de main à trois voies. Il assure la fiabilité par les accusés de réception, la retransmission des paquets perdus et le réordonnancement. Il implémente également un contrôle de flux (évite de submerger le récepteur) et un contrôle de congestion (adapte le débit au réseau). En revanche, UDP est sans connexion : il envoie des datagrammes sans établissement préalable, sans garantie de livraison ni d'ordre. Il n'y a pas de mécanisme de contrôle de flux ou de congestion. La surcharge de TCP est plus importante (en-tête de 20 à 60 octets) tandis que UDP a un en-tête fixe de 8 octets. On choisit TCP pour les applications nécessitant une transmission fiable : HTTP/HTTPS, FTP, email, bases de données. On choisit UDP pour les applications temps réel ou multicast où une perte occasionnelle est acceptable : streaming vidéo/audio, jeux en ligne, VoIP, DNS. Il existe aussi des protocoles hybrides comme QUIC qui utilisent UDP avec une couche de fiabilité au-dessus.

Expliquez comment vous concevriez un système de stockage de fichiers distribué comme HDFS.

Ce qu'une bonne réponse couvre

Architecture centralisée avec un NameNode (maître) et plusieurs DataNodes (esclaves).
Les fichiers sont divisés en blocs (par défaut 128 Mo) répliqués sur plusieurs DataNodes pour la tolérance aux pannes.
Le NameNode gère les métadonnées (arborescence, emplacement des blocs) et les DataNodes stockent les blocs.
L'écriture : le client contacte le NameNode, qui alloue des DataNodes pour la réplication, puis le client écrit les blocs en pipeline.
La lecture : le client demande au NameNode les emplacements des blocs, puis lit directement depuis un DataNode proche.

Voir un exemple de réponse

Un système de stockage distribué comme HDFS (Hadoop Distributed File System) est conçu pour stocker de très gros fichiers sur un cluster de machines. L'architecture est de type maître-esclave avec un NameNode (maître) qui gère les métadonnées (arborescence des répertoires, permissions, correspondance entre fichiers et blocs, et emplacement des blocs) et plusieurs DataNodes (esclaves) qui stockent les blocs de données sur le disque. Les fichiers sont divisés en blocs de taille fixe (128 Mo par défaut), et chaque bloc est répliqué sur plusieurs DataNodes (facteur de réplication typique 3) pour assurer la tolérance aux pannes. Le NameNode est le point central : le client interagit d'abord avec lui pour obtenir les emplacements des blocs. Lors de l'écriture, le client contacte le NameNode pour savoir où écrire les blocs ; le NameNode sélectionne des DataNodes pour chaque réplica, et le client écrit les données en pipeline vers le premier DataNode, qui les transmet au suivant, etc. Lors de la lecture, le client demande au NameNode la liste des DataNodes contenant chaque bloc, puis lit le bloc depuis le DataNode le plus proche (généralement le premier de la liste) pour minimiser le trafic réseau. La scalabilité horizontale est obtenue en ajoutant des DataNodes. Le principal défaut est le point unique de défaillance du NameNode ; des solutions comme HDFS HA (High Availability) avec un NameNode secondaire actif-passif existent. D'autres pièges incluent la gestion des petits fichiers (nombreux blocs, pression sur le NameNode) et la latence élevée pour les opérations de métadonnées.

Parlez-moi d'une fois où vous avez eu un conflit avec un membre de l'équipe. Comment l'avez-vous résolu ?

Ce qu'une bonne réponse couvre

Situation : Projet de refonte d'un module, désaccord sur l'architecture (monolithique vs microservices).
Tâche : Trouver une solution qui satisfasse les exigences techniques et les préférences de l'équipe.
Action : Organisation d'une réunion de design, présentation des arguments avec des données de performance, écoute active, compromis sur une architecture hybride.
Résultat : Solution adoptée par tous, délais respectés, amélioration de la collaboration.

Voir un exemple de réponse

Lors d'un projet de refonte d'un module critique, un collègue insistait pour une approche monolithique tandis que je préférais des microservices pour la scalabilité future. La situation devenait tendue car nous devions livrer rapidement. J'ai proposé une réunion de design dédiée. J'ai préparé des benchmarks montrant que les microservices réduiraient le temps de déploiement de 30% et faciliteraient l'isolation des pannes. J'ai écouté ses préoccupations sur la complexité opérationnelle et le surcoût de la communication inter-services. Nous avons alors convenu d'une architecture hybride : le module serait divisé en deux microservices seulement, avec un mécanisme de communication asynchrone simple, et le reste resterait monolithique. J'ai proposé de gérer la configuration Docker et Kubernetes pour simplifier le déploiement. Le résultat a été une livraison à temps, avec une flexibilité accrue pour les évolutions futures, et une meilleure entente dans l'équipe. Cette expérience m'a appris l'importance de l'écoute active et du compromis basé sur des données.

Écrivez du code pour inverser une liste chaînée de manière itérative et récursive.

Ce qu'une bonne réponse couvre

Itératif : utiliser trois pointeurs (précédent, courant, suivant) pour inverser les liens.
Récursif : inverser récursivement la sous-liste à partir du nœud suivant, puis ajuster les pointeurs.
Complexité temporelle O(n) pour les deux, spatiale O(1) pour l'itératif, O(n) pour le récursif (pile d'appels).
Attention à ne pas perdre le reste de la liste lors de l'itération.
La version récursive nécessite un cas de base (liste vide ou un seul nœud).

Voir un exemple de réponse

Pour inverser une liste chaînée, nous avons deux approches principales : itérative et récursive. La version itérative utilise trois pointeurs : précédent (initialisé à None), courant (tête de la liste), et suivant. On parcourt la liste en boucle : à chaque étape, on sauvegarde le nœud suivant, on inverse le lien du nœud courant vers précédent, puis on avance précédent et courant. À la fin, précédent devient la nouvelle tête. La version récursive procède en inversant d'abord le reste de la liste (à partir du nœud suivant), puis en attachant le nœud courant à la fin de la liste inversée. Le cas de base est une liste vide ou un seul nœud (on retourne la tête). Les deux ont une complexité temporelle O(n). L'itératif utilise O(1) d'espace supplémentaire, tandis que le récursif utilise O(n) d'espace de pile. L'implémentation itérative est généralement préférée en production pour éviter les risques de débordement de pile. Un piège courant dans l'itératif est de ne pas correctement mettre à jour les pointeurs, ce qui peut créer des cycles ou perdre des nœuds. Dans la version récursive, il faut s'assurer que la tête de la liste inversée est correctement renvoyée par le dernier appel récursif.

Solution de référencepython

class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next

def reverse_iterative(head: ListNode) -> ListNode:
    # Itératif : trois pointeurs
    precedent = None
    courant = head
    while courant:
        suivant = courant.next  # sauvegarder le suivant
        courant.next = precedent  # inverser le lien
        precedent = courant  # avancer precedent
        courant = suivant  # avancer courant
    return precedent  # nouvelle tête

def reverse_recursive(head: ListNode) -> ListNode:
    # Récursif : inverser le reste puis attacher
    # Cas de base : liste vide ou un seul nœud
    if head is None or head.next is None:
        return head
    # Inverser la sous-liste à partir de head.next
    nouvelle_tete = reverse_recursive(head.next)
    # Attacher head à la fin de la sous-liste inversée
    head.next.next = head
    head.next = None
    return nouvelle_tete

# Complexité temporelle: O(n) pour les deux
# Complexité spatiale: O(1) itératif, O(n) récursif (pile)

Comment fonctionne un index de base de données relationnelle ? Décrivez l'index B-tree vs hash.

Ce qu'une bonne réponse couvre

Un index de base de données accélère les requêtes en permettant un accès rapide aux lignes via des structures de données.
L'index B-tree organise les données dans un arbre équilibré, adapté aux requêtes de plage (range) et d'égalité.
L'index hash utilise une table de hachage pour des accès directs par égalité, inefficace pour les plages.
Le B-tree est l'index par défaut dans la plupart des SGBDR (ordre de grandeur O(log n) pour les opérations).
Le hash index est utile pour les recherches par clé unique avec une complexité O(1) en moyenne, mais pas de tri.

Voir un exemple de réponse

Un index de base de données relationnelle est une structure de données qui améliore la vitesse des opérations de sélection (SELECT) sur une table, au prix d'espace de stockage supplémentaire et d'une légère dégradation des opérations d'écriture (INSERT, UPDATE, DELETE). Les deux types d'index les plus courants sont le B-tree (arbre B) et le hash (table de hachage). L'index B-tree est un arbre équilibré où chaque nœud contient plusieurs clés et pointeurs vers des enfants. Il maintient les clés triées, ce qui permet de supporter efficacement les requêtes d'égalité (WHERE id = 5) et de plage (WHERE id BETWEEN 10 AND 20) ainsi que les tris (ORDER BY). La complexité temporelle d'une recherche dans un B-tree est O(log n). L'index hash, quant à lui, utilise une fonction de hachage sur la clé pour obtenir une adresse directe dans une table de hachage. Il est très rapide pour les recherches par égalité (O(1) en moyenne), mais ne supporte pas les recherches de plage ou le tri. Il est souvent utilisé pour des index sur des colonnes avec beaucoup de valeurs uniques, comme les clés primaires dans certains moteurs (Memory de MySQL). Le choix entre B-tree et hash dépend donc du type de requêtes : pour des applications avec beaucoup de recherches par plage ou de tris, le B-tree est préférable ; pour des recherches ponctuelles intensives, le hash peut être plus performant. D'autres index existent comme les index bitmap ou GiST pour des besoins spécialisés.

Concevez un système de chat en temps réel similaire à WhatsApp. Discutez de l'architecture, du stockage des données et du passage à l'échelle.

Ce qu'une bonne réponse couvre

Architecture : clients mobiles/services, serveurs de présence, gestionnaires de messages, stockage persistant.
Utiliser WebSockets pour la communication en temps réel entre clients et serveurs.
Stockage des messages : base de données distribuée (Cassandra) pour l'historique, cache Redis pour les messages récents.
File d'attente de messages (Kafka) pour découpler l'envoi et la réception, assurer l'ordre et la fiabilité.
Scalabilité : partitionnement des utilisateurs (sharding) par ID, équilibrage de charge, réplication géographique.

Voir un exemple de réponse

Un système de chat en temps réel comme WhatsApp repose sur une architecture client-serveur avec communication persistante via WebSockets. Le système comprend plusieurs composants : un serveur de connexion/gestion de sessions (pour gérer les WebSockets), un serveur de présence (indique si un utilisateur est en ligne), un gestionnaire de messages (qui reçoit un message, le stocke et le transmet au destinataire), et un service de notification push (pour les mobiles en arrière-plan). Les messages sont d'abord envoyés à un serveur via WebSocket, puis stockés dans une base de données distribuée comme Cassandra (pour l'historique) et temporairement dans un cache Redis (pour les messages récents). Un système de files d'attente comme Kafka assure l'ordre FIFO par conversation et permet de découpler les composants pour la résilience. Pour le passage à l'échelle, on partitionne les utilisateurs par ID (hash) sur plusieurs instances de serveur, avec un répartiteur de charge (load balancer) en entrée. La réplication géographique des serveurs réduit la latence. Le stockage des messages doit être dimensionné pour des milliards de messages par jour : on utilise un partitionnement temporel et par utilisateur. La livraison des messages nécessite un mécanisme de confirmation (ack) et de retransmission en cas d'échec. Pour les discussions de groupe, on peut utiliser un fan-out avec copie des messages ou une approche centralisée.

Décrivez un projet ambitieux que vous avez dirigé. Quel était votre rôle et le résultat ?

Ce qu'une bonne réponse couvre

Situation : Projet de migration d'une application monolithique vers une architecture microservices au sein d'une équipe de 8 personnes.
Tâche : Diriger la conception, le découpage en services, la mise en place de l'infrastructure et la coordination des développeurs.
Action : Définition des limites des services basée sur les domaines métier (DDD), choix de technologies (Docker, Kubernetes), organisation en sprints, revues de code régulières.
Résultat : Migration réussie en 6 mois, amélioration de la scalabilité (capacité à gérer 3x plus de requêtes), déploiements plus rapides (de 2 heures à 10 minutes).

Voir un exemple de réponse

Dans mon précédent poste, j'ai dirigé un projet ambitieux de migration d'une application monolithique vieillissante vers une architecture microservices. L'équipe était composée de 8 développeurs. Mon rôle était de définir la stratégie de découpage, de choisir les technologies et de coordonner les sprints. J'ai commencé par une analyse du domaine métier en utilisant le Domain-Driven Design pour identifier les limites des services. Nous avons ensuite implémenté une infrastructure avec Docker et Kubernetes pour l'orchestration. J'ai mis en place des pipelines CI/CD avec Jenkins pour automatiser les tests et les déploiements. J'ai organisé des revues de code régulières et des sessions de pair programming pour assurer la qualité. Un défi majeur a été de gérer la dette technique héritée et de former l'équipe aux nouvelles technologies. J'ai organisé des ateliers techniques et des démonstrations. Le résultat a été une migration réussie en 6 mois : l'application a pu gérer trois fois plus de requêtes simultanées, les déploiements sont passés de 2 heures à 10 minutes, et l'équipe a gagné en autonomie. Ce projet a considérablement amélioré la performance et la maintenabilité du système.

Conseils pour se préparer

Révisez minutieusement les sujets fondamentaux de l'informatique : structures de données, algorithmes, OS et réseaux.

Entraînez-vous à coder sur un tableau blanc ou dans un éditeur de texte simple sans coloration syntaxique.

Pour la conception système, étudiez les systèmes à grande échelle comme les bases de données distribuées, les équilibreurs de charge et le cache.

Préparez des exemples spécifiques de dépassement d'adversité ou de travail sous des délais serrés pour démontrer la résilience.

Recherchez la culture d'entreprise et les valeurs de Huawei, en particulier les concepts comme 'l'esprit du loup' et le dévouement à la réussite client.

Questions fréquentes

Combien de rounds y a-t-il dans un entretien Huawei ?

Quelle est la difficulté des entretiens Huawei ?

Combien de temps dure l'ensemble du processus ?

Du premier contact à l'offre, cela peut prendre 2 à 6 semaines selon le poste et le nombre de rounds. Huawei avance souvent rapidement pour les candidats solides.