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

Короткий ответ: как готовиться к системному интервью

Подготовьте один сквозной сценарий: потребность → функциональные и нефункциональные требования → состояния и данные → API → ошибки и повторы → критерии приёмки. На каждом шаге называйте допущение и вопрос владельцу. Синтаксис HTTP или SQL без этой цепочки не показывает, сможет ли команда реализовать требование одинаково.

Удобный учебный сценарий — уведомление об изменении статуса рейса. В нём есть пользователь, источник события, идентификатор рейса, доставка сообщения, ошибка сети и повтор запроса. Можно показать BPMN для процесса согласования, UML sequence для обмена сервисов и ER-модель для хранимых сущностей. Не рисуйте всё подряд: выбирайте артефакт под вопрос.

Этапы отбора отличаются между компаниями. Часто кандидат сначала обсуждает опыт, затем разбирает требования или интеграцию и отвечает на технические уточнения. Иногда дают небольшое тестовое. Подготовьте и историю о реальном рабочем решении, и синтетический кейс, который можно решать без закрытых материалов прошлой работы.

Двенадцать вопросов: что проверяют и как отвечать

Таблица — тренировка, а не список «правильных фраз». Прочитайте вопрос, произнесите свой ответ вслух и проверьте, есть ли в нём объект, граница, ошибка и способ проверить результат. Слабые ответы специально похожи на то, что легко сказать на автомате; сильные показывают ход мысли и открытые вопросы.

Функциональные, нефункциональные требования и ограничения

Функциональное требование отвечает на вопрос, что система делает при конкретном входе: «При новом подтверждённом изменении статуса рейса создать задачу доставки уведомления пассажиру с активным билетом». Но здесь ещё нужно договориться, что значит «новое», какие статусы значимы и как определяется право на контакт. Без этих уточнений два разработчика могут реализовать разные вещи.

Нефункциональное требование задаёт качество или ограничение решения: допустимую задержку, доступность, порядок аудита, объём нагрузки и права доступа. Не выдумывайте обещание «за пять секунд» на интервью, если заказчик его не назвал. Скажите, что измерите текущий поток, предложите проверяемую цель и согласуете её с владельцем. Важно отделить бизнесовое ожидание от технической гипотезы.

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

User story, use case и критерии приёмки: не смешивайте

User story компактно объясняет ценность: «Как пассажир, я хочу узнать об отмене своего рейса, чтобы изменить поездку». Она не раскрывает все ветки. Use case полезен, когда нужно перечислить акторов, предусловия, основной поток и альтернативы: контакт отсутствует, уведомление запрещено, событие пришло дважды, сервис доставки недоступен. Критерии приёмки делают конкретную ветку проверяемой.

Пример: дан существующий flight_id, активный билет, разрешённый канал и новый event_id; когда интеграция получает событие Cancelled, тогда создаётся одна задача доставки. При повторе того же event_id новая задача не создаётся, а клиент получает определённый контрактом прежний результат. Для неизвестного flight_id или конфликтного event_id с другим содержимым поведение нужно описать отдельно.

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

BPMN, UML sequence и ER-модель: какую выбрать

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

На доске можно начать с обычных прямоугольников и стрелок, обозначив, что это упрощённый эскиз. Не называйте любой поток «BPMN», если не соблюдаете смысл событий, задач и шлюзов. Покажите, какой вопрос снимает каждая диаграмма. На собеседовании чаще ценнее объяснить развилку, чем продемонстрировать полный набор значков.

В нашем кейсе процессная схема говорит: «новое событие → проверка права на контакт → попытка доставки → обработка отказа». Sequence добавляет границу транзакции и ответ API. ER-модель показывает, как event_id связан с flight_id и попытками доставки. Эти артефакты вместе делают спецификацию проверяемой.

Практический кейс: спроектировать интеграцию статусов

Условие синтетическое: система расписания публикует изменение статуса конкретного вылета; сервис уведомлений должен создать задание на отправку пассажиру при разрешённом канале. Сначала уточните, кто источник истины по статусу, как выглядит уникальный идентификатор события, может ли событие прийти не по порядку и нужен ли ответ о фактической доставке или только о принятии. Затем проверьте, какие данные уже существуют, а какие нужно проектировать.

В учебной базе есть flight_id и flight_no. Первый обозначает конкретный вылет, второй — номер рейса, который повторяется между датами. Мы выполнили запрос ко всем рейсам: 33 121 строка и только 710 разных flight_no; один номер встречается до 61 раза. Поэтому flight_no без даты не может быть ключом события. Для API выбираем flight_id, а при переносе в реальную систему подтверждаем его стабильность и область уникальности контрактом источника.

Сценарий на уровне сообщений: источник отправляет event_id, flight_id, status, occurred_at; API проверяет формат и права; база сохраняет событие и задачу доставки атомарно; работник отправляет сообщение и фиксирует попытку. Повтор с тем же event_id и тем же содержимым не создаёт вторую задачу. Событие с тем же id и иным содержимым — конфликт, требующий разбора. Поведение при старом occurred_at нужно согласовать, а не угадывать.

Источник → API: событие(event_id, flight_id, status, occurred_at)
API → БД: проверить event_id и flight_id, сохранить событие + задачу
БД → API: новый / повтор / конфликт
API → Источник: результат по контракту
Работник → БД: забрать задачу, записать попытку
Работник → Сервис доставки: отправить сообщение
Сервис доставки → Работник: подтверждение или ошибка
Работник → БД: состояние попытки и следующая дата повтора

Контракт API: вход, ответ, ошибки

Для учебного решения достаточно описать один метод и явно назвать предположения. POST создаёт ресурс события, потому что клиент сообщает о новом изменении. В запросе нет персональных контактов: по flight_id и билетам сервис ищет разрешённые адреса внутри защищённого контура. Это проектное решение для синтетического кейса, не описание существующего API учебной базы.

Для нового event_id и валидного flight_id мы проектируем ответ 201 с идентификатором события. Повтор с тем же телом получает 200 и ссылку на прежний результат; тот же id с изменённым телом — 409 по нашему контракту. Неверный JSON и отсутствующее обязательное поле — 400, неизвестный flight_id — 404, временный сбой сервиса — 5xx с возможностью безопасного повтора. Точные коды обсуждаются с командой и фиксируются в OpenAPI; важна согласованность, а не универсальность этой таблицы.

Покажите пример входа и ограничения схемы: event_id обязателен, status — из согласованного набора, occurred_at — время события с часовой зоной, flight_id — целое положительное. JSON Schema различает свойство, которое может присутствовать, и свойство из списка required; написать properties без required недостаточно для контракта.

В контракте разделите синтаксис и поведение. JSON Schema с обязательным полем позволяет отвергнуть запрос без идентификатора, но не объяснит, допустим ли переход из «отменён» в «завершён». Правило перехода должно быть отдельно записано и покрыто примером ошибки. Укажите, кто выдаёт внешний идентификатор, как долго хранится ключ повтора и какой ответ получает клиент, если сервер уже выполнил действие, но ответ потерялся. В этом месте интервьюер видит, понимаете ли вы различие между описанием объекта и гарантиями процесса.

POST /v1/flight-status-events
Content-Type: application/json

{
  "event_id": "evt-001",
  "flight_id": 18452,
  "status": "Cancelled",
  "occurred_at": "2026-08-05T09:15:00+03:00"
}

Идемпотентность, порядок событий и очередь

Идемпотентность означает, что повтор одной операции не должен создавать новое бизнес-действие. Сам HTTP POST не даёт такой гарантии автоматически. Мы добавляем уникальный event_id, храним отпечаток содержимого и прежний результат. Если подтверждение ответа потерялось, клиент может повторить запрос: сервер обнаружит событие и не отправит пассажиру второе сообщение. Но «однократная доставка человеку» остаётся отдельной задачей: внешний канал может подтвердить отправку не сразу.

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

Очередь отделяет быстрый приём события от доставки. Она не устраняет ошибки: сообщение может быть обработано повторно, застрять или попасть в очередь ошибок. Нужны журнал попыток, лимит повторов, наблюдение и способ безопасно переиграть событие. Не обещайте «exactly once» одним словом: на собеседовании объясните, что именно будет уникально в базе и как поведёт себя внешний сервис.

Если источник присылает события асинхронно, возможны повтор, задержка и изменение порядка. Одной очереди недостаточно для гарантии корректного состояния. В учебном решении храните идентификатор события и версию объекта, применяйте только допустимый переход, а обработку повторного события делайте безопасной. Если версия 8 пришла до версии 7, нужно определить политику: запросить актуальное состояние, подождать или пометить конфликт для разбора. Не обещайте автоматическое исправление без знания поведения источника.

На собеседовании полезно назвать журнал аудита и наблюдаемость: какой запрос и событие вызвали переход, какой код ответа отдали, где видно неуспешную попытку и кто получит сигнал. Если описать только счастливый путь, разработчик и тестировщик будут по-разному интерпретировать ошибку. Это вопрос качества требований, а не только эксплуатации.

Модель данных: ключи и кардинальность

Минимум для учебного проекта: flights с первичным flight_id; status_events с уникальным event_id и внешним flight_id; notification_attempts с ключом попытки, event_id, каналом, состоянием и временем. Если один event_id адресован многим пассажирам, между событием и попытками нужен уровень notification_jobs с ключом получателя и канала. Здесь мы не храним реальные контакты из учебной базы и не утверждаем, что такая структура уже существует.

Назовите кардинальность вслух: один рейс может иметь много событий статуса, одно событие — много заданий доставки, одно задание — много попыток. Уникальность event_id не заменяет проверку повторной отправки для каждого получателя. Если статус корректируется, история событий нужна для аудита; перезапись единственной строки стирает причину и порядок.

Из модели сразу получаются проверки: не бывает события без flight_id, в таблице попыток нет ссылки на отсутствующее задание, повтор id не меняет тело события. Ключи в схеме предотвращают часть ошибок, но не решают бизнесовое правило «достаточно ли одной доставки».

SQL-задачи на учебной базе: проверить ключ и фан-аут

Первая авторская задача: можно ли использовать flight_no как уникальный ключ вылета? Запрос ко всей учебной таблице даёт 33 121 рейс, 710 разных номеров и максимум 61 использование одного номера. На одном дне, 5 августа, 548 строк и 548 разных номеров — локальная уникальность маскирует проблему. Сильный ответ показывает оба среза и выбирает flight_id; слабый смотрит один день и объявляет flight_no первичным ключом.

Вторая задача: проверить уникальность пары ticket_no, flight_id в boarding_passes. Группировка с HAVING count(*) > 1 даёт ноль дублей в текущем срезе. Это поддерживает ожидание модели данных, но не заменяет ограничение уникальности в будущей системе. Третья: после LEFT JOIN рейсов 5 августа с посадочными талонами получается 22 189 строк вместо 548 рейсов, из них 22 024 строки с талоном. COUNT(*) после такого JOIN не считает рейсы. Сильный кандидат считает distinct flight_id или сначала агрегирует талоны по рейсу.

Четвёртая задача — базовое окно: пронумеровать вылеты внутри каждого flight_no по времени и flight_id. Максимальный ROW_NUMBER() равен 61; значит один номер используется в 61 строке. Оконная функция сохраняет строки и добавляет порядковый номер, в отличие от GROUP BY, который сворачивает группу. В интеграции такое окно годится для диагностики повторов, но не делает номер рейса ключом. Сортировка включает flight_id, чтобы результат оставался определённым при одинаковом времени.

Это не те же задачи, что подборка SQL на собеседовании: их цель — найти ключ и кардинальность для интеграционного контракта. Все запросы выполнены скриптом в исследовательской папке волны; в рабочей системе сначала проверяйте фактические ограничения и версию данных.

SELECT count(*) AS flight_rows,
       count(DISTINCT flight_no) AS flight_numbers
FROM flights;

WITH numbered AS (
  SELECT flight_no,
         row_number() OVER (
           PARTITION BY flight_no
           ORDER BY scheduled_departure, flight_id
         ) AS occurrence
  FROM flights
)
SELECT max(occurrence) AS max_occurrence FROM numbered;
-- 61

Документация, которую смогут реализовать и проверить

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

Свяжите требование с проверкой. Для правила «повтор не создаёт дубль» добавьте тест: два одинаковых POST с одним event_id, одна запись события, одна задача, второй ответ отражает уже созданное. Для правила «неизвестный рейс отвергается» — вход с отсутствующим flight_id и отсутствие побочных записей. Нефункциональная цель, например задержка, требует способа измерения и условий нагрузки.

На интервью покажите, как вы передадите команде не только идеальный путь, но и вопросы, которые ещё не решены: порядок событий, согласие на контакт, правила ретраев. Нельзя честно «закрыть» эти пункты красивой диаграммой без владельца решения.

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

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

Пять ошибок кандидата, которые меняют поведение системы

Первая: считать номер рейса уникальным без даты — события разных вылетов смешаются. Вторая: написать «уведомление отправляется» без различия между принятой задачей и подтверждённой доставкой — поддержка не поймёт, что обещано пользователю. Третья: дать один ответ 500 на ошибки валидации, отсутствующий рейс и временный сбой — клиент будет бесполезно повторять неправильный запрос.

Четвёртая: забыть повтор запроса после потери ответа — пассажир получит дубль. Пятая: рисовать BPMN вместо определения данных и контракта — разработка сама додумает порядок и права. Шестая: проверить SQL на десяти строках, не заметив размножения после JOIN — спецификация будет опираться на неверный объём. У каждой ошибки есть конкретное последствие, поэтому на собеседовании говорите о нём, а не просто перечисляйте термины.

Хороший способ самопроверки: представьте, что завтра другой разработчик и тестировщик получат только ваш документ. Смогут ли они одинаково ответить, что делать с дублем, неизвестным рейсом, старым событием и отказом отправки? Если нет — ещё остались требования, а не «мелкие детали реализации».

План подготовки на две недели

Дни 1–3: возьмите знакомый процесс и выпишите цель, акторов, функциональные и нефункциональные требования, открытые вопросы. Дни 4–5: опишите основной и альтернативный use case, критерии приёмки. Дни 6–7: нарисуйте процесс и последовательность сообщений, найдите места, где диаграммы расходятся.

Дни 8–9: напишите один API-контракт с корректными входами и ошибками, затем повторите запрос и проверьте идемпотентность на бумаге. Дни 10–11: разберите ключи и связи учебной базы, выполните три SQL-проверки выше. Дни 12–13: отдайте спецификацию человеку, который не слышал постановку, и запишите вопросы, на которые он не может ответить. День 14: короткое пробное интервью с таймером: уточнение, модель, ошибки, проверка.

• Всегда названо зерно сущности и ключ.
• У каждого требования есть владелец и проверяемый пример.
• Повтор, ошибка и недоступность описаны явно.
• Схема процесса, API и SQL говорят об одном сценарии.

Частые вопросы

Что спрашивают на собеседовании системного аналитика? Обычно обсуждают требования, моделирование процесса и данных, API, интеграции, ошибки, SQL и коммуникацию. Конкретный набор зависит от продукта и уровня; готовьте сквозной кейс, а не только определения.

Нужно ли системному аналитику знать SQL? Полезно уметь читать схему, проверять ключи, JOIN и агрегаты. Глубина зависит от роли, но без понимания кардинальности трудно спроектировать корректный контракт данных.

Чем бизнес-аналитик отличается от системного на интервью? У первого сильнее проверяют потребность, стейкхолдеров и эффект процесса; у второго — однозначность поведения системы, данных и интеграций. В компаниях граница может быть иной.

Как отвечать, если не знаете конкретный HTTP-код? Скажите, какие случаи нужно различить и как проверили бы семантику по стандарту и контракту команды. Уверенно назвать неверный код хуже открытой проверки.

Что делать дальше

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

Для SQL-части можно тренироваться на том же наборе данных в курсе. Для общей карты профессий вернитесь к хабу и проверьте, соответствует ли ожидаемый артефакт вашей вакансии.