Кто занимается архитектурой и техническим описанием задач

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

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

Как отвечать

Опишите реальное распределение ролей и свою долю в нём:

• архитектор или техлид: выбирает границы сервисов, способ взаимодействия (HTTP, gRPC, очередь), общие подходы вроде Clean Architecture или вертикальных срезов;
• разработчик: пишет техническое описание своей задачи, то есть какие проекты решения затронуты, какие эндпоинты и DTO появятся, какая миграция EF Core нужна, как обрабатываются ошибки;
• ревью дизайна: описание смотрит техлид или вся команда до начала кода, а не после.

Назовите артефакты. Для крупных решений это ADR, короткий документ с контекстом, выбором и последствиями. Для схем нередко берут модель C4. Для API подходит контракт OpenAPI, который в ASP.NET Core генерируется из кода или пишется заранее. Хорошо звучит конкретика: «перед задачей на новый платёжный провайдер я расписал интерфейс адаптера, повторы через Polly и идемпотентность по ключу запроса, техлид поправил схему ретраев».

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

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

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

Говорят «архитектуру делал архитектор, я писал код». Звучит как признание, что вы не понимаете, почему система устроена именно так.

Называют архитектурой выбор между List и Dictionary. Архитектура это решения, которые дорого менять: границы модулей, хранилища, протоколы.

Не могут объяснить ни одного своего технического решения с альтернативами. Без сравнения вариантов рассказ выглядит заученным.