Насколько вы погружены в бизнес-процессы и архитектуру
Что проверяют
Уровень самостоятельности. Джун закрывает тикет, инженер понимает, зачем тикет нужен и что сломается у соседей. Вопрос отделяет тех, кто может описать реальный контур системы и связать техническое решение с ограничением бизнеса, от тех, кто знает только свой класс и свой сервис.
Как отвечать
Опишите конкретную систему, в которой работали, а не абстрактные принципы. Полезный каркас ответа:
- домен и пользователь: что делает система и кто за неё платит;
- границы вашего сервиса: кто ваши апстримы и даунстримы, что вы отдаёте и с каким SLA;
- способ взаимодействия: синхронный вызов по REST или gRPC против события в Kafka, и почему выбрано именно это;
- данные: где граница транзакции, как гарантируется согласованность между записью в базу и отправкой события, как накатываются миграции;
- операционка: что происходит при недоступности соседа, есть ли ретраи и идемпотентность у консьюмера.
Дальше один пример решения, принятого из-за бизнес-ограничения: например, отказ от синхронного вызова в пользу очереди, потому что внешняя система не держала нагрузку, а пользователю достаточно было отложенного результата.
Где спотыкаются
Ставят в один ряд вещи разного масштаба и называют всё паттернами: MVC это способ разложить слои внутри приложения, а микросервисы это решение про границы развёртывания и владения данными. Смешение сразу показывает, что архитектуру человек не проектировал.
Второе: вместо архитектуры перечисляют стек. Spring Boot, Hibernate и Kafka есть у половины кандидатов, это не ответ на вопрос о том, как устроена система.
Третье: под «погружением в бизнес» понимают пересказ задач из трекера. Если на вопрос, кто конечный пользователь и какой бизнес-показатель ухудшится при падении сервиса, ответа нет, погружения нет тоже.