Пример использования диаграммы последовательности в работе
Что проверяют
Рисуете ли вы такие диаграммы в работе или знаете их только по учебнику. Ждут конкретный случай: какая была неясность, что диаграмма показала и какое решение приняли. Заодно смотрят, отличаете ли её от соседних нотаций.
Как отвечать
Возьмите задачу, где спорили про порядок и ответственность: интеграция с внешней системой, оформление заказа через несколько сервисов, вход через внешнего провайдера. Дальше по шагам: кто участники (пользователь, интерфейс, сервис, внешняя система, база), кто инициирует вызов, что синхронно, а что уходит в очередь, где таймаут и что происходит при ошибке.
Полезно показать, что владеете нотацией: ветвления через alt, необязательный шаг через opt, повтор через loop, отдельная стрелка для асинхронного сообщения, ответы пунктиром. Ценность не в красоте: диаграмма заставляет проговорить неуспешные сценарии и зафиксировать контракт, какие поля и коды ошибок ходят между участниками.
Отличие от соседних нотаций назовите сами: последовательность про порядок сообщений во времени между участниками, диаграмма активностей про шаги и ветвления одного процесса, BPMN про бизнес-процесс с исполнителями и событиями, ER про данные. Результат формулируйте проверяемо: нашли, что повтор платежа не идемпотентен, или что два сервиса ждут ответа друг от друга.
Где спотыкаются
Отвечают определением вместо примера. Вопрос про работу, поэтому нужны конкретная интеграция, участники и вывод, который изменил постановку задачи.
Рисуют только счастливый путь. Именно неуспешные ветки дают пользу: истёк таймаут, пришёл дубликат, внешняя система ответила ошибкой, а повтор создал второй заказ.
Не попадают в уровень детализации: для бизнеса рисуют вызовы методов, для разработчиков наоборот общие стрелки без контракта. И оставляют диаграмму картинкой, которая устаревает к следующему спринту, тогда как текстовый исходник в PlantUML или Mermaid правится вместе с документом.