Questions d'entretien Développeur frontend

Mon flux de travail commence par la compréhension des exigences et des maquettes avant d'écrire la moindre ligne de code. Je découpe l'interface en composants tôt, en distinguant ceux qui gèrent l'état de ceux qui sont purement présentationnels. J'utilise TypeScript du début à la fin, donc les définitions de types précèdent l'implémentation. Pour le contrôle de version, je travaille dans des branches courtes, je garde des commits petits et ciblés, et j'ouvre des pull requests avant de merger. Je teste les composants en isolation avec Storybook quand l'équipe l'utilise, j'écris des tests unitaires avec Jest et React Testing Library au fil du développement, et je fais une vérification manuelle cross-browser avant de marquer quelque chose comme prêt.

Je commence par reproduire le problème de façon fiable, en notant exactement quels navigateurs et versions sont concernés. Une fois que je peux le reproduire de manière constante, j'utilise les DevTools pour inspecter le DOM, vérifier les différences CSS et consulter la console. J'isole le composant défaillant et le réduis à une reproduction minimale pour écarter les interactions avec d'autres parties du code. Pour les bugs CSS je vérifie les propriétés avec des problèmes de compatibilité connus via MDN ou Can I Use. Pour les problèmes JavaScript je cherche des différences de comportement d'API ou d'événements propres à chaque navigateur. Une fois la cause identifiée, je corrige sans régresser les autres navigateurs, puis j'ajoute un test cross-browser pour éviter les récidives.

Quand je relis le code de quelqu'un, je me concentre sur la correction, la maintenabilité et les performances plutôt que sur les préférences de style, qui doivent être gérées par un linter. J'essaie de poser des questions plutôt que d'imposer des changements : "As-tu envisagé l'approche X pour la raison Y ?" est mieux reçu qu'un rejet direct. Je reconnais toujours ce qui fonctionne bien avant de soulever des problèmes. Quand je reçois des retours, je les traite comme des informations. Si je ne suis pas d'accord avec un commentaire, j'explique mon raisonnement une fois clairement, puis je m'en remets au relecteur. L'objectif est de livrer du meilleur code, pas d'avoir raison.

Nous avions un tableau de bord React qui prenait plus de quatre secondes à devenir interactif sur des appareils de milieu de gamme. J'ai commencé par le profiler dans Chrome DevTools, ce qui a révélé un bundle volumineux et un arbre de composants qui se re-rendait bien plus que nécessaire. L'analyse du bundle a montré que nous importions une librairie de graphiques entière pour deux types de graphiques. Je l'ai remplacée par une alternative plus légère et utilisé les imports dynamiques pour séparer les graphiques dans un chunk distinct. Pour les re-renders, j'ai utilisé React.memo et déplacé les calculs coûteux dans useMemo avec les tableaux de dépendances corrects. Après ces modifications, le chargement initial est passé à moins de 1,5 seconde et le Largest Contentful Paint s'est amélioré de 60 %.

J'essaie d'intervenir avant que les maquettes soient finalisées plutôt que de recevoir une spec complète à implémenter. Cela me permet de signaler les contraintes techniques tôt : par exemple, si une animation est belle dans Figma mais nécessite une propriété CSS qui force un repaint complet à chaque frame, il est plus simple d'ajuster le design. Pendant l'implémentation, je fais des points réguliers avec une version brute plutôt d'attendre d'avoir quelque chose de parfait, car les designers repèrent souvent dans le navigateur des choses qu'ils n'avaient pas vues dans la maquette statique. Je demande aussi les états d'interaction en amont : hover, focus, chargement, erreur et états vides sont faciles à omettre dans les designs.

Je sépare le signal du bruit en me concentrant d'abord sur les standards et spécifications du navigateur. Les nouvelles API comme View Transitions ou Popover représentent de vraies capacités de la plateforme, pas des opinions de framework, donc je les priorise. Pour les frameworks, je suis les notes de version et les RFCs des outils que j'utilise déjà. Je maintiens une courte liste de sources fiables : les mises à jour MDN, le dépôt de propositions TC39, et quelques ingénieurs dont j'estime la réflexion. Quand un nouvel outil gagne en adoption, je passe quelques heures à construire quelque chose de petit avec lui pour me forger ma propre opinion. J'ai décliné l'adoption de plusieurs outils surmédiatisés qui ne correspondaient pas aux besoins de notre équipe.

Lors d'un lancement produit, nous avions trois jours pour construire une fonctionnalité qui aurait normalement pris une semaine. J'ai eu une conversation directe avec l'équipe sur les compromis : nous avons convenu de ne pas écrire de tests unitaires pour les nouveaux composants, d'utiliser une approche d'état plus simple qui nécessiterait une refactorisation, et de reporter les améliorations d'accessibilité au-delà de la navigation clavier. J'ai créé immédiatement un ticket de dette technique avec les éléments reportés. Nous avons livré à temps. Deux semaines après le lancement, j'ai repris le ticket et terminé la refactorisation avec une couverture de tests complète et des améliorations ARIA. La clé est de rendre le compromis explicite et tracé, pas invisible.

Je commence par mesurer l'état actuel avec Lighthouse et le Chrome User Experience Report pour comprendre quelles métriques échouent dans les sessions utilisateurs réelles, pas seulement en conditions de laboratoire. Pour le Largest Contentful Paint, je vérifie si l'image ou le titre principal est chargé avec la bonne priorité : il doit avoir fetchpriority="high" et ne pas être en lazy-loading. Pour les polices, j'utilise font-display: swap et je précharge le sous-ensemble critique. Pour le Cumulative Layout Shift, j'audite tout élément dont la taille est déterminée par du contenu chargé après le rendu initial. Pour l'Interaction to Next Paint, je profile l'exécution JavaScript sur des appareils lents et cherche des tâches longues à découper avec scheduler.yield ou à déplacer vers un web worker.

L'accessibilité est quelque chose que j'intègre dès le début plutôt que d'auditer en fin de projet. J'utilise le HTML sémantique comme fondation : un document bien structuré avec une hiérarchie de titres correcte, des régions de repère et des éléments de formulaire natifs couvre une grande partie des exigences d'accessibilité sans ARIA. Quand j'utilise ARIA, je suis la première règle : ne pas utiliser ARIA si un élément natif peut faire le travail. Pour les composants interactifs, je vérifie que toutes les fonctionnalités sont accessibles au clavier et que le focus est géré correctement. Je teste avec un lecteur d'écran au moins une fois par fonctionnalité. Je lance aussi des vérifications automatisées avec axe-core dans la suite de tests. Les outils automatisés ne détectent qu'environ 30 à 40 % des problèmes, donc les tests manuels restent indispensables.

Je pense aux composants en termes de responsabilité. Les composants présentationnels reçoivent des props et rendent l'interface, sans connaissance de la provenance des données. Les composants conteneurs gèrent la récupération de données et l'état, et transmettent les données. Les primitives UI partagées vivent dans un dossier de design system et restent génériques. Les composants spécifiques à une fonctionnalité vivent aux côtés de cette fonctionnalité, car la co-localisation facilite la compréhension du périmètre et la suppression du code. Pour l'état, je le garde aussi proche que possible de son utilisation : état local d'abord, puis contexte, puis un store global uniquement quand c'est vraiment nécessaire. Je réfléchis aussi à la surface d'API de chaque composant, en gardant les props minimes.