Участвовали ли в проработке архитектуры решения
Что проверяют
Понимаете ли вы, где заканчивается зона аналитика и начинается зона архитектора, и умеете ли говорить про интеграции, данные и ограничения. Вопрос отделяет тех, кто описывает экраны, от тех, кто описывает систему.
Как отвечать
Сформулируйте роль честно: аналитик отвечает за требования, ограничения и контракты, а не за выбор фреймворка и базы. Дальше перечислите, что делали руками.
Нефункциональные требования: ожидаемая нагрузка и профиль пиков, допустимое время отклика, доступность, объём и срок хранения данных, требования к персональным данным и аудиту. Именно они задают форму решения, и именно их чаще всего не собирают.
Данные и процессы: сущности и их атрибуты, справочники, источник истины для каждого поля, процессы до и после изменения.
Интеграции: кто инициатор обмена, синхронно или асинхронно, формат, частота, что считается ошибкой, что происходит при недоступности смежной системы, нужна ли идемпотентность и повтор, как сверяются расхождения. Это самая частая зона ответственности аналитика в архитектуре.
Назовите нотации, которыми пользуетесь: BPMN для процессов, диаграмма последовательности для обмена сообщениями, ER для данных, уровни контекста и контейнеров для общей картины. И упомяните фиксацию решений в виде записей с причиной и рассмотренными альтернативами.
Где спотыкаются
Приписывают себе чужие решения: «я выбрал микросервисную архитектуру». Уточняющий вопрос про границы сервисов и про то, как разделили данные между ними, обычно остаётся без ответа.
Говорят только про функциональные требования. Без нагрузки, доступности и объёмов данных обсуждать архитектуру невозможно, и отсутствие этой части сразу заметно.
Приносят красивые цифры из ниоткуда: система держала десять тысяч запросов в минуту. Вопрос о том, чем нагружали и на каком профиле данных, показывает, что цифра услышана, а не измерена.