Guide d’entretien React : hooks, rendu et ce que demandent les grandes entreprises

Question classique : une liste de 10 000 lignes ralentit lors de la saisie dans un champ de recherche. Prévoyez des mécanismes de debounce, de virtualisation et des lignes mémorisées.

4. Gestion de l’état

• État local vs global vs serveur — nommer séparément l’état serveur (cache, révalidation, chargement/erreur) de l’état UI impressionne les équipes techniques.
• Context vs Redux/Zustand — utiliser Context pour les variables globales rares (thème, authentification) ; opter pour Redux/Zustand lorsque l’on a besoin de middleware, d’outils, d’actualisations complexes ou d’écritures fréquentes sans problèmes liés au contexte.
• React Query / SWR / TanStack Query — mise en cache, rechargement en arrière-plan, suppression des doublons afin d’éviter de réinventer le mécanisme de récupération via useEffect.
• Bases de Redux (si la stack l’utilise) : actions, réducteurs, store, middleware thunk/saga, réducteurs purs.

5. Modèles de conception

• HOCs — enrober un composant ; exemple classique : withAuth.
• Render props — partager de la logique via une propriété fonctionnelle ; en grande partie remplacés par les hooks, mais leur concept reste pertinent.
• Composants composés — composants frères partageant un état implicite via le contexte (Select / Select.Option).
• Conteneur/presentational — séparation des données et de l’interface utilisateur ; moins stricte avec les hooks, mais la séparation des préoccupations reste importante.
• Composition plutôt que héritage — la méthode privilégiée de React pour le réutilisement ; soyez prêt à en justifier l’utilisation.

6. Cycle de vie des classes (encore posé)

Ces équipes qui privilégient les hooks explorent encore des bases fondamentales ou des codes anciens.

• componentDidMount ≈ useEffect(() => {}, [])
• componentDidUpdate ≈ effet avec dépendances
• componentWillUnmount ≈ nettoyage des effets
• Bordures d’erreur — uniquement disponibles pour les classes (componentDidCatch / getDerivedStateFromError) ; les hooks n’ont pas d’équivalent, c’est pourquoi des outils comme react-error-boundary existent.

7. Connaissance de React 18+

• Rendu concurrent — exécution interrompable pour une interface utilisateur plus réactive.
• useTransition — marquer les mises à jour non urgentes afin de maintenir une saisie rapide.
• useDeferredValue — diffère l’affichage des éléments UI non critiques.
• Grouper automatiquement — regroupe les opérations à l’intérieur des promesses, des délais et des gestionnaires natifs (pas seulement ceux de React).
• Suspense pour les données — particulièrement utile avec des architectures de type Next.js/Remix.
• Composants serveur — ce qui s’exécute où, et pourquoi les bundles clients se réduisent.

8. Le JavaScript qui s’infiltrerait

• Closures — état obsolète des hooks.
• Boucle d’événements / tâches micro vs macro — raison pour laquelle le regroupement fonctionne de cette manière.
• Liaison de this — si les classes sont utilisées.
• Debounce vs throttle — presque toujours recommandé, souvent sous prétexte d’« optimiser cette boîte de recherche ».
• Comparaison superficielle vs profonde — React.memo / useMemo et raison pour laquelle les littéraux d’objet empêchent la mémorisation.
• Promesses / async-await — conflits de requêtes lorsqu’utilisateurs tapent rapidement.

9. Tests

• Testing Library — comportement plutôt que mécanismes internes (recherches par rôle ou texte).
• Jest — simulation d’API ; connaître les limites des captures d’écran.
• Tests unitaires contre tests d’intégration contre tests e2e, et place habituelle des tests de composants.

10. Codage en direct répétitif

• Recherche/autocomplétion avec délai de réponse
• useFetch personnalisé avec gestion des états chargement/erreur/données
• Défilement infini ou pagination
• Modale via portal (createPortal) et raison d’existence des portals (éviter le débordement/z-index tout en restant dans l’arbre React pour les événements/contexte)
• Compteur avec fonction undo/redo via useReducer
• Détection des erreurs dues à des closures obsolètes ou à des dépendances manquantes

Démonstration type

« Pourquoi ce useEffect est-il en boucle infinie ? »

useEffect(() => {
  setData({ ...data, updated: true });
}, [data]);

Réponse solide : l’effet liste data comme dépendance, puis écrit un nouvel objet à l’intérieur de data, ce qui fait que chaque exécution modifie la dépendance et déclenche immédiatement à nouveau l’effet. La solution consiste à retirer data de la liste des dépendances lorsque cela ne doit pas déclencher à nouveau l’effet, à déplacer la mise à jour en dehors de l’effet, ou à utiliser un mises à jour fonctionnel avec des dépendances plus restreintes.

C’est en expliquant pourquoi cela ne fonctionne pas — et non seulement en proposant une correction — que se distinguent les bonnes réponses aux entretiens React.

Conclusion

La profondeur de compréhension l’emporte sur la simple mémorisation des fonctionnalités d’une API. Les interviewers cherchent à connaître le comportement de rendu, les concepts de closures et les compromis en termes de performance — c’est-à-dire les bugs qui apparaissent en production. Préparez-vous en créant de petits composants conçus pour échouer délibérément (closures obsolètes, dépendances manquantes, rendus inutilement répétés) et en les corrigeant. C’est cet instinct de débogage que l’interview évalue réellement.

Lorsque vous vous entraînez, fixez-vous des délais identiques à ceux utilisés lors des entretiens : expliquez le Virtual DOM en soixante secondes, puis déboguez un exemple de closure obsolète, puis esquissez une fonction de recherche avec délai d’exécution. Cette séquence correspond à la manière dont les entretiens se déroulent réellement.

Comment les entretiens évoluent généralement

Les exercices de mise en température portent sur le Virtual DOM, les entrées contrôlées et les touches. Les étapes intermédiaires abordent les hooks : mises à jour par lots, effets doubles dans le mode strict, memo versus callback, ainsi que l’écriture d’un hook personnalisé en direct. Les étapes avancées traitent de sujets liés à la performance — listes de dix mille lignes, problèmes de contexte, données fournies par le Profiler — et des choix architecturaux entre Context, Redux/Zustand et TanStack Query pour gérer l’état serveur.

Gardez un répertoire personnel consacré aux cas « délibérément cassés » : un compteur de fermetures obsolètes, un effet lié à des dépendances manquantes, une liste mémorisée qui se rérend toujours en raison d’objets inline, ainsi qu’un modal de type portal. Expliquer oralement ces quatre corrections couvre une part surprenante du temps consacré au codage en direct et aux sessions sur tableau blanc.

Si le poste mentionne React 18+, soyez prêt à donner une phrase chacun sur le rendu concurrent, les transitions, les valeurs différées, le lotage automatique et les composants serveur. Une connaissance approfondie d’un seul cas concret vaut mieux qu’une connaissance vague de tous les RFC.