Développeur·euse Front-end

Capacité à structurer une décision sous incertitude : identification des contraintes (équipe, calendrier, dette existante, parc utilisateur·rice), arbitrages explicites, consultation des parties concernées (designer, back-end, PM), validation a posteriori avec des données (Core Web Vitals, taux d'erreur, feedback équipe). Bonus : la·le candidat·e mentionne avoir changé d'avis en cours de route ou avoir documenté la décision. Les candidat·e·s qui décrivent une décision « évidente » avec recul révèlent qu'ils·elles n'ont jamais vraiment arbitré.

Méthode de debug structurée : reproduction, DevTools (Performance tab, Memory tab, rendering, network), instrumentation, hypothèses validées par expérimentation. Honnêteté sur la durée (un vrai bug Front-end dure rarement moins de 30 min). Bonus : la·le candidat·e cite la cause profonde et le correctif systémique (pas seulement le hotfix). Les réponses « j'ai changé une propriété CSS au hasard et ça a marché » sans diagnostic révèlent une faiblesse d'investigation.

Humilité technique et capacité à apprendre. Bonus : la·le candidat·e identifie ce qu'il·elle aurait fait différemment dès le départ (découpage, gestion d'état local vs global, séparation logique / présentation). Les candidat·e·s qui n'ont « jamais vraiment dû refactorer leur code » mentent ou n'ont pas porté de code en production sur la durée.

Posture de partenariat : challenger constructivement, proposer un échange rapide pour comprendre l'intention (variation justifiée par un cas d'usage différent ou simple écart non intentionnel ?), proposer 2 options chiffrées (étendre l'existant via une variante de composant vs créer un nouveau composant). Bonus : la·le candidat·e mentionne le coût caché des composants quasi-doublons (maintenance, accessibilité, cohérence visuelle). Les candidat·e·s qui implémentent en bloc sans poser de question, ou qui refusent en bloc sans proposer d'alternative, révèlent une faiblesse de collaboration.

Clarification du besoin avant de négocier la timeline (la démo a-t-elle besoin de toute la feature ou seulement du happy path ?). Proposition d'options : MVP visuel non interactif en 2 jours pour la démo + V2 fonctionnelle en 2 semaines ; coupes explicites de scope (un seul navigateur, pas d'accessibilité clavier, pas de gestion d'erreur). Bonus : la·le candidat·e signale les risques de chaque coupe. Les réponses « je peux le faire en 5 jours si je travaille les week-ends » sont un drapeau rouge.

Diagnostic d'abord : ne pas tout vouloir réparer en même temps. Priorisation par risque / impact (typiquement : extraction d'un noyau de tokens et de 5-10 composants partagés d'abord, puis introduction progressive de TypeScript sur les nouvelles features, puis tests sur les zones critiques). Validation avec l'équipe et la·le lead avant d'engager. Bonus : la·le candidat·e propose de mesurer la valeur du chantier (vélocité, taux de régression, accessibilité) plutôt que de refactorer pour la beauté du geste. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.

Mesurer avant d'optimiser : Lighthouse, WebPageTest, Chrome DevTools Performance tab, RUM si disponible. Identification des bottlenecks par métrique (LCP : image héros non optimisée, font-display:swap manquant, CSS bloquant ; CLS : images sans dimensions, fonts qui reflowent, bannières insérées tardivement ; INP : long tasks JS, listeners coûteux, hydration trop lourde). Hiérarchisation par effort × impact. Bonus : la·le candidat·e mentionne qu'une page à 6 s en prod indique souvent un problème systémique (bundle énorme, trop d'hydration) plus qu'une optimisation locale. Les réponses « j'ajoute un lazy-load » sans diagnostic révèlent un réflexe d'optimisation prématurée.

Connaissance des patterns WAI-ARIA (rôle dialog, aria-modal, aria-labelledby, gestion du focus à l'ouverture, focus trap pendant l'ouverture, restauration du focus à la fermeture, gestion de la touche Escape). Distinction entre dialog modal et dialog non-modal. Bonus : la·le candidat·e mentionne avoir testé avec VoiceOver ou NVDA, et signale les pièges classiques (modal qui ferme au focus sur un input externe, validation inline non annoncée aux lecteurs d'écran). Les candidat·e·s qui répondent « j'utilise une librairie comme Radix » sans pouvoir expliquer ce qu'elle fait sous le capot révèlent un manque de fondamentaux.

Clarifications avant code : volume attendu d'options (10 vs 10 000 changent l'architecture), source des données (local vs API), comportement attendu sur mobile (sheet vs popover), accessibilité requise (combobox WAI-ARIA pattern). Architecture cohérente : composition (un Select de base + variantes vs un Select monolithique configurable), gestion d'état (controlled vs uncontrolled), API publique stable. Bonus : reconnaissance des zones d'incertitude (« je ferais un prototype rapide pour valider l'API publique avec 2-3 cas d'usage de l'équipe avant de m'engager »). Les candidat·e·s qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design de composant.

useMemo mémoïse la valeur de retour d'une fonction coûteuse ; useCallback mémoïse une référence de fonction stable ; React.memo évite le re-render d'un composant si ses props n'ont pas changé (comparaison superficielle par défaut). Pièges classiques : mémoïser un calcul trivial coûte plus en mémoire et en complexité qu'il n'économise en CPU ; React.memo est inutile si le composant reçoit des props non stables (objets ou fonctions recréés à chaque render) ; la sur-mémoïsation rend le code illisible. Bonus : la·le candidat·e cite avoir mesuré avant de mémoïser (Profiler React DevTools). Les candidat·e·s qui mémoïsent tout par réflexe révèlent un manque de fondamentaux.

Compréhension de la séquence : HTML parsing, construction du DOM, CSS parsing et CSSOM, blocking resources (CSS et JS sync), construction du render tree, layout, paint, composite. LCP : optimiser le plus gros élément visible (image preload, fetchpriority=high, formats modernes, dimensions explicites, font-display:swap, CSS critique inline). CLS : dimensions explicites sur médias, réservation d'espace pour bannières et embeds, transitions CSS plutôt que reflows JS, font fallback métriquement proche. Bonus : la·le candidat·e mentionne les outils (Lighthouse, WebPageTest, Chrome DevTools Performance) et la distinction entre données synthétiques (lab) et données réelles (RUM, CrUX).

Approche progressive : (1) cartographier les composants critiques et les patterns récurrents, (2) extraire les hooks et la logique métier d'abord (impact massif, risque faible), (3) découper les gros composants par boundary métier plutôt que par contrainte technique, (4) introduire un state-manager si nécessaire (Context, Zustand pour PME, Redux si volume) seulement sur les zones où le props drilling est réellement douloureux, (5) typer progressivement en TypeScript sur les nouvelles features et les zones touchées. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.

Ouverture : capacité à dissocier le code de l'ego personnel. Bonus : la·le candidat·e cite une fois où il·elle a changé d'avis grâce à une review, ou cite une review qu'il·elle a fait sienne après réflexion. Les candidat·e·s qui décrivent avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour le travail en équipe.

Posture de partenariat : challenge constructif basé sur la faisabilité, la complexité, l'accessibilité, ou la cohérence avec le design system. Proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange (n'est pas en mode opposition systématique). Les candidat·e·s qui décrivent les designers comme « ne comprenant pas la technique » ou les PMs comme « ne comprenant pas le Front » révèlent une faiblesse de jeu d'équipe.

Curiosité Front-end authentique : capacité à citer 3-5 produits récents (pas seulement Apple, Linear, Notion par réflexe), avec une analyse précise de ce qui fonctionne (qualité des interactions, performance perçue, cohérence visuelle, accessibilité au clavier, gestion des états). Bonus : la·le candidat·e cite un produit que personne ne cite et explique pourquoi. Les candidat·e·s qui répondent par des généralités (« j'aime quand c'est rapide ») ou par des produits évidents sans analyse révèlent un manque de regard critique entraîné, ce qui est rédhibitoire pour un poste qui exige du goût technique au quotidien.