Есть ли опыт написания программной документации
Что проверяют
Умеете ли вы передать знание о коде другим людям: новичку в команде, соседней команде, себе через полгода. Следом обычно спрашивают, как вы держите документацию актуальной, потому что устаревший документ хуже отсутствующего.
Как отвечать
Опирайтесь на свой опыт и называйте конкретные артефакты, а не «писал документацию»:
- README и онбординг: как собрать проект с нуля, какая версия JDK и Android Studio нужна, где взять ключи и что положить в
local.properties, как запустить тесты и собрать сборку для тестировщиков; - KDoc: комментарии к публичному API модулей и библиотек. Из них Dokka генерирует HTML-документацию, это особенно ценно в многомодульном проекте или SDK для других команд;
- архитектурные решения: ADR, короткие записи о том, почему выбрали, например, Hilt вместо Koin или Compose Navigation вместо фрагментов. Схемы модулей удобно держать в Mermaid прямо в репозитории;
- контракты и процессы: описание API с бэкендом (часто в OpenAPI), чеклист релиза в Google Play, CHANGELOG.
Дальше расскажите, как документация остаётся живой: лежит рядом с кодом, правится в том же pull request, а ревьюер проверяет и её. Если есть эффект, назовите его своими цифрами: новичок собрал проект за день вместо недели, вопросов в чате стало меньше. Придуманные проценты на интервью разваливаются на первом уточнении.
Если опыта мало, скажите честно и покажите, что есть: KDoc в своём модуле, README пет-проекта, подробные описания pull request. И добавьте, что вы сделали бы первым делом в новой команде, например описали бы локальную сборку.
Где спотыкаются
Говорят, что хороший код документирует себя сам. Названия методов объясняют «что», но не объясняют «почему» и не расскажут, как настроить окружение.
Путают программную документацию с пользовательской справкой и рассказывают про инструкции для клиентов вместо документации для разработчиков.
Описывают разовый большой документ в Confluence, который никто не обновлял. Интервьюер услышит не опыт, а проблему.