Кто решает технические детали реализации: техлид или разработчики

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

Как вы понимаете границы ответственности в команде и умеете ли одновременно предлагать решения и принимать чужие. Интервьюер ищет крайности: пассивного исполнителя, который ждёт указаний по каждому классу, и одиночку, который всё делает по-своему. Следом почти всегда спрашивают, что вы делали, когда были не согласны с техлидом.

Как отвечать

Сильный ответ строится не на том, «кто главный», а на уровне решения:

• архитектурные решения: границы сервисов, выбор хранилища, синхронные вызовы или события через Kafka, общие библиотеки, переход на новую мажорную версию Spring Boot. Последнее слово за техлидом или архитектором, но после обсуждения с командой, а итог фиксируется в ADR или дизайн-документе;
• детали внутри задачи: структура классов, выбор коллекции, запрос через JPA или JdbcTemplate, обработка ошибок, тесты. Это решает разработчик, а проверкой служит код-ревью;
• пограничные случаи: новая зависимость в pom.xml или build.gradle, изменение публичного API, схемы базы или контракта события. Разработчик предлагает, но согласует, потому что это задевает других.

Дальше пример из своего опыта. Скажем, вы предложили заменить RestTemplate на RestClient из Spring Framework 6.1 или включить виртуальные потоки Java 21 через spring.threads.virtual.enabled, подготовили короткое сравнение и замеры, а техлид попросил сначала проверить на одном сервисе. Покажите механику: как вынесли вопрос, какие аргументы привели, чем закончилось.

Про несогласие: вы приводите аргументы с фактами, а если решение всё же принято иначе, выполняете его добросовестно и не саботируете. Этот принцип часто называют «disagree and commit».

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

Говорят «всё решает техлид, я пишу код». Для мидла и выше это звучит как отсутствие инициативы и ответственности за результат.

Уходят в обратную крайность: «я сам выбираю, как лучше». Интервьюер слышит будущие конфликты и зоопарк библиотек в проекте.

Рассказывают о процессе без примера. Один конкретный случай с технической сутью весит больше, чем общие слова о командной работе.