Comment décidez-vous d'utiliser un framework ou une bibliothèque plutôt que d'écrire quelque chose vous-même ?

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.

Comment abordez-vous l'optimisation des performances dans une application web ?

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.

Comment abordez-vous l'authentification et l'autorisation dans une application web ?

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é.

Parlez-moi d'une fonctionnalité full-stack que vous avez construite de bout en bout. Expliquez les décisions que vous avez prises.

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.

Décrivez une situation où vous avez dû déboguer un problème difficile en production. Comment avez-vous procédé ?

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.

Donnez un exemple d'une décision technique que vous avez prise et que vous changeriez rétrospectivement.

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.

Comment abordez-vous la conception d'une API REST ?

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.

Comment rédigez-vous et maintenez-vous des tests pour du code full-stack ?

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.

Comment gérez-vous la conception de base de données et les migrations dans un système en production ?

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.

Développeur full-stack

Les entretiens pour un poste de développeur full-stack couvrent les fondamentaux front-end et back-end, la pensée en termes d'architecture système et votre capacité à prendre des décisions techniques solides sur toute la couche produit. Les recruteurs veulent voir que vous pouvez construire des fonctionnalités de bout en bout, déboguer à travers la stack et travailler efficacement avec les équipes produit et design. Ce guide couvre les questions les plus fréquentes et les réponses qui montrent une vraie expérience full-stack.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Questions d'entretien courantes pour Développeur full-stack

Questions comportementales pour les postes Développeur full-stack

Questions techniques pour les candidats Développeur full-stack

Ce que les recruteurs recherchent pour un poste Développeur full-stack

Les développeurs full-stack qui se distinguent peuvent raisonner sur les compromis à travers toute la stack, pas seulement exécuter dans une couche. Recherchez des candidats qui expliquent pourquoi ils ont pris une décision technique, pas seulement ce qu'ils ont construit. Demandez-leur de décrire une vraie fonctionnalité qu'ils possèdent de bout en bout et sondez le raisonnement à chaque couche. Les meilleurs développeurs full-stack admettent aussi sans problème être plus forts d'un côté de la stack que de l'autre.

Questions à poser à votre interlocuteur

→À quoi ressemble la stack technologique actuelle et y a-t-il des migrations ou refactorisations prévues ?
→Comment le travail front-end et back-end est-il réparti au sein de l'équipe ?
→À quoi ressemble la couverture de tests et quelle est l'approche de l'équipe en matière de qualité ?
→Comment les déploiements en production sont-ils gérés et comment s'organise l'astreinte ?
→À quoi ressemble une fonctionnalité typique de bout en bout, du ticket à la production ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pour commencer. Sans engagement.

Métiers similaires