Практическое задание было такое. В компании три тарификатора, каждый департамент писал свой на своём стеке. Нужна единая точка входа для всех событий тарификации.

Я открыл редактор и сразу нарисовал, как тарификаторы передают данные друг другу по цепочке. Мне так показалось по вводной в начале разговора.

Архитектор посмотрел на схему и спросил, откуда это понимание. Выяснилось, что тарификаторы друг от друга вообще не зависят. Схема, на которую я потратил первые минуты, описывала систему, которой нет.

Чуть позже я всё-таки спросил про зависимость прямо и получил ответ. Только время уже ушло, и до вопросов к бизнесу и разработчикам из задания я так и не дошёл.

Вопрос был по делу: всё решение дальше строилось бы на допущении, которое никто не проверил.

Теперь порядок у меня такой. Сначала рисую AS IS со слов собеседника: какие системы есть, кто кому что отправляет. Потом спрашиваю, правильно ли я понимаю. И только после этого рисую решение.

На работе с заказчиком то же самое, просто цена ошибки выше: неверную схему замечают позже.

А вы с чего начинаете, когда на собесе дают задачу на проектирование?