Можешь ли работать без достаточной документации

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

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

Как отвечать

Скажите, что код и окружение сами по себе документация, и покажите метод, по которому их читаете:

• тесты: лучший источник ожидаемого поведения, особенно интеграционные на @SpringBootTest или Testcontainers;
• история: git log и git blame по спорному месту, ссылки на задачи в коммитах объясняют, зачем код такой;
• навигация в IDE: Find Usages и Call Hierarchy в IntelliJ IDEA, отладчик с точкой остановки на входе в сервис;
• запущенный сервис: эндпоинты /actuator/mappings и /actuator/beans, сгенерированный Swagger от springdoc, логи на уровне DEBUG;
• схема данных: миграции Liquibase или Flyway показывают, как таблицы менялись.

Вопросы коллегам тоже часть метода, но с подготовкой: вы приходите не с «как это работает», а с гипотезой «правильно ли я понял, что заказ отменяется здесь». Такой вопрос отнимает у человека пять минут, а не час.

Хорошо закончить тем, что вы оставили после себя: README по запуску, ADR с принятым решением, характеризационные тесты перед рефакторингом. Пример нужен ваш, с реальным модулем и реальным результатом. Если коммерческого опыта с плохой документацией не было, расскажите, как разбирались в исходниках библиотеки или open source проекта: подход тот же.

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

Отвечают «да, конечно» и на этом останавливаются. Без описания метода это звучит как пустое заявление.

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

Ругают прошлую команду за бардак в документации. Интервьюер слышит не проблему проекта, а то, как вы будете отзываться о новой команде. Выдуманные проценты вроде «ускорил на 30%» тоже вредят: их попросят обосновать.