Собеседование на системного аналитика: вопросы, ответы и разбор

Сильный ответ

На проекте нужно было связать CRM и систему биллинга через REST API. Я описала эндпоинты, формат JSON-запросов, коды ошибок и логику повторных попыток при таймауте. Отдельно прописала, что происходит при рассинхронизации данных: кто источник истины, как откатываться. Согласовала документ с бэкендом и тестировщиками до начала разработки, это сняло часть вопросов на этапе код-ревью.

Сильный ответ

Функциональное требование в моем проекте: система должна формировать отчёт по остаткам на складе раз в сутки. Нефункциональное к нему: отчёт должен формироваться не дольше 5 минут при объёме в миллион записей. Я всегда фиксирую нефункциональные требования отдельным пунктом, иначе разработчик оптимизирует не то, что критично для бизнеса.

Сильный ответ

Я бы сделала LEFT JOIN таблицы клиентов с таблицей заказов по условию, что дата заказа больше указанной границы, и отобрала строки, где после джойна заказ отсутствует, то есть значение NULL. Либо через NOT EXISTS с подзапросом по заказам за период. Второй вариант обычно быстрее на больших объёмах, я проверяю через EXPLAIN, какой план выполнения эффективнее.

Сильный ответ

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

Сильный ответ

Для описания бизнес-процессов использую BPMN, потому что она понятна заказчику без технической подготовки. Для проектирования структуры данных строю ER-диаграммы. Диаграммы последовательности UML применяю, когда нужно показать разработчикам порядок вызовов между сервисами при сложном сценарии, например при отмене заказа с откатом в трёх системах.

Сильный ответ

В спецификации фиксирую метод, URL, формат тела запроса и ответа с примерами, обязательные и опциональные поля, коды ошибок с расшифровкой причин, ограничения по частоте запросов, если они есть, и версию API. Отдельно прописываю сценарии edge case, например что возвращает система, если объект уже удалён другим процессом.

Сильный ответ

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

Сильный ответ

Я формулирую критерии приёмки ещё на этапе постановки задачи, обычно в формате Given-When-Then. Когда функциональность готова, прохожусь по критериям вместе с QA, проверяю пограничные случаи, которые могли не попасть в тест-кейсы. Если нахожу расхождение с требованием, фиксирую это до того, как задача уйдёт в релиз.

Сильный ответ

Основной опыт с PostgreSQL, работала с таблицами на десятки миллионов строк, где важно было продумывать индексы под конкретные отчётные запросы. Также участвовала в проекте, где часть данных хранилась в MongoDB из-за неструктурированных логов, и приходилось описывать, как эти данные синхронизируются с реляционной частью системы.

Сильный ответ

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

Сильный ответ

Такое случается, особенно когда заказчик на старте сам не до конца понимал детали процесса. Я сразу разбираюсь, в чём именно расхождение, обсуждаю с разработчиком, что можно исправить малой кровью, а что требует пересмотра логики. Обновляю документацию и сообщаю всем участникам об изменении, чтобы это не повторилось на смежных задачах.