Есть ли документация по проекту

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

Как устроена работа с документацией в вашем проекте и участвовали ли вы в ней сами или относитесь к тем, у кого «всё в коде». Следом обычно спрашивают, как вы разбирались в проекте без документации и что оставили после себя.

Как отвечать

Опишите по слоям, что было в проекте, и честно отметьте пробелы:

• README и запуск: как поднять сервис локально, профили Spring, docker compose для зависимостей. Это первое, что читает новичок;
• API: OpenAPI-спецификация. В Spring Boot 3 её обычно генерирует springdoc-openapi, либо идут от контракта и генерируют код через openapi-generator. Для строгих команд есть Spring REST Docs: документация собирается из тестов и не может разойтись с поведением;
• архитектура: диаграммы в нотации C4 в PlantUML или Structurizr, ADR (Architecture Decision Records) в репозитории рядом с кодом;
• схема базы: миграции Liquibase или Flyway сами по себе хранят историю изменений;
• Javadoc: на публичных API библиотек и неочевидных местах, а не на каждом геттере;
• wiki: Confluence или аналог для бизнес-процессов и регламентов.

Добавьте свою роль: что вы написали или обновили и почему. Хороший пример: после инцидента дописали runbook, или перевели описание API из Confluence в генерацию из кода, потому что вики отставала от релизов. Если документации почти не было, так и скажите и расскажите, как восстанавливали картину по коду, тестам и истории коммитов.

Тот же вопрос полезно задать и работодателю в конце собеседования: ответ многое говорит о зрелости команды и о том, каким будет ваш онбординг.

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

Отвечают «да, была» и замолкают. Интервьюеру важно, какая она и кто её поддерживал.

Называют Springfox для Swagger в современном проекте. Он давно не развивается и не поддерживает Spring Boot 3, стандартом стал springdoc.

Ругают прежнюю команду за отсутствие документации, не сказав, что сделали сами. Это звучит как жалоба, а не как опыт.