Questions et réponses d'entretien pour développeur Java : le guide 2026

Les entretiens Java traînent une réputation de quiz de culture générale, et elle est en partie méritée. Les bons ont évolué. Ce qu'un jury compétent teste aujourd'hui, c'est si vous comprenez ce que fait le runtime sous votre code : où la mémoire est partie, pourquoi la pause a eu lieu, ce que le framework a généré à votre place, et ce qui casse quand deux threads atteignent la même ligne en même temps. Voici les questions qui reviennent, ce que chacune sonde, et comment se construit une bonne réponse.

Ce sont les schémas du métier en général ; si vous voulez la liste courte pour un entretien précis, collez l'annonce réelle dans le Question Predictor gratuit et obtenez les vingt questions les plus susceptibles de tomber dans ce processus précis.

Qu'évaluent vraiment les entretiens de développeur Java ?

Cinq domaines, de façon fiable : la JVM et le comportement mémoire, le ramasse-miettes, le framework de collections dans le détail réel, la concurrence, et le framework dans lequel vit l'équipe, presque toujours Spring. En dessous, une question que personne ne formule à voix haute : quand ce service déraillera en production à 2h du matin, saurez-vous trouver pourquoi ?

La profondeur monte fort avec la séniorité. Un junior doit avoir la mécanique juste ; un profil confirmé doit apporter des arbitrages et du diagnostic ; d'un senior, on attend un raisonnement sur le dimensionnement du tas, le choix du collecteur et la configuration des pools de threads, avec des anecdotes de production à l'appui. Une chose a vraiment changé : le code répétitif est gratuit désormais, donc les jurys passent moins de temps à vous faire écrire un builder et plus de temps à demander pourquoi une transaction n'a pas fait de rollback.

À quoi ressemble le processus d'entretien Java ?

Un parcours typique compte quatre à six étapes : une préqualification par le recruteur, un test technique mêlant code et fondamentaux, une épreuve de code plus longue, une épreuve de conception, et un échange avec le responsable du recrutement. Les grands groupes et les cabinets de conseil appuient sur les fondamentaux et Spring ; les entreprises produit pèsent plus la conception et la concurrence. Les exercices à emporter sont courants dans les entreprises de taille moyenne et portent en général sur un petit service Spring.

1. Préqualification par le recruteur (20 à 30 minutes). Version, framework, échelle, fourchette de salaire. Sachez quelle version de Java vise votre base de code, parce que répondre "la dernière" puis ne pas savoir ce qu'est un record se passe mal.
2. Test technique (45 à 60 minutes). Du code dans un éditeur partagé, plus des fondamentaux à la volée : collections, exceptions, immuabilité, streams.
3. Épreuve de code (60 minutes). Un problème pratique plutôt qu'un casse-tête : analyser et agréger un fichier, implémenter un petit cache, écrire un compteur thread-safe.
4. Épreuve de conception (60 minutes). Conception de service ou exercice orienté objet, avec la capacité et les modes de défaillance en plus pour les processus senior.
5. Épreuve framework et profondeur. Comportement de Spring, transactions, tests, parfois un exercice de relecture où vous critiquez une classe volontairement bancale.
6. Responsable du recrutement ou comportemental. Incidents, désaccords, mentorat, et si le niveau que vous annoncez survit au détail.

Si vous connaissez l'entreprise, les banques de questions par entreprise donnent une lecture plus rapide du style maison que de fouiller les forums, puisque les grands cabinets de conseil en particulier suivent un script constant.

À quelles questions sur la JVM et la mémoire s'attendre ?

Attendez-vous à expliquer le chemin du source au code qui tourne, et les zones mémoire où vivent vos objets. Le jury vérifie si la JVM est une boîte noire pour vous. Couvrez la compilation en bytecode, le chargement des classes, l'interprétation suivie de la compilation à la volée des chemins chauds, et la séparation entre tas, piles de threads et metaspace, sans que ça tourne au récital.

Déroulez ce qui se passe entre l'écriture d'une classe et son exécution. Ce que ça sonde : si vous comprenez le runtime sur lequel vous déployez. Allez dans l'ordre : javac produit du bytecode, le class loader le charge et le lie (la délégation au parent mérite d'être nommée), l'interpréteur commence à exécuter, et le compilateur JIT optimise les méthodes une fois qu'elles sont chaudes, avec l'inlining et la déoptimisation comme comportements bien réels.

Expliquez les zones mémoire de la JVM. Ce que ça sonde : votre capacité à localiser un problème de mémoire. Le tas contient les objets et c'est là que se fait la collecte ; chaque thread a une pile pour ses frames et ses variables locales ; le metaspace contient les métadonnées de classes, hors du tas. La mémoire native utilisée par les buffers est en dehors de tout ça, et c'est pour ça qu'un conteneur peut se faire tuer alors que le tas a l'air en bonne santé.

Comment diagnostiqueriez-vous une OutOfMemoryError en production ? Ce que ça sonde : une vraie expérience opérationnelle. Demandez d'abord laquelle, puisque le manque d'espace dans le tas, le metaspace et l'échec de création de thread ont des causes différentes. Ensuite, capturez un heap dump à l'erreur, inspectez l'arbre des dominateurs pour voir ce qui retient l'ensemble conservé, et regardez les logs de GC pour distinguer une croissance régulière d'un pic.

Quelles questions reviennent sur le ramasse-miettes ?

Les questions de GC testent votre capacité à raisonner sur le temps de pause face au débit. Partez de l'hypothèse générationnelle (la plupart des objets meurent jeunes), expliquez que les collectes jeunes coûtent peu et que les collectes complètes non, et traitez le choix du collecteur comme une décision liée aux exigences, pas comme une préférence. N'affirmez jamais qu'un flag de tuning règle un problème que vous n'avez pas mesuré.

Comment fonctionne réellement le ramasse-miettes ? Ce que ça sonde : la mécanique, pas le vocabulaire. Décrivez l'accessibilité depuis les racines du GC plutôt que le comptage de références, la séparation entre génération jeune et ancienne, les collectes mineures qui promeuvent les survivants, et les pauses stop-the-world comme la chose qui fait vraiment mal.

Comment choisissez-vous parmi les collecteurs disponibles ? Ce que ça sonde : si vous ajustez l'outillage à une cible de latence. G1 est le choix par défaut raisonnable pour la plupart des charges serveur et vise un objectif de pause. ZGC et Shenandoah échangent du débit contre des pauses très courtes sur de gros tas, ce qui compte quand 300ms font exploser votre budget.

Votre service affiche des pauses de 400ms au 99e centile. Comment attaquez-vous le problème ? Ce que ça sonde : la discipline de mesure. Activez les logs de GC et confirmez que les pauses sont bien du GC avant de toucher quoi que ce soit, parce que la contention sur les verrous et les appels lents en aval produisent des queues de distribution similaires. Si c'est bien le GC, regardez d'abord le taux d'allocation, parce que la plupart des problèmes de pause sont des problèmes d'allocation.

Quelles questions pose-t-on sur les collections Java ?

Les collections sont le filtre le plus fiable du parcours, parce que tout le monde prétend les connaître et que peu savent en expliquer les rouages. Soyez prêt à décrire comment HashMap est implémentée, pourquoi le contrat entre equals et hashCode n'est pas optionnel, quand une LinkedList est réellement le bon choix (rarement), et en quoi les collections concurrentes diffèrent d'un wrapper synchronisé.

Comment fonctionne HashMap en interne ? Ce que ça sonde : la profondeur. Couvrez le hachage de la clé, la répartition des bits, l'indexation dans le tableau de buckets, le chaînage des collisions dans une liste qui se convertit en arbre équilibré quand un bucket s'allonge, et le redimensionnement au facteur de charge par rehachage dans un tableau plus grand.

Quel est le contrat entre equals et hashCode, et qu'est-ce qui casse si vous le violez ? Ce que ça sonde : si vous avez déjà débogué ça. Des objets égaux doivent renvoyer des codes de hachage égaux ; des objets différents peuvent entrer en collision. Cassez ça et un objet placé dans un HashSet devient introuvable, parce que la recherche va dans le mauvais bucket.

ArrayList ou LinkedList : quand sortiriez-vous vraiment une LinkedList ? Ce que ça sonde : si vous répétez la complexité du manuel ou si vous pensez au matériel. Le grand O favorise LinkedList à l'insertion, mais ArrayList gagne en pratique sur presque toutes les charges parce que la mémoire contiguë est amie du cache et que la course aux pointeurs ne l'est pas. LinkedList se défend surtout comme deque, et ArrayDeque y fait en général mieux.

ConcurrentHashMap ou une map synchronisée : quelle différence ? Ce que ça sonde : la compréhension de la contention. Un wrapper synchronisé sérialise chaque opération sur un seul verrou ; ConcurrentHashMap permet des lectures concurrentes et des écritures avec verrous répartis, ce qui donne un bien meilleur débit en charge.

Quelles questions de concurrence posent les recruteurs Java ?

La concurrence sépare le confirmé du senior plus vite que n'importe quel autre sujet. Attendez-vous à la visibilité face à l'atomicité, à la configuration des pools de threads, aux interblocages, et de plus en plus aux threads virtuels. Les meilleures réponses évitent l'abstraction : décrivez la panne réelle, une lecture périmée, une mise à jour perdue ou un pool épuisé par des tâches bloquées, plutôt que de réciter des définitions de mots-clés.

Que garantit volatile, et que ne garantit-il pas ? Ce que ça sonde : le modèle mémoire. Volatile garantit la visibilité et l'ordre : une écriture est vue par les autres threads, et la réorganisation autour est restreinte. Il ne garantit pas l'atomicité, donc l'incrément d'un compteur volatile reste un bug de mise à jour perdue, parce que lire, ajouter et écrire font trois opérations.

Comment dimensionnez-vous un pool de threads, et qu'est-ce qui cloche avec les méthodes fabrique de confort ? Ce que ça sonde : si vous avez déjà vu un pool lâcher. Un pool fixe issu de la fabrique de confort utilise une file non bornée, donc en surcharge il accumule les tâches jusqu'à ce que le tas meure au lieu de renvoyer une pression. Construisez-le explicitement avec une file bornée et une politique de rejet, dimensionnée selon le type de charge.

Qu'est-ce qui cause un interblocage et comment l'éviter ? Ce que ça sonde : la précision alliée au pragmatisme. Un interblocage exige l'exclusion mutuelle, la détention avec attente, l'absence de préemption et une attente circulaire, et vous le cassez en supprimant une de ces conditions, en général avec un ordre global d'acquisition des verrous.

À quoi servent les threads virtuels, et quand n'aident-ils pas ? Ce que ça sonde : si vous êtes à jour. Ils rendent les entrées-sorties bloquantes bon marché, donc vous pouvez écrire du code bloquant simple à forte concurrence au lieu de le tordre en chaînes asynchrones. Ils n'accélèrent pas le travail lié au CPU, et les mettre en pool en détruit l'intérêt.

Quelles questions reviennent sur Spring et Spring Boot ?

Les questions Spring testent si vous comprenez ce que le framework génère pour vous. Attendez-vous aux fondamentaux de l'injection de dépendances, à la façon dont l'auto-configuration décide de ce qu'elle câble, au comportement des transactions et à la gestion des erreurs dans une couche REST. La question sur les transactions est le filtre senior classique, parce que les manières dont une annotation ne fait silencieusement rien sont exactement celles dont les vrais bugs arrivent en production.

Expliquez l'injection de dépendances, et pourquoi l'injection par constructeur est préférée. Ce que ça sonde : si vous comprenez l'inversion de contrôle ou si vous vous contentez d'annoter. L'injection par constructeur rend les dépendances explicites et obligatoires, autorise des champs final, et rend la classe testable sans conteneur. L'injection par champ cache les dépendances, laisse passer des références circulaires sans qu'on les remarque, et exige de la réflexion pour tester.

Comment fonctionne réellement @Transactional, et quand ne s'applique-t-il pas en silence ? Ce que ça sonde : les proxys. Spring enveloppe le bean dans un proxy qui ouvre et valide une transaction autour de l'appel, ce qui veut dire qu'une auto-invocation (une méthode qui en appelle une autre, annotée, dans la même classe) contourne complètement le proxy et s'exécute sans aucune transaction.

Que fait l'auto-configuration ? Ce que ça sonde : si la magie est comprise ou redoutée. Spring Boot évalue de la configuration conditionnelle en fonction de ce qui est dans le classpath et de ce que vous avez déjà défini, donc ajouter une dépendance câble des valeurs par défaut sensées et déclarer votre propre bean fait reculer la valeur par défaut. Le rapport de conditions montre exactement ce qui a correspondu, et c'est le moyen le plus rapide d'expliquer un bean surprenant.

Comment gérez-vous les erreurs dans une API REST Spring ? Ce que ça sonde : la cohérence. Centralisez avec un controller advice qui associe les types d'exceptions à des codes de statut et à un corps d'erreur stable, gardez les stack traces hors des réponses, et séparez correctement les erreurs client des erreurs serveur.

Quelles questions de langage et de conception se posent encore ?

Attendez-vous à une poignée de questions de langage utilisées comme calibrage : exceptions, immuabilité et ajouts récents. Gardez les réponses courtes et pratiques. Le jury vérifie que vos opinions viennent de la pratique et non d'une récitation, alors rattachez chacune à une décision que vous avez réellement prise dans une base de code.

Exceptions vérifiées ou non vérifiées : quelle est votre position ? Ce que ça sonde : votre goût en conception d'API. Les exceptions vérifiées obligent l'appelant à traiter une condition récupérable, mais elles polluent les signatures et se font avaler en pratique, et c'est pour ça que la plupart des bases de code modernes préfèrent les exceptions non vérifiées avec une frontière claire qui les traduit.

Quel problème résolvent les records et les types scellés ? Ce que ça sonde : votre actualité sur le langage. Les records donnent des porteurs de données immuables et concis, avec equals, hashCode et toString générés, ce qui supprime toute une classe de bugs écrits à la main. Les types scellés restreignent les implémentations autorisées, ce qui rend le pattern matching dans un switch exhaustif et vérifié à la compilation.

Quelles erreurs coulent les candidats Java ?

Presque toutes sont des manques de profondeur. Les jurys Java creusent deux ou trois niveaux sous la définition, donc un candidat qui a appris le vocabulaire mais n'a jamais lu un heap dump ni un thread dump se fait démasquer à la relance, pas à la première réponse. Voici les schémas récurrents.

• Réciter des définitions sans la mécanique. "Volatile rend ça thread-safe" est éliminatoire. Dites ce qu'il garantit et ce qu'il ne garantit pas.
• Ignorer le runtime. Un candidat incapable de décrire où va la mémoire ou ce qui cause une pause ne peut pas déboguer la production, aussi propre que soit son code.
• Traiter Spring comme de la magie. Ne pas savoir que les transactions passent par des proxys est le trou de niveau senior le plus fréquent.
• La complexité du manuel plutôt que le comportement réel. La réponse sur LinkedList tout droit sortie d'un manuel signale quelqu'un qui n'a jamais rien mesuré.
• Le silence pendant le code. Les jurys achètent votre raisonnement. Racontez l'approche, les cas limites et l'arbitrage pendant que vous tapez.
• Des connaissances périmées. Si l'équipe est sur une LTS actuelle et que vous n'avez jamais entendu parler des records ni des threads virtuels, ça se lit comme quelqu'un qui a arrêté d'apprendre.

Comment se préparer à un entretien Java ?

Choisissez les trois domaines que le jury va forcément creuser (les rouages des collections, la concurrence, et le framework nommé dans l'offre d'emploi) et amenez-les au point où vous savez les expliquer sans notes. Lisez une fois les logs de GC et un thread dump de votre propre service, pour que ces réponses viennent de l'expérience et non de la lecture. Puis répétez deux anecdotes de production, une sur la mémoire ou la latence et une sur un désaccord.

Avant le processus lui-même, collez la vraie offre d'emploi dans le Question Predictor gratuit et travaillez les vingt questions qu'il signale pour ce poste précis, parce qu'une équipe de trading à faible latence et une boîte Spring d'entreprise partagent un langage et à peu près rien d'autre.

Pour les épreuves en direct, GhostPilot est un copilote d'entretien en temps réel : un panneau latéral d'extension Chrome et une application de bureau Windows optionnelle qui transcrivent l'appel, attrapent la question au moment où elle tombe, et ont une réponse structurée prête environ deux secondes plus tard. Il aide le plus sur les questions à piège, comme celle sur les transactions. C'est une amorce, pas un texte à réciter, et le détail de production doit toujours venir de vous. L'offre gratuite vous donne 10 minutes d'entretien en direct par semaine, sans carte bancaire.

FAQ entretien Java

Combien de temps faut-il se préparer à un entretien de développeur Java ? Deux à trois semaines pour un poste confirmé si vous écrivez du Java tous les jours : une semaine sur les fondamentaux et les collections, une semaine sur la concurrence et le comportement du framework, quelques jours sur les anecdotes.

Quelle version de Java faut-il connaître pour les entretiens en 2026 ? Connaissez la LTS que fait tourner l'entreprise visée, et ce qu'ont apporté les versions récentes, en particulier les records, les types scellés, le pattern matching dans switch et les threads virtuels. Beaucoup de grands groupes sont encore sur une LTS plus ancienne, alors soyez honnête sur ce que vous avez réellement utilisé.

Quel niveau de Spring faut-il ? Si l'offre mentionne Spring, traitez-le comme un sujet de premier plan et pas comme une note de bas de page. L'injection de dépendances, l'auto-configuration, les transactions et les tests reviennent dans presque tous les parcours Spring, et la question sur les transactions est là où les candidats perdent le plus souvent l'étape.

Faut-il admettre quand on ne sait pas ? Oui. "Je n'ai pas réglé ce collecteur en production, mais voilà comment je m'y prendrais et ce que je mesurerais en premier" bat une mauvaise réponse assénée avec assurance. Les jurys Java creusent deux ou trois niveaux dans les relances, donc le bluff s'effondre vite.