Les deux se défendent : Maven donne un build déclaratif et très conventionnel que n'importe qui lit facilement, tandis que Gradle offre des builds incrémentaux et un cache de build qui paient sur les gros projets multi-modules. Pour la reproductibilité, figez les versions exactes de dépendances, utilisez une nomenclature (bill of materials) pour les bibliothèques liées, évitez les plages de versions et les snapshots dans les releases, et exécutez le build dans un conteneur avec une chaîne d'outils fixée pour que la version du JDK ne soit pas celle qui traîne sur la machine.
Pourquoi les recruteurs posent cette question
Le recruteur s'intéresse moins à votre préférence qu'à savoir si vous avez des avis sur l'hygiène de build : gestion des dépendances, reproductibilité et temps de build. Mentionner le figeage des versions, une nomenclature et l'analyse des dépendances montre que vous traitez le build comme de l'infrastructure de production. Les builds lents et une résolution de dépendances capricieuse coûtent vraiment cher à une équipe, et cette question sert à savoir si vous le remarquez.
Comment structurer votre réponse
- Donnez une courte comparaison et un choix par défaut avec une raison.
- Couvrez la gestion des versions de dépendances et la nomenclature.
- Expliquez comment vous rendez les builds reproductibles d'une machine à l'autre.
- Mentionnez la vitesse de build et les contrôles de chaîne d'approvisionnement.
Exemple de réponse
Pour un service unique je prends en général Maven, parce que le build finit par être quelque chose que n'importe qui peut lire sans apprendre un langage propre au projet, et le parent Spring Boot gère l'essentiel. Pour un gros dépôt multi-modules où le temps de build est une taxe quotidienne, je préfère Gradle, puisque les builds incrémentaux et le cache de build changent vraiment la boucle de retour. Sur la reproductibilité, les règles sont les mêmes des deux côtés : versions exactes, pas de plages, pas de dépendances snapshot dans quoi que ce soit de publié, et une nomenclature pour les groupes de bibliothèques afin de mettre à niveau une famille d'un bloc au lieu de mélanger des versions et de récolter une erreur bizarre à l'exécution. Je fige le JDK avec une chaîne d'outils pour que le build ne dépende pas de ce qui est installé sur le portable de quelqu'un, et la CI construit dans un conteneur. Je veux aussi que l'arbre de dépendances soit vérifié en CI, à la fois pour les vulnérabilités et pour les montées de version transitives accidentelles, puisque l'incident classique est une montée de version mineure qui arrive par une dépendance transitive et change un comportement que personne n'a choisi.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Comment résolvez-vous un conflit entre deux versions transitives d'une bibliothèque ?
- Comment réduiriez-vous un build de dix minutes ?
- Quelle est votre politique pour mettre à niveau des dépendances avec des vulnérabilités connues ?
Autres questions pour Développeur Java
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions