Опишите архитектуру проекта
Что проверяют
Владеете ли вы системой целиком или только своим тикетом. Вопрос открытый, без подсказок, и половина оценки это структура рассказа: сумеете ли дать обзор за пару минут, а потом углубиться туда, куда попросят.
Как отвечать
Начните с одного предложения о том, что система делает и для кого. Дальше масштаб: сколько запросов, какой объём данных, требования к отклику и доступности. Без этого любая архитектура выглядит одинаково.
Затем форма: монолит, модульный монолит или набор сервисов, и почему именно так. Потом устройство вашего куска: слой контроллеров, сервисный слой, доступ к данным. Для Java полезно проговорить вещи, которые видно только изнутри:
- где проходит граница транзакции и почему она на сервисном слое, а не в контроллере;
- работа с базой: ORM или явный SQL, где от ORM отказались и по какой причине;
- как накатываются миграции схемы и как выкатывается несовместимое изменение;
- что закэшировано и чем этот кэш инвалидируется;
- что делают фоновые задачи и как они не запускаются дважды на нескольких экземплярах.
Закончите компромиссом: какое решение сегодня выглядит спорным и что бы вы поменяли. Часто именно ради этого ответа вопрос и задают.
Где спотыкаются
Отвечают списком технологий. Перечень фреймворка, базы и брокера не содержит ни одного решения и ни одной причины, а спрашивают про выбор и его цену.
Второе: знают свой сервис и не знают соседей. На вопрос, что происходит с запросом до вашего контроллера и куда уходит ответ, наступает пауза, и дальше разговор идёт как с исполнителем чужих задач.
Третье: проваливаются в детали кода: имена классов, структура пакетов, аннотации. Уровень рассказа теряется, слушателю не за что зацепиться. Держите обзор сверху и спускайтесь вглубь только по просьбе.