Использовали ли вы Apache Maven для сборки проектов

Что проверяют

Работали ли вы с Maven руками или только нажимали кнопку в IDEA. Интервьюер ждёт, что вы разберётесь с конфликтом версий и сломанной сборкой. Следом часто спрашивают, чем install отличается от package и как выяснить, откуда в проект приехала библиотека.

Как отвечать

Начните с контекста: какие проекты, один модуль или многомодульный, как Maven встроен в CI. Дальше покажите устройство:

• жизненный цикл: фазы validate, compile, test, package, verify, install, deploy идут по порядку, вызов фазы выполняет все предыдущие. install кладёт артефакт в локальный ~/.m2/repository, deploy в Nexus или Artifactory. В CI обычно хватает mvn verify;
• зависимости: области compile, provided, runtime, test; версии держат в dependencyManagement и BOM, например от Spring Boot. При конфликте транзитивных версий побеждает ближайшая к проекту, поэтому незаметно может приехать старая библиотека. Диагностика через mvn dependency:tree, лечение явной версией или <exclusions>, а maven-enforcer-plugin не пустит расхождение в сборку;
• плагины: Surefire гоняет юнит-тесты на фазе test, Failsafe интеграционные на verify, spring-boot-maven-plugin собирает исполняемый fat jar;
• многомодульность: родительский pom.xml, сборка одного модуля с зависимостями через -pl module -am, Maven Wrapper mvnw для единой версии Maven у всех.

Приведите свой случай: конфликт версий Jackson или Netty, ускорение сборки через -T, переход на BOM. Детали и цифры должны быть ваши. Если опыт только с Gradle, скажите об этом и сравните: декларативный XML против Kotlin DSL, где Gradle быстрее за счёт кэша сборки.

Где спотыкаются

Считают, что mvn clean install сам по себе даёт запускаемый JAR. Обычный jar не содержит зависимостей, нужен spring-boot-maven-plugin, Shade или Assembly.

Не знают правило ближайшей версии и лечат конфликт перебором версий наугад.

Гоняют install в CI без нужды и засоряют локальный репозиторий раннера или пропускают SNAPSHOT-зависимости в релизную сборку.