Entretien de tech lead Java sur l'architecture, Spring Boot et la JVM

Dans les offres françaises, le tech lead Java partage son temps entre le code et l'encadrement technique d'une équipe de quatre à huit développeurs, parfois en partie à distance. Il conçoit les évolutions, estime, relit les merge requests, tient la CI et intervient sur les incidents difficiles. La stack revient d'une offre à l'autre : Java 17 ou 21, Spring Boot, JPA et Hibernate, Kafka, PostgreSQL ou Oracle, Docker et Kubernetes, souvent Angular ou React côté front.

Très bons développeurs seniors, beaucoup de candidats n'ont jamais décidé pour une équipe. L'écart se voit vite sur une montée de version planifiée, sur un incident de performance analysé avec de vraies mesures et sur des règles de code que l'équipe applique sans que le lead relise tout. Demandez chaque fois ce qui a été décidé, sur quels chiffres, et ce que l'équipe a dû changer.

Spring Boot 4.0 est sorti en novembre 2025 sur Spring Framework 7, le support open source de la branche 3.5 s'est arrêté en juin 2026, et Java 25 est la dernière version LTS. Un tech lead à jour sait ce que ces versions imposent au code et aux dépendances. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.

La stack Java qu'un tech lead doit tenir

Java 21 et Java 25

Les deux versions LTS récentes. Java 21 a stabilisé les threads virtuels et le pattern matching dans les switch, Java 25 est sortie en septembre 2025. Beaucoup d'équipes sortent encore de Java 8 ou 11, et c'est souvent le tech lead qui conduit ces montées de version.

Spring Boot et Spring Framework

Le socle de la plupart des services Java. Spring Boot 4.0 repose sur Spring Framework 7 et Jakarta EE 11. Le tech lead décide quand migrer, dans quel ordre, et comment garder l'équipe sur une version encore supportée.

JPA et Hibernate

La couche d'accès aux bases relationnelles, d'où viennent beaucoup de problèmes de performance : requêtes N+1, chargements trop larges, transactions trop longues. Le tech lead fixe les règles de chargement, de projection et de pagination, et sait lire le SQL généré.

JVM et garbage collector

Le tas, les collecteurs (G1 par défaut, ZGC pour des pauses très courtes), les threads. Un tech lead sait lire un heap dump et un thread dump, régler la mémoire d'un conteneur et dire si une lenteur vient du GC ou du code.

Kafka

Très présent dans les offres pour faire communiquer les services par événements. Les sujets du tech lead : ordre des messages, rejeu, consommateurs idempotents, schéma des événements et son évolution.

Maven ou Gradle, et la CI

La construction, les dépendances et la chaîne d'intégration (GitLab CI, Jenkins, GitHub Actions). Le tech lead tient les versions des dépendances, les contrôles automatiques (tests, SonarQube, analyse des vulnérabilités) et la durée du build.

JUnit, Mockito, Testcontainers, ArchUnit

JUnit et Mockito pour les tests unitaires, Testcontainers pour tester contre une vraie base ou un vrai Kafka, ArchUnit pour vérifier les règles d'architecture par des tests. Ces outils font respecter les règles de l'équipe sans que le lead relise chaque ligne.

Micrometer et OpenTelemetry

Les métriques avec Micrometer, les traces avec OpenTelemetry, des logs structurés, puis Prometheus et Grafana ou un outil du marché. Sans ces mesures, un incident de production se discute à l'intuition.

Le tech lead Java n'est pas un manager. Il ne mène en général pas les entretiens annuels des développeurs, et on attend de lui une part importante de code. Selon l'organisation, il dépend d'un engineering manager ou d'un responsable de domaine, et travaille avec un architecte et un product owner. Les offres citent les revues de merge requests, les estimations, la documentation d'architecture, les mises en production et le support sur les incidents complexes, souvent avec une partie de l'équipe à distance. Sur un CV, cherchez la taille de l'équipe, les décisions techniques nommées et les montées de version conduites.

Ce qu'un tech lead Java doit maîtriser

• Architecture et découpage du code
• Spring Boot avancé et montées de version
• Performance et diagnostic JVM
• Persistance JPA et transactions
• Qualité, tests et revue de code
• CI/CD, sécurité et exploitation

Cinq décisions techniques à faire expliquer à un tech lead Java

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.

1. Question 1 · senior

   Vous devez faire passer une application de Spring Boot 2.7 et Java 11 à Spring Boot 4 et Java 21 ou 25. Comment planifiez-vous la migration ?

   Une bonne réponsePar étapes : Java 17 sur la dernière 2.7, puis Spring Boot 3 avec le passage de javax à jakarta, puis la 3.5 en corrigeant les dépréciations, et enfin Spring Boot 4. OpenRewrite automatise une partie des changements. Chaque étape passe la CI et la recette, avec un inventaire des dépendances qui bloquent (bibliothèques pas encore passées à Jakarta). Spring Security se traite à part, sa configuration ayant beaucoup changé.

   Signal d'alerteChanger tous les numéros de version d'un coup, puis corriger les erreurs de compilation une à une.

2. Question 2 · confirmé

   La mémoire d'un service monte pendant trois jours jusqu'à l'OutOfMemoryError, puis le pod redémarre. Comment trouvez-vous la cause ?

   Une bonne réponseLe candidat vérifie d'abord de quelle mémoire il s'agit, tas Java ou hors tas (metaspace, buffers directs, threads), en comparant les métriques de la JVM et celles du conteneur. Pour le tas, un heap dump, pris automatiquement avec -XX:+HeapDumpOnOutOfMemoryError ou à chaud, analysé dans Eclipse MAT pour trouver ce qui retient les objets : cache sans limite, collection statique, ThreadLocal jamais vidé. Puis un test qui reproduit la fuite.

   Signal d'alerteAugmenter -Xmx et programmer un redémarrage chaque nuit.

3. Question 3 · confirmé

   En revue de code, vous voyez une entité JPA avec cinq associations en FetchType.EAGER. Que demandez-vous de changer, et pourquoi ?

   Une bonne réponsePasser les associations en LAZY, en rappelant que @ManyToOne et @OneToOne sont EAGER par défaut, puis charger ce dont chaque cas d'usage a besoin avec JOIN FETCH, @EntityGraph ou une projection DTO pour la lecture. Sinon chaque lecture ramène tout le graphe et les listes déclenchent des requêtes N+1. Il demande d'activer les logs SQL ou les statistiques Hibernate en développement pour le constater.

   Signal d'alerteGarder EAGER « pour éviter les LazyInitializationException », ou laisser open-in-view activé pour les masquer.

4. Question 4 · senior

   Un monolithe Spring Boot de 400 000 lignes devient difficile à faire évoluer, et l'équipe veut passer aux microservices. Que proposez-vous ?

   Une bonne réponseD'abord mesurer où ça coince : durée du build, conflits de fusion, modules couplés, besoin réel de déployer à part. Un monolithe modulaire règle souvent une bonne partie du problème : des modules par domaine avec des dépendances contrôlées (modules Maven ou Gradle, Spring Modulith, règles ArchUnit) et des tables qui ne sont plus partagées entre modules. Un service n'est extrait que si un module a un besoin propre de charge, de cycle de livraison ou d'équipe.

   Signal d'alerteDix services dès le départ, qui partagent la même base et s'appellent en chaîne.

5. Question 5 · senior

   Quelles règles de revue de code mettez-vous en place pour une équipe de six développeurs, et lesquelles confiez-vous aux outils ?

   Une bonne réponseLes outils prennent ce qui se vérifie automatiquement : formatage commun (Spotless par exemple), analyse statique (SonarQube, Error Prone ou SpotBugs), couverture du code modifié, règles d'architecture en ArchUnit, vulnérabilités des dépendances. La revue humaine porte sur la conception, les noms, les cas d'erreur et les tests. Des merge requests courtes, un délai de revue suivi, et des relecteurs autres que le lead.

   Signal d'alerteLe lead relit seul chaque merge request, ou des revues limitées au style.

Les questions des recruteurs sur le poste de tech lead Java

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.