Préparer les questions d'entretien d'un développeur full-stack JavaScript commence par la stack du poste. Les offres publiées sur HelloWork et Free-Work associent le plus souvent NestJS ou Express côté serveur, React avec Next.js ou Vue avec Nuxt côté client, PostgreSQL derrière un ORM comme Prisma, et un monorepo qui partage les types. TypeScript y figure presque toujours comme indispensable.
Un langage unique ne donne pas un profil unique. Beaucoup de candidats viennent du front et ont appris Node.js en chemin : leurs routes fonctionnent, mais ils ne savent pas ce qui bloque la boucle d'événements ni ce qu'une transaction protège. D'autres viennent du back et traitent React comme un moteur de templates. Le rendu serveur de Next.js et de Nuxt brouille encore la frontière, puisqu'un composant peut lire la base directement.
Les versions bougent vite. Depuis juillet 2026, Next.js annonce ses mises à jour de sécurité à l'avance, environ une fois par mois, et une faille critique des React Server Components a imposé des correctifs en urgence en décembre 2025. Demandez comment la personne suit et met à jour ses dépendances. Le PDF contient l'entretien complet en 30 questions, un cas de 20 minutes et une grille de 1 à 4.
Les outils d'un développeur full-stack TypeScript, du serveur au navigateur
TypeScript
Le JavaScript typé, utilisé de la base de données jusqu'aux composants. Il repère les erreurs à la compilation puis disparaît : à l'exécution, rien ne vérifie qu'une donnée reçue a la bonne forme. C'est pourquoi les équipes ajoutent une validation au moment où la donnée entre dans l'application, avec Zod ou class-validator.
Node.js
Le moteur qui exécute JavaScript côté serveur. Il traite toutes les requêtes sur un seul fil d'exécution et compte sur les entrées-sorties non bloquantes : un calcul lourd ralentit donc tout le serveur. En novembre 2026, les versions LTS maintenues sont la 22, la 24 et la 26. Vérifiez que la production tourne sur l'une d'elles.
NestJS, Express ou Fastify
Les frameworks d'API. Express et Fastify sont minimalistes. NestJS impose une structure en modules avec injection de dépendances, des guards pour l'authentification, des pipes pour la validation et des interceptors, une organisation proche d'Angular ou de Spring. C'est le plus cité dans les offres full-stack TypeScript.
React et Next.js
React construit l'interface en composants. Next.js ajoute le routage, le rendu côté serveur et les React Server Components, qui s'exécutent sur le serveur et peuvent lire la base sans passer par une API. La version 16, sortie en octobre 2025, a apporté les Cache Components. Comprendre ce qui tourne côté serveur et ce qui part dans le navigateur fait la différence entre les profils.
Vue et Nuxt
L'alternative à React, avec la Composition API de Vue 3 et Pinia pour l'état partagé. Nuxt joue pour Vue le rôle de Next.js : routage, rendu serveur et récupération de données côté serveur. Vue 2 n'est plus maintenu depuis fin 2023, donc un CV qui s'arrête à Vue 2 et Nuxt 2 décrit surtout de la maintenance.
Prisma, Drizzle ou TypeORM et PostgreSQL
Les ORM qui génèrent le SQL et les types à partir du schéma. Prisma est le plus répandu : la version 7 a remplacé son moteur Rust par un client en TypeScript, et la version 8 est encore en release candidate en novembre 2026. Derrière, PostgreSQL domine. L'ORM ne dispense pas de comprendre les index, les transactions et le nombre de connexions ouvertes.
Monorepo (pnpm, Nx, Turborepo) et contrat d'API
Front, back et paquets partagés vivent dans un même dépôt. Nx ou Turborepo ne relancent que ce qui a changé et mettent en cache les builds. Le contrat entre front et API passe par tRPC, GraphQL ou un document OpenAPI dont on génère les types. Chaque option a ses limites quand des clients externes arrivent.
Tests : Vitest, Jest, Testing Library, Playwright
Vitest ou Jest pour les tests unitaires, Testing Library pour les composants, Playwright pour les parcours de bout en bout dans un vrai navigateur. Les tests d'API s'écrivent avec supertest ou le module de test de NestJS, idéalement contre une vraie base PostgreSQL lancée en conteneur.
Le poste n'a pas la même épaisseur partout. Dans une petite équipe, le développeur full-stack JavaScript écrit aussi le Dockerfile, la CI et parfois l'infrastructure (Terraform, Kubernetes, ou une plateforme d'hébergement comme Vercel). Dans une équipe plus grande, il travaille dans un monorepo où le front, l'API et les paquets partagés ont chacun leurs règles et leurs responsables. Les offres demandent tantôt React et Next.js, tantôt Vue et Nuxt, plus rarement Angular avec NestJS. Un bon profil passe d'un framework front à l'autre en quelques semaines. Les lacunes sur Node.js, SQL ou la sécurité des sessions prennent beaucoup plus de temps à combler, et ce sont elles qu'il faut vérifier en priorité.
Ce qu'un développeur full-stack JavaScript doit maîtriser en production
- TypeScript strict et validation à l'exécution
- Node.js : boucle d'événements et asynchrone
- Conception d'API NestJS ou REST
- React/Next.js ou Vue/Nuxt et rendu serveur
- Prisma, PostgreSQL et transactions
- Sessions, sécurité web et dépendances npm
Les questions à poser à un développeur full-stack JavaScript
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Une route Node.js génère un PDF de 300 pages, et toutes les autres requêtes du serveur ralentissent pendant ce temps. Pourquoi, et que faites-vous ?
Une bonne réponseNode.js exécute le JavaScript sur un seul fil. Les entrées-sorties ne bloquent pas, mais un calcul lourd occupe la boucle d'événements et plus aucune requête n'avance. Les solutions : déplacer le calcul dans un worker_thread, ou mieux le confier à une file de tâches (BullMQ avec Redis, par exemple) traitée par un process séparé, puis prévenir l'utilisateur quand le fichier est prêt. Pour mesurer, la personne cite le retard de la boucle d'événements (monitorEventLoopDelay) ou un profil CPU.
Signal d'alerte« J'ajoute async devant la fonction », comme si cela rendait le calcul non bloquant. Ou « on augmente la mémoire du serveur ».
Question 2 · confirmé
Le front et l'API partagent un type Commande dans le monorepo. Une requête arrive avec un montant en chaîne de caractères et passe sans erreur jusqu'à la base. Comment est-ce possible ?
Une bonne réponseLes types TypeScript disparaissent à la compilation : rien ne vérifie à l'exécution ce qui arrive par HTTP. Il faut valider à l'entrée de l'API, avec un schéma Zod ou un DTO class-validator derrière le ValidationPipe de NestJS (whitelist activée), et dériver le type du schéma pour n'avoir qu'une source. Même prudence avec un JSON.parse ou la réponse d'une API tierce, à typer en unknown puis à valider.
Signal d'alerte« TypeScript vérifie les types », ou un as Commande ajouté pour faire taire le compilateur.
Question 3 · confirmé
Dans une application Next.js avec l'App Router, un composant lit des produits en base puis affiche un bouton « Ajouter au panier ». Où s'exécute chaque partie ?
Une bonne réponseLes composants sont des Server Components par défaut : la lecture en base tourne sur le serveur, avec accès aux secrets, et n'envoie pas de JavaScript au navigateur. Le bouton est un Client Component, marqué 'use client', qui reçoit des props sérialisables. L'ajout au panier passe par une Server Action ou un route handler, qui reste un endpoint public à authentifier et à valider. Le paquet server-only empêche d'importer du code serveur côté client par erreur.
Signal d'alerte'use client' en tête de chaque fichier, l'idée qu'une Server Action est privée parce qu'elle n'a pas d'URL visible, ou une clé d'API mise dans une variable NEXT_PUBLIC_.
Question 4 · confirmé
Un utilisateur clique deux fois sur « Valider la commande » et le stock est décrémenté deux fois. Comment corrigez-vous côté API et base de données ?
Une bonne réponseUne écriture conditionnelle atomique (diminuer le stock seulement s'il reste au moins une unité, et vérifier le nombre de lignes modifiées) dans une transaction Prisma avec la création de la commande. Le front envoie une clé d'idempotence, enregistrée avec une contrainte unique, pour que la seconde requête renvoie la commande déjà créée. Désactiver le bouton améliore l'ergonomie mais ne protège rien.
Signal d'alerteLire le stock puis l'écrire en deux requêtes séparées, ou compter sur la désactivation du bouton.
Question 5 · confirmé
Où rangez-vous la session d'un utilisateur dans une application React avec une API Node.js, et pourquoi ?
Une bonne réponseDans un cookie HttpOnly, Secure et SameSite posé par le serveur : le JavaScript de la page ne peut pas le lire, donc une faille XSS ne peut pas le voler. Si le cookie part vers une autre origine, une protection CSRF s'ajoute (jeton dédié ou contrôle de l'en-tête Origin). La session est courte, renouvelée côté serveur et révocable. Le stockage dans localStorage expose le jeton à n'importe quel script injecté.
Signal d'alerteUn JWT dans localStorage « parce que c'est ce que montrent les tutoriels », signé avec un secret faible, sans aucun moyen de déconnecter quelqu'un.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recrutement full-stack JavaScript : questions fréquentes
TypeScript est-il indispensable pour un poste full-stack JavaScript ?
Pour un projet récent, en pratique oui : presque toutes les offres le demandent et le partage des types entre front et API repose dessus. Un candidat venu du JavaScript pur s'y met vite s'il est rigoureux. Vérifiez qu'il travaille en mode strict, sait typer un état avec une union discriminée, et sait surtout que les types disparaissent à l'exécution. Cette dernière notion manque souvent et coûte des bugs en production.
Un développeur React peut-il reprendre le back Node.js ?
Souvent, à condition de vérifier les points que le front n'apprend pas. La boucle d'événements et ce qui la bloque. Les transactions et la concurrence en base. Le stockage des sessions et les failles qui vont avec. La gestion d'une erreur inattendue en production. Un profil front qui répond correctement sur ces sujets tient un poste full-stack. S'il bute sur tous, il reste un développeur front qui sait écrire des routes.
Quel exercice proposer en test technique à un développeur full-stack JavaScript ?
Un petit projet existant à corriger en direct est plus parlant qu'une application à créer chez soi. Par exemple une route NestJS ou Express qui décrémente un stock deux fois et une page React qui recharge ses données en boucle. La personne cherche les causes en commentant à voix haute. Vous voyez en une heure sa lecture du code serveur et client, et la façon dont elle teste sa correction.
Next.js ou Nuxt sur un CV : que faut-il regarder ?
La version et le modèle de rendu. Avec Next.js, une expérience limitée au Pages Router ne couvre pas les Server Components et les Server Actions de l'App Router, qui changent la façon de lire les données et de sécuriser les mutations. Avec Nuxt, Nuxt 2 repose sur Vue 2, qui n'est plus maintenu, alors que les versions suivantes utilisent la Composition API. Demandez un exemple de page rendue côté serveur et de ce qui s'exécute dans le navigateur.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
