Расскажите про опыт с инструментами сборки

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

Работали ли вы со сборкой руками или только нажимали кнопку в среде разработки. Конкретно: умеете ли разобрать конфликт версий, починить упавший билд, настроить многомодульный проект и сделать сборку повторяемой на чужой машине и в CI.

Как отвечать

Назовите инструмент и сразу переходите к тому, что делали сами:

• структура проекта: один модуль или несколько, родительский pom.xml либо общий скрипт сборки, где хранятся версии зависимостей;
• зависимости: dependencyManagement и BOM для Spring Boot, области видимости test и provided, разделение implementation и api в Gradle;
• конфликты версий: смотрите дерево через mvn dependency:tree или задачу dependencies в Gradle. В Maven из двух транзитивных версий побеждает ближайшая к корню, в Gradle по умолчанию самая высокая. Лечится исключением или фиксацией версии в одном месте;
• плагины и фазы: surefire для юнит-тестов и failsafe для интеграционных, сборка исполняемого архива, генерация кода;
• повторяемость: обёртки mvnw и gradlew, зафиксированные версии плагинов, кэш зависимостей в CI.

Держите наготове одну историю. Например: после обновления библиотеки приложение падало на старте, в дереве зависимостей оказались две версии одного артефакта, версию зафиксировали через BOM и добавили проверку в сборку.

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

Ограничиваются фразой «собирали Maven». Вопрос про фазы жизненного цикла или про то, чем package отличается от install, заканчивает тему за полминуты.

Не могут объяснить, как разрешается конфликт версий. Это первое, обо что спотыкаются при переезде между инструментами: правило выбора версии у них разное, и молчаливая подмена ломает приложение уже в рантайме.

Приписывают себе ускорение сборки в процентах. Спросят, за счёт чего: параллельные модули, кэш, инкрементальность? Если тесты просто отключили в основном профиле, это не ускорение, а перенос проблемы в прод.