Questions d'entretien Junior Ingénieur Fullstack

Ce qui est attendu au niveau Junior

On attend des tâches guidées de fonctionnalité complète avec de solides fondamentaux dans une couche.

Exemples de questions d'entretien pour Ingénieur Fullstack

• TechniqueComment décidez-vous quelle logique revient au client et laquelle au serveur ?
  Ce qu'une bonne réponse couvre

  • Séparation des préoccupations
  • Sécurité des données sensibles vs performance
  • Validation côté client vs serveur
  • Gestion d'état et latence réseau
  • Expérience hors-ligne et résilience

  Voir un exemple de réponse

  La décision repose sur plusieurs facteurs : en premier lieu, les données sensibles ou les règles métier critiques doivent impérativement être traitées côté serveur pour des raisons de sécurité et d'intégrité. La validation côté client améliore l'expérience utilisateur en évitant des allers-retours inutiles, mais ne remplace jamais la validation serveur. Pour la logique lourde (calculs complexes, agrégations), le serveur est plus approprié car il peut utiliser des ressources dédiées et évite de surcharger l'appareil client. En gestion d'état, le client gère l'état local (UI, cache) tandis que le serveur est l'autorité sur l'état persistant. Enfin, pour les fonctionnalités hors-ligne ou à faible latence, on peut déplacer plus de logique côté client (ex : applications PWA). Un piège courant est de dupliquer la logique de validation, ce qui peut causer des incohérences ; il faut toujours maintenir le serveur comme source de vérité.

• TechniqueExpliquez le fonctionnement de l'authentification et des sessions de bout en bout.
  Ce qu'une bonne réponse couvre

  • Différence entre sessions côté serveur et tokens JWT
  • Flux OAuth2 pour délégation
  • Stockage sécurisé des tokens (httpOnly, Secure)
  • Gestion du rafraîchissement et expiration
  • Prévention CSRF et XSS

  Voir un exemple de réponse

  L'authentification de bout en bout commence par la vérification des identifiants (login/password) côté serveur, qui génère un jeton (généralement JWT) ou une session. Avec une session classique, le serveur stocke l'identifiant de session côté serveur et envoie un cookie httpOnly ; chaque requête vérifie la session en base. Avec JWT, le serveur signe un jeton contenant les claims (userId, rôle, expiration) et le renvoie au client. Le client le stocke (localStorage ou cookie) et l'envoie dans l'en-tête Authorization. Une pratique courante est d'utiliser un token courte durée (15 min) et un refresh token longue durée stocké dans un cookie httpOnly pour éviter le XSS. Le rafraîchissement s'effectue silencieusement via un endpoint dédié. Pour la sécurité, il faut protéger les endpoints avec CSRF tokens si on utilise des cookies, et valider la signature du JWT à chaque requête. Un écueil fréquent est de stocker le JWT dans localStorage sans protection XSS ; il est préférable d'utiliser un cookie httpOnly avec un mécanisme de rotation.

• TechniqueComment optimiseriez-vous une page lente qui dépend d'une API lente ?
  Ce qu'une bonne réponse couvre

  • Mise en cache côté client (Service Worker, Cache-Control)
  • Lazy loading et chargement différé
  • Optimistic UI avec mise à jour locale
  • Batching et pagination des appels API
  • Server-side rendering ou génération statique

  Voir un exemple de réponse

  Pour optimiser une page ralentie par une API lente, on applique plusieurs stratégies combinées. D'abord, on met en cache les réponses de l'API côté client via un Service Worker ou des headers Cache-Control appropriés, en validant l'obsolescence avec ETag. Ensuite, on utilise le lazy loading : on ne charge les composants ou données que lorsqu'ils deviennent visibles (Intersection Observer). L'interface utilisateur optimiste affiche immédiatement une version locale des données (comme un état instantané) avant la confirmation serveur, ce qui donne l'illusion de réactivité. On peut aussi grouper plusieurs requêtes en une seule (batching) ou paginer les données pour réduire le temps de réponse perçu. Enfin, le rendu côté serveur (SSR) ou la génération statique (SSG) peut livrer une page déjà partiellement peuplée, réduisant le besoin de requêtes API au chargement. Un piège classique est de négliger l'expérience d'erreur : il faut prévoir des fallbacks et des messages clairs en cas d'échec.

• ProgrammationConstruisez une petite fonctionnalité CRUD : schéma, endpoint d'API et un formulaire d'UI.
  Ce qu'une bonne réponse couvre

  • Schéma de base de données (SQL) avec clé primaire
  • Endpoint RESTful (GET, POST, PUT, DELETE)
  • Validation et gestion des erreurs
  • Formulaire React avec état local et soumission
  • Idempotence et navigation après mutation

  Voir un exemple de réponse

  On construit une fonctionnalité CRUD simple pour une liste de tâches. Le schéma SQL : une table 'tasks' avec id (SERIAL PRIMARY KEY), title (TEXT NOT NULL), completed (BOOLEAN DEFAULT FALSE), created_at (TIMESTAMP). L'API REST expose les endpoints : GET /api/tasks (liste), POST /api/tasks (créer), PUT /api/tasks/:id (mettre à jour), DELETE /api/tasks/:id (supprimer). Le contrôleur valide les données et retourne JSON. Le formulaire UI est un composant React avec useState pour le titre et un champ texte ; à la soumission, il appelle POST /api/tasks, puis met à jour la liste locale ou navigue vers la page de détails. On prévoit la gestion d'erreur (toast). Un écueil : oublier de gérer le chargement et les doublons de soumission.

  // Schéma SQL (exécution dans la base)
  -- CREATE TABLE tasks (
  --   id SERIAL PRIMARY KEY,
  --   title TEXT NOT NULL,
  --   completed BOOLEAN DEFAULT FALSE,
  --   created_at TIMESTAMP DEFAULT NOW()
  -- );
  
  // Endpoint avec Express (Node.js)
  import express from 'express';
  const router = express.Router();
  
  router.get('/', async (req, res) => {
    const tasks = await db.query('SELECT * FROM tasks ORDER BY created_at');
    res.json(tasks.rows);
  });
  
  router.post('/', async (req, res) => {
    const { title } = req.body;
    if (!title || title.length === 0) {
      return res.status(400).json({ error: 'Le titre est obligatoire' });
    }
    const result = await db.query(
      'INSERT INTO tasks (title) VALUES ($1) RETURNING *',
      [title]
    );
    res.status(201).json(result.rows[0]);
  });
  
  router.put('/:id', async (req, res) => {
    const { title, completed } = req.body;
    const { id } = req.params;
    const result = await db.query(
      `UPDATE tasks SET title = COALESCE($1, title), completed = COALESCE($2, completed) WHERE id = $3 RETURNING *`,
      [title, completed, id]
    );
    if (result.rows.length === 0) {
      return res.status(404).json({ error: 'Tâche introuvable' });
    }
    res.json(result.rows[0]);
  });
  
  router.delete('/:id', async (req, res) => {
    const { id } = req.params;
    await db.query('DELETE FROM tasks WHERE id = $1', [id]);
    res.status(204).send();
  });
  
  export default router;
  
  // Formulaire React
  import React, { useState } from 'react';
  
  function TaskForm({ onTaskCreated }) {
    const [title, setTitle] = useState('');
    const [error, setError] = useState(null);
  
    const handleSubmit = async (e) => {
      e.preventDefault();
      setError(null);
      try {
        const res = await fetch('/api/tasks', {
          method: 'POST',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ title }),
        });
        if (!res.ok) {
          const data = await res.json();
          throw new Error(data.error);
        }
        const newTask = await res.json();
        onTaskCreated(newTask); // Met à jour la liste parent
        setTitle('');
      } catch (err) {
        setError(err.message);
      }
    };
  
    return (
      <form onSubmit={handleSubmit}>
        <input
          type="text"
          value={title}
          onChange={(e) => setTitle(e.target.value)}
          placeholder="Nouvelle tâche"
          required
        />
        {error && <p style={{ color: 'red' }}>{error}</p>}
        <button type="submit">Ajouter</button>
      </form>
    );
  }
  
  export default TaskForm;

• ProgrammationImplémentez des mises à jour optimistes de l'UI avec retour arrière en cas d'échec.
  Ce qu'une bonne réponse couvre

  • Principe de mise à jour optimiste
  • Copie d'état avant mutation
  • Restauration de l'état en cas d'erreur
  • Gestion des erreurs avec messages utilisateur
  • File d'attente de requêtes pour éviter les conflits

  Voir un exemple de réponse

  L'implémentation d'une mise à jour optimiste consiste à mettre à jour immédiatement l'interface utilisateur avant la confirmation du serveur, puis à annuler la modification si la requête échoue. En React, on peut utiliser un hook personnalisé qui sauvegarde l'état avant la mutation et le restaure en cas d'erreur. On utilise useState pour l'état local et on stocke une copie de sauvegarde. La fonction de mise à jour appelle d'abord setState avec la nouvelle valeur, puis effectue la requête fetch. En cas d'échec, on rétablit la sauvegarde et on affiche une notification d'erreur. Pour éviter des conflits avec des mises à jour concurrentes, on peut gérer une file d'attente de mutations ou utiliser un mécanisme de verrouillage. Un écueil est d'ignorer la latence réseau : si l'utilisateur effectue plusieurs modifications rapides, il faut annuler toutes les mutations dépendantes de la précédente si celle-ci échoue.

  import React, { useState, useCallback } from 'react';
  
  function useOptimisticUpdate(initialData, apiUpdateFn) {
    const [data, setData] = useState(initialData);
    const [error, setError] = useState(null);
  
    const optimisticUpdate = useCallback(async (newData, rollbackData) => {
      // Sauvegarde de l'état avant modification
      const previousData = data;
      // Application immédiate de la nouvelle valeur
      setData(newData);
      setError(null);
      try {
        await apiUpdateFn(newData);
      } catch (err) {
        // En cas d'échec, restauration de l'état précédent
        setData(previousData);
        setError(err.message || 'Erreur lors de la mise à jour');
        // Optionnel : rollback supplémentaire personnalisé
        if (rollbackData) rollbackData();
      }
    }, [data, apiUpdateFn]);
  
    return { data, error, optimisticUpdate };
  }
  
  // Exemple d'utilisation dans un composant
  function TaskItem({ task, onToggle }) {
    const { data, error, optimisticUpdate } = useOptimisticUpdate(
      task,
      async (updatedTask) => {
        const res = await fetch(`/api/tasks/${updatedTask.id}`, {
          method: 'PUT',
          headers: { 'Content-Type': 'application/json' },
          body: JSON.stringify({ completed: updatedTask.completed }),
        });
        if (!res.ok) throw new Error('Échec de la mise à jour');
      }
    );
  
    const handleToggle = () => {
      const newTask = { ...data, completed: !data.completed };
      optimisticUpdate(newTask);
    };
  
    return (
      <div>
        <label style={{ textDecoration: data.completed ? 'line-through' : 'none' }}>
          <input type="checkbox" checked={data.completed} onChange={handleToggle} />
          {data.title}
        </label>
        {error && <span style={{ color: 'red' }}>Erreur: {error}</span>}
      </div>
    );
  }
  
  export default TaskItem;

• Conception de systèmesConcevez un système de commentaires avec mises à jour en temps réel et modération.
  Ce qu'une bonne réponse couvre

  • Architecture en temps réel (WebSockets ou SSE)
  • File d'attente de modération (pub/sub, Kafka)
  • Base de données avec cache (Redis)
  • Flux : commentaire -> modération -> notification
  • Évolutivité et résilience

  Voir un exemple de réponse

  Le système de commentaires temps réel avec modération repose sur une architecture publish/subscribe. Lorsqu'un utilisateur soumet un commentaire via une requête HTTP POST, le serveur l'insère dans une file d'attente (ex: RabbitMQ) pour modération asynchrone. Un worker de modération (automatique ou manuel) vérifie le contenu (spam, abus) et, si approuvé, publie un événement sur un canal Redis ou un bus Kafka. Les clients connectés via WebSocket reçoivent cet événement en temps réel. On utilise une base de données relationnelle (PostgreSQL) pour la persistance et Redis pour le cache des commentaires récents et la diffusion temps réel. Pour la modération, on peut déléguer les commentaires suspects à une file de validation humaine. L'évolutivité se gère en ajoutant des workers de modération et en partageant les WebSockets via un adaptateur Redis. Un piège fréquent est la gestion du décalage entre l'écriture en base et la publication ; on préfère un modèle event-driven où la base est source de vérité et le cache met à jour après validation.

• ComportementalParlez-moi d'une fonctionnalité que vous avez livrée entièrement seul.
  Ce qu'une bonne réponse couvre

  • Méthode STAR : Situation, Tâche, Action, Résultat
  • Exemple concret de fonctionnalité livrée seul
  • Prise de décision et priorisation
  • Collaboration et communication malgré l'isolement
  • Résultats mesurables

  Voir un exemple de réponse

  J'ai développé seul un module de tableau de bord analytics pour notre application SaaS. La situation : l'équipe était surchargée, et le client pressait pour avoir des graphiques temps réel sur l'utilisation. Ma tâche était de livrer cette fonctionnalité en deux semaines. J'ai d'abord recueilli les besoins auprès du client, puis conçu l'architecture : collecte de données via des événements asynchrones, stockage dans ClickHouse, et API REST exposée à un front-end React avec chart.js. J'ai implémenté l'ingestion, les requêtes agrégées, le rendu des graphiques et la mise en cache. Le résultat : le module a été livré dans les temps, avec une réduction de 40% du temps de chargement par rapport à une solution initiale prévue, et a permis au client de prendre des décisions plus rapidement. Le suivi a impliqué des revues de code asynchrones et des démos régulières avec l'équipe produit.

• ComportementalComment décidez-vous dans quelle partie de la pile approfondir ?
  Ce qu'une bonne réponse couvre

  • Objectifs de carrière et alignement avec le métier
  • Principe de la forme en T (T-shaped)
  • Analyse de la demande du marché et de l'entreprise
  • Identification des goulets d'étranglement dans le projet
  • Apprentissage continu et mentorat

  Voir un exemple de réponse

  Ma décision d'approfondir un domaine repose sur trois axes : d'abord, la valeur métier : si un composant de la pile cause des ralentissements récurrents ou des bugs critiques, j'investis du temps pour le maîtriser. Ensuite, l'alignement avec mes objectifs de carrière : si je vise un poste d'architecte, je creuse le backend et l'infrastructure ; si je préfère le produit, j'approfondis le front-end et l'UX. Enfin, le principe de la forme en T : je maintiens une large connaissance de toute la stack, mais je développe une expertise pointue dans un domaine (ex : performance Web ou systèmes distribués) pour apporter une valeur unique à l'équipe. Je consacre régulièrement 20% de mon temps à l'apprentissage : lire des RFCs, participer à des conférences, ou contribuer à l'open source. Un écueil est de trop se spécialiser trop tôt ; la polyvalence permet de mieux comprendre les compromis.

Ce que les recruteurs évaluent

Comment se préparer

• Choisissez un domaine de profondeur et affichez-le clairement — les généralistes qui approfondissent quelque part se démarquent.
• Racontez tout le cycle de vie d'une requête pour montrer une compréhension de bout en bout.
• Ne négligez pas les tests et le déploiement ; les entretiens fullstack sondent la livraison, pas seulement le code.

Questions fréquentes