Questions d'entretien Développeur full-stack

Je pars du périmètre du problème. Si le problème est bien défini et qu'une bibliothèque mature le résout de façon fiable, j'utilise la bibliothèque : réinventer des problèmes résolus gaspille du temps et introduit du code non testé. Les facteurs que je pèse sont : dans quelle mesure la bibliothèque est-elle maintenue (commits récents, issues actives, grande communauté ?), correspond-elle à nos exigences de montée en charge, et quel est le coût en bundle côté front-end ? Je suis particulièrement prudent vis-à-vis des dépendances importantes pour de petits utilitaires. Pour un besoin de formatage de date, je n'ajouterais pas une bibliothèque utilitaire complète si l'API Intl native gère le cas d'usage. Pour la gestion d'état ou le traitement HTTP, une bibliothèque éprouvée l'emporte généralement car ces surfaces sont pleines de cas limites. Je considère aussi la maintenabilité à long terme.

Je commence toujours par mesurer avant d'optimiser. Une optimisation prématurée basée sur des suppositions conduit à des changements qui rendent le code plus difficile à lire sans améliorer l'expérience utilisateur. Ma boîte à outils commence par Lighthouse et les DevTools du navigateur côté front-end : je regarde les Core Web Vitals (LCP, INP et CLS). Pour le back-end, je profile les requêtes lentes, examine les problèmes N+1 dans les schémas d'accès à la base de données et vérifie si des calculs coûteux sont répétés inutilement. Côté front-end : découpage du code et chargement différé, optimisation des images et réduction des re-renders inutiles. Côté back-end : indexation des requêtes, mise en cache à la couche appropriée et déplacement des traitements lourds vers des jobs asynchrones. Je documente les performances de référence avant et après tout travail d'optimisation.

Je traite l'authentification et l'autorisation comme des préoccupations différentes. L'authentification répond à "qui êtes-vous ?" et l'autorisation à "qu'êtes-vous autorisé à faire ?" Pour l'authentification je me tourne par défaut vers un fournisseur bien maintenu (comme Auth0, Supabase Auth ou Clerk) plutôt que de tout développer moi-même, car la gestion des sessions, la rotation des tokens et les flux OAuth ont trop de cas limites de sécurité. J'utilise des JWT pour l'authentification sans état avec des délais d'expiration courts et les stocke dans des cookies HTTP-only pour empêcher l'accès XSS. Pour l'autorisation j'implémente un contrôle d'accès basé sur les rôles au niveau de la couche API, pas seulement du front-end. Le contrôle côté front-end est une commodité UX, pas un contrôle de sécurité.

J'ai construit un système de notifications en temps réel pour un tableau de bord interne. Les exigences étaient : envoyer des notifications aux utilisateurs quand un événement se produisait dans un système connecté, afficher le nombre de notifications non lues dans la barre de navigation et les marquer comme lues au clic. Pour le back-end, j'ai choisi les WebSockets plutôt que le polling car nous avions besoin d'une livraison en temps réel et le nombre d'utilisateurs connectés était suffisamment faible pour que la charge de connexion ne soit pas un problème. J'ai construit un event emitter Node.js qui écoutait les événements de changement de base de données via un déclencheur Postgres et les transmettait via une connexion socket au client. Côté front-end, j'ai utilisé React Context avec un pattern reducer pour les mises à jour optimistes de marquage comme lu. J'ai ajouté un endpoint REST de secours pour récupérer la liste initiale au chargement de la page. La fonctionnalité a été lancée sans régression et a réduit les tickets de support d'environ 70% le premier mois.

Nous avions un problème en production où un sous-ensemble d'utilisateurs recevait des données périmées sur une page à forte lecture, mais seulement après avoir été actifs plus de 30 minutes dans la même session. J'ai d'abord reproduit le problème localement avec une session longue durée. Ensuite j'ai isolé le chemin de code affecté : les données étaient récupérées au montage du composant et stockées en état local sans logique de rafraîchissement. J'ai trouvé la cause racine : un cache au niveau session avait été appliqué à un type de données pouvant changer au cours d'une session. La correction consistait à ajouter un déclencheur d'invalidation du cache sur l'événement de mutation concerné. J'ai aussi ajouté une alerte de monitoring pour le taux de succès du cache sur cet endpoint. Après la correction, le problème était résolu pour 100% des utilisateurs affectés en un seul déploiement.

En début de carrière j'ai construit une fonctionnalité en utilisant le rendu côté client pour une page qui devait se classer dans les résultats de recherche. J'ai choisi le CSR car l'équipe utilisait déjà une SPA React et je voulais rester cohérent avec l'architecture existante. Six mois plus tard nous avons découvert que la page n'était pas indexée correctement car le crawler n'exécutait pas le JavaScript de façon fiable. Nous avons dû reconstruire en utilisant le rendu côté serveur. La reconstruction a pris trois semaines et a retardé d'autres fonctionnalités. La leçon que j'en ai tirée est d'identifier toujours les exigences de rendu avant de choisir une architecture : CSR, SSR, SSG et ISR ont chacun des cas d'usage spécifiques et la décision doit être délibérée. J'ajoute maintenant une question sur la stratégie de rendu à ma checklist pour toute nouvelle page ou route.

Je suis une conception orientée ressources où les endpoints représentent des entités, pas des actions. J'utilise correctement les verbes HTTP : GET pour les lectures, POST pour les créations, PUT/PATCH pour les mises à jour, DELETE pour les suppressions. Pour les codes de statut je suis la norme : 200 pour le succès, 201 pour la création, 400 pour les erreurs client, 404 pour non trouvé, 401 pour non authentifié, 403 pour non autorisé, 500 pour les erreurs serveur. Je versionne toujours les APIs dès le départ. Pour la pagination j'utilise la pagination par curseur pour les grands ensembles de données plutôt que la pagination par offset, car la pagination par offset devient incohérente quand des enregistrements sont ajoutés ou supprimés. Je documente aussi le contrat d'API avant de le construire : cela force une réflexion plus claire.

Je suis une pyramide de tests : beaucoup de tests unitaires, moins de tests d'intégration et un petit nombre de tests end-to-end. Les tests unitaires couvrent les fonctions pures et le rendu isolé des composants. Les tests d'intégration couvrent les routes API avec une base de données de test et la logique de la couche service. Les tests end-to-end couvrent uniquement les parcours utilisateurs critiques : connexion, action principale et flux de conversion, en utilisant des outils comme Playwright. Pour la couverture je ne cherche pas un objectif en pourcentage ; je vise à couvrir chaque résultat visible par l'utilisateur et chaque état d'erreur. J'écris aussi des tests avant de corriger des bugs : un test échouant qui reproduit le bug est la preuve que la correction fonctionne et une protection contre les régressions.

Je conçois les schémas en pensant à l'évolution future : les colonnes nullable sont moins coûteuses à ajouter plus tard, les contraintes de clé étrangère sont mieux appliquées dans la base de données que dans le code applicatif, et l'ajout d'un index à une table existante en production nécessite de la précaution pour éviter les verrous. Pour les migrations j'utilise un outil dédié (comme Flyway, Alembic ou le système de migration de l'ORM) plutôt que d'exécuter du SQL brut manuellement, et chaque migration est versionnée et revue avant la production. Je distingue aussi les migrations de schéma des migrations de données : les changements de schéma doivent être rétrocompatibles autant que possible pour qu'un rollback soit sûr. J'utilise un pattern ajouter-avant-supprimer pour les changements de colonnes. Je teste toujours les migrations sur un snapshot des données de production en amont.