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