Développeur frontend Questions d'entretien & Réponses

Exemple de réponse

L'équipe design a livré des maquettes pour un tableau de données avec défilement infini, tri en temps réel, édition en ligne et transitions animées sur les lignes, le tout sur un jeu de données de plus de 100 000 entrées. J'ai créé un prototype et constaté que le rendu du DOM combiné aux animations pour autant de lignes faisait chuter les performances en dessous de 10 images par seconde sur des appareils d'entrée de gamme. Au lieu de dire simplement que c'était impossible, j'ai développé deux alternatives: l'une utilisant le rendu virtualisé (react-window), qui conservait un défilement fluide tout en simplifiant les animations, et une autre avec pagination qui préservait tous les effets visuels. J'ai présenté les deux au designer avec les métriques de performance. Nous avons choisi l'approche virtualisée avec des transitions de lignes simplifiées. Le designer a apprécié voir le compromis de façon concrète plutôt qu'entendre un refus abstrait. L'implémentation finale gérait 100 000 lignes à 60 images par seconde avec toutes les fonctionnalités principales intactes.

Exemple de réponse

La page d'accueil de notre site e-commerce affichait un Largest Contentful Paint de 4,2 secondes, et les données de conversion montraient une baisse de 7 % des achats pour chaque seconde de chargement supplémentaire. J'ai identifié trois goulets d'étranglement: une image hero de 2 Mo, 800 Ko de JavaScript synchrone et un fichier CSS bloquant le rendu qui importait des feuilles de style inutilisées. J'ai converti l'image hero en WebP avec un srcset adaptatif, découpé le bundle JavaScript en utilisant des imports dynamiques (réduisant le chargement initial de 65 %) et intégré le CSS critique en ligne tout en chargeant le reste de façon asynchrone. Le LCP est passé à 1,1 seconde. Au cours du mois suivant, le taux de conversion a augmenté de 9 % et le taux de rebond a diminué de 15 %. L'effort d'ingénierie total était de 4 jours, l'un des projets avec le meilleur retour sur investissement sur lequel j'ai travaillé.

Exemple de réponse

J'ai développé une bibliothèque de composants React partagée pour une entreprise comptant 4 équipes produit qui implémentaient chacune leurs propres boutons, modales et formulaires. J'ai commencé par auditer les composants existants dans tous les produits: nous avions 12 variantes différentes de boutons. Je les ai consolidés en 4 (primaire, secondaire, fantôme, danger) avec des dimensions et espacements cohérents. J'ai utilisé TypeScript pour le typage strict des props, Storybook pour la documentation et les tests visuels, et Chromatic pour les tests de régression visuelle. J'ai versionné la bibliothèque avec le versionnage sémantique et l'ai publiée dans un registre npm privé. L'adoption a été la partie la plus difficile: j'ai organisé des permanences hebdomadaires, créé un guide de migration pour chaque produit et soumis des pull requests pour montrer aux équipes comment remplacer leurs composants personnalisés. Au bout de 4 mois, toutes les équipes utilisaient la bibliothèque commune, la cohérence visuelle s'était améliorée et le temps de développement des nouvelles fonctionnalités avait diminué.

Exemple de réponse

Nous avons reçu des signalements de bugs indiquant que la validation de formulaire ne fonctionnait pas sur Safari iOS. Le problème: nous utilisions la méthode reportValidity() de l'API Constraint Validation, que Safari prenait en charge mais gérait différemment. Elle affichait l'infobulle d'erreur sans empêcher la soumission du formulaire sur iOS. J'ai retracé le bug jusqu'à un problème de rendu WebKit où l'infobulle apparaissait derrière le clavier virtuel. Ma solution comportait trois volets: remplacer les infobulles de validation natives par des messages d'erreur personnalisés en ligne (une meilleure expérience utilisateur), ajouter une couche de validation JavaScript en solution de repli et mettre en place des tests cross-browser avec BrowserStack dans notre pipeline CI pour détecter les problèmes spécifiques à Safari. J'ai également créé une liste de vérification pour les tests de compatibilité couvrant Safari iOS, Chrome Android, Firefox et Edge. La correction a résolu plus de 40 rapports de bugs ouverts liés à Safari d'un coup.

Exemple de réponse

Le DOM virtuel est une représentation JavaScript légère du DOM réel. Lorsque l'état change, React crée un nouvel arbre DOM virtuel et le compare au précédent: c'est la réconciliation. React utilise un algorithme heuristique en O(n): il compare les arbres niveau par niveau, suppose que des éléments de types différents produisent des arbres différents (et les détruit entièrement), et utilise les props 'key' pour identifier quels enfants d'une liste ont changé, bougé ou été supprimés. Quand le diff détecte une différence, React regroupe le nombre minimal d'opérations DOM réelles nécessaires. C'est plus rapide que de manipuler le DOM directement, car les opérations DOM sont coûteuses (elles déclenchent le recalcul de la mise en page, le rendu et la composition), tandis que la comparaison d'objets JavaScript est peu coûteuse. Les implications pratiques: utilisez toujours des clés stables et uniques pour les éléments de liste (pas des indices de tableau), évitez de créer de nouvelles références d'objets ou de fonctions dans le rendu (elles annulent la mémoïsation) et utilisez React.memo, useMemo et useCallback lorsque le profilage révèle des re-renders inutiles.

Exemple de réponse

Flexbox est unidimensionnel: il gère la mise en page soit sur une ligne, soit sur une colonne. Grid est bidimensionnel: il gère lignes et colonnes simultanément. J'utilise Flexbox pour la mise en page au niveau des composants: aligner des éléments dans une barre de navigation, espacer des boutons dans une barre d'outils, centrer du contenu verticalement et horizontalement. Flexbox excelle quand la taille du contenu doit déterminer la mise en page. J'utilise Grid pour la mise en page au niveau de la page: définir la structure générale, créer des grilles de cartes complexes, construire des tableaux de bord avec plusieurs zones. Grid excelle quand la mise en page doit définir le positionnement du contenu. En pratique, je combine les deux: Grid pour la macro-mise en page (en-tête, barre latérale, contenu principal, pied de page) et Flexbox pour la micro-mise en page à l'intérieur de chaque cellule de grille. L'erreur courante est de recourir à Grid pour une simple rangée d'éléments, ou d'utiliser des contournements Flexbox (marges négatives, pseudo-éléments) là où Grid serait plus propre.

Exemple de réponse

Je classe l'état par nature et je choisis les outils en conséquence. L'état UI local (champs de formulaire, états de bascule, visibilité des modales): useState ou useReducer. Je le conserve dans le composant propriétaire et ne le remonte que lorsque c'est vraiment nécessaire. L'état serveur (données provenant des API): React Query ou SWR. Ces outils gèrent la mise en cache, le rechargement, les mises à jour optimistes et les états de chargement/erreur bien mieux que les schémas Redux manuels. Je ne place jamais les données serveur dans un état global. L'état client global (thème, authentification, préférences utilisateur): React Context pour les mises à jour peu fréquentes (thème, langue), ou Zustand pour l'état qui change souvent et nécessite un abonnement sélectif pour éviter les re-renders. L'état URL (filtres, pagination, paramètres de recherche): useSearchParams de React Router. L'état vit dans l'URL, ce qui permet la mise en favoris et le partage. L'anti-pattern à éviter: tout mettre dans un seul store global. Cela crée du couplage, complique les tests et fait re-rendre les composants lorsque des données sans rapport changent. Chaque catégorie d'état a le bon outil; l'art consiste à choisir correctement.

Exemple de réponse

Une closure est une fonction qui conserve l'accès aux variables de sa portée externe même après que la fonction externe a terminé son exécution. La fonction interne capture les variables auxquelles elle fait référence. Un exemple pratique: une fonction debounce. Quand vous écrivez debounce(fn, delay), la fonction retournée a accès à la variable timer définie dans la portée de debounce. Chaque fois que la fonction retournée est appelée, elle annule le timer précédent et en crée un nouveau. La variable timer persiste entre les appels grâce à la closure: elle n'est pas collectée par le ramasse-miettes tant que la fonction retournée existe. Un autre usage concret: le hook useState de React. Quand vous appelez setCount(count + 1), la valeur de count provient de la closure créée lors du rendu du composant. C'est pourquoi les closures obsolètes sont un bug React courant: si vous utilisez count dans un useEffect sans l'inclure dans le tableau de dépendances, l'effet capture la valeur initiale et ne voit jamais les mises à jour.

Exemple de réponse

D'abord, je vérifierais ma compréhension de l'exigence du design et de la limitation de l'API. Parfois, ce qui ressemble à une limitation est en réalité un endpoint différent ou un paramètre de requête que je n'ai pas trouvé. Je consulterais la documentation de l'API et discuterais avec le développeur backend. Si la limitation est réelle, j'évaluerais trois options. Première: le frontend peut-il déduire les données nécessaires à partir des réponses API existantes ? Parfois, un calcul ou une transformation côté client résout le problème sans modifier le backend. Deuxième: une modification de l'API backend est-elle faisable dans les délais ? S'il s'agit d'un ajout simple, j'en discuterais avec l'équipe backend pour coordonner. Troisième: peut-on adapter le design pour fonctionner avec les données disponibles sans compromettre l'expérience utilisateur ? Je présenterais la contrainte et les alternatives au designer et au chef de produit avec ma recommandation. Ce que je ne ferais pas: contourner la limitation avec plusieurs appels API, des jointures côté client ou des astuces de cache qui créent de la dette technique. Si la bonne solution est une modification backend, la défendre fait partie de mon travail.

Exemple de réponse

J'éviterais complètement le jargon technique. J'utiliserais une analogie: 'C'est comme demander d'ajouter une porte à une pièce. La porte elle-même est simple, mais cela implique de déplacer les câbles électriques et potentiellement d'ajuster un mur porteur.' Ensuite, je serais précis sur les délais: 'Le bouton en lui-même représente 30 minutes de travail. Mais les données dont il a besoin n'existent pas encore dans le système, et la mise en place du pipeline pour récupérer ces données prend environ 2 semaines.' Je présenterais des options: 'On peut livrer une version simplifiée utilisant les données existantes d'ici la semaine prochaine, ou la version complète que vous imaginez d'ici 3 semaines. Laquelle préférez-vous ?' L'essentiel est d'être honnête sur la complexité sans mettre le responsable mal à l'aise pour avoir posé la question. Il n'a pas besoin de comprendre pourquoi c'est complexe: il a besoin de comprendre les délais et les options.

Exemple de réponse

J'évaluerais sur cinq dimensions, pas selon la mode. Premièrement, la maturité de l'équipe: combien de temps de montée en compétence le nouveau framework nécessite-t-il ? Si l'équipe connaît React et envisage Svelte, cela représente 4 à 6 semaines de productivité réduite. Le calendrier est-il suffisamment flexible ? Deuxièmement, la maturité de l'écosystème: y a-t-il des bibliothèques pour le routage, la gestion d'état, les formulaires et les tests ? Peut-on trouver des réponses sur Stack Overflow ? Troisièmement, le recrutement: peut-on trouver des développeurs qui connaissent ce framework ? React dispose d'un vivier de talents bien plus large que Solid ou Qwik. Quatrièmement, la performance: le nouveau framework résout-il un problème de performance réel ? Si notre application React est suffisamment rapide, changer pour des benchmarks est une optimisation prématurée. Cinquièmement, la longévité: est-il soutenu par une organisation ou une communauté stable ? Quelle est la fréquence des commits, le nombre de contributeurs, l'adoption par les entreprises ? Je créerais un prototype d'une fonctionnalité représentative dans les deux frameworks, mesurerais la vitesse de développement et les performances, et présenterais la comparaison à l'équipe. La décision doit être fondée sur des données, pas sur les tendances.

Exemple de réponse

J'agirais de façon proactive plutôt que d'attendre que le problème éclate. Je dresserais une liste courte des problèmes d'accessibilité spécifiques que je vois dans les maquettes: états de focus manquants, contraste de couleurs insuffisant, icônes sans libellé textuel, champs de formulaire sans labels visibles. J'en parlerais au designer de façon constructive: 'J'ai remarqué quelques lacunes en matière d'accessibilité que nous devrions corriger avant le développement. Voici les points spécifiques.' Je proposerais des solutions, pas seulement des problèmes: 'Ce bouton a besoin d'un anneau de focus; voici à quoi il pourrait ressembler. Ce texte affiche un contraste de 3,2:1 alors qu'il en faut 4,5:1: l'assombrir de deux nuances suffirait.' Si le designer résiste en invoquant les délais, j'expliquerais le risque juridique et commercial: les procès pour accessibilité se multiplient, et corriger l'accessibilité après le développement coûte 3 à 5 fois plus cher que de l'intégrer dès le départ. Je mettrais également en place des vérifications d'accessibilité automatisées (axe-core dans la CI) pour éviter les régressions.