Вопросы на собеседовании системному аналитику

Требования

1. Какие бывают виды требований?

   Бизнес-требования — зачем проект нужен бизнесу. Пользовательские — что пользователь хочет сделать с помощью системы. Функциональные — что именно делает система. Нефункциональные — с какими характеристиками: скорость, надёжность, безопасность. Отдельно фиксируют ограничения (стек, законы, сроки) и бизнес-правила.

2. Каким должно быть хорошее требование?

   Однозначным, проверяемым, полным, непротиворечивым, атомарным, реализуемым и трассируемым — связанным с источником и с задачами. «Список заказов должен открываться быстро» не проверить; «список из 50 заказов открывается не дольше 2 секунд при 500 одновременных пользователях» — можно (цифры условные).

3. Как вы выявляете требования?

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

4. Чем use case отличается от user story?

   Use case — сценарий взаимодействия актора с системой: предусловия, основной поток, альтернативные потоки и исключения, постусловия. User story — короткая формулировка ценности «Как <роль>, я хочу <действие>, чтобы <польза>» плюс критерии приёмки, а детали уточняют с командой. Story удобна для бэклога, use case — когда важна полнота сценариев. Хорошая story отвечает INVEST: независимая, обсуждаемая, ценная, оцениваемая, небольшая, тестируемая.

5. Что такое критерии приёмки?

   Проверяемые условия, при которых задача считается выполненной. Часто их пишут в формате Given / When / Then: дано — в корзине есть товар; когда — пользователь нажимает «Оформить»; тогда — создаётся заказ в статусе «Новый». По ним тестировщик пишет проверки, а заказчик принимает работу.

6. Какие нефункциональные требования вы знаете?

   Производительность (время отклика, пропускная способность), доступность, масштабируемость, надёжность и восстановление (RPO — сколько данных допустимо потерять, RTO — за сколько нужно восстановиться), безопасность, совместимость, удобство, аудит и логирование. Без чисел они не проверяемы, поэтому значения всегда уточняют у заказчика.

Моделирование: BPMN и UML

7. Какие основные элементы BPMN?

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

8. Чем отличаются исключающий, параллельный и включающий шлюзы?

   Исключающий (XOR, пустой ромб или ромб с крестом) пускает процесс ровно по одной ветке по условию. Параллельный (AND, ромб с плюсом) запускает все ветки сразу, а при слиянии ждёт завершения всех. Включающий (OR, ромб с кругом) — по одной или нескольким веткам, условия которых выполнились.

9. Какие диаграммы UML вы используете?

   Чаще всего: последовательности — кто кого вызывает в интеграции; активности — алгоритм с ветвлениями и параллельными шагами; состояний — жизненный цикл сущности, например статусы заказа; вариантов использования — акторы и их сценарии; классов — модель данных (для таблиц БД чаще рисуют ER-диаграмму). Реже — компонентов и развёртывания.

10. Что показывает диаграмма последовательности?

    Участников — вертикальные линии жизни, и сообщения между ними — стрелки сверху вниз во времени. Синхронный вызов — сплошная линия с закрашенным наконечником, ответ — пунктир, асинхронное сообщение — сплошная линия с открытым наконечником. Фрагменты alt, opt, loop, par показывают условия, необязательные шаги, циклы и параллельность.

11. Когда рисовать BPMN, а когда диаграмму активности?

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

REST, форматы данных и интеграции

12. Что такое REST?

    Архитектурный стиль для API поверх HTTP: данные — ресурсы со своими адресами (/orders/42), действия — стандартные методы, сервер не хранит состояние клиента между запросами, ответы можно кэшировать. В URL — существительное, действие выражает метод, а не адрес вроде /getOrder.

13. Чем отличаются GET, POST, PUT, PATCH и DELETE? Что такое идемпотентность?

    GET читает и не меняет данные, POST создаёт ресурс или запускает действие, PUT заменяет ресурс целиком, PATCH меняет частично, DELETE удаляет. Идемпотентный метод при повторе даёт то же состояние, что и при одном вызове: GET, PUT и DELETE идемпотентны, POST — нет, PATCH — не обязательно.

14. Какие коды ответа HTTP нужно знать?

    2xx — успех: 200 OK, 201 Created, 204 No Content. 3xx — перенаправления. 4xx — ошибка клиента: 400 — некорректный запрос, 401 — не аутентифицирован, 403 — нет прав, 404 — не найдено, 409 — конфликт, 422 — не прошла валидация, 429 — слишком много запросов. 5xx — ошибка сервера: 500, 502, 503, 504.

15. Чем JSON отличается от XML?

    JSON — объекты и массивы с типами строка, число, логическое значение и null; он компактный и стандартный для REST. XML — теги и атрибуты, пространства имён, строгая схема XSD; на нём построен SOAP, и он по-прежнему встречается в банковских и государственных интеграциях. Структуру JSON описывают JSON Schema или OpenAPI.

16. Синхронная или асинхронная интеграция — как выбрать?

    Синхронная (REST, gRPC, SOAP): вызывающий ждёт ответа — просто и подходит, когда результат нужен сразу, но если получатель недоступен, запрос падает. Асинхронная, через брокер сообщений: отправитель кладёт сообщение и идёт дальше — система устойчивее к сбоям и пикам, но данные согласуются не мгновенно, и нужно продумать повторы, дубли и порядок сообщений.

17. Чем Kafka отличается от RabbitMQ?

    RabbitMQ — брокер очередей: сообщение через exchange попадает в очередь и после подтверждения обработки удаляется. Kafka — распределённый журнал: сообщения пишутся в топики с партициями и хранятся заданное время, потребители читают по смещению (offset) и могут перечитать. Порядок в Kafka гарантирован только внутри партиции.

18. Что такое at-least-once и почему потребитель должен быть идемпотентным?

    At-most-once — сообщение может потеряться, но не придёт дважды; at-least-once — не потеряется, но может прийти повторно; exactly-once — ровно один раз, это сложно и дорого. Самый распространённый вариант — at-least-once, поэтому получатель должен спокойно переживать дубли: хранить ID обработанных сообщений или делать операции идемпотентными.

SQL и базы данных

19. Что такое нормализация?

    Приведение структуры БД к виду без избыточности и аномалий при изменении. 1НФ — атомарные значения, нет повторяющихся групп; 2НФ — неключевые поля зависят от всего составного ключа, а не от его части; 3НФ — неключевые поля не зависят от других неключевых. Денормализация — осознанное дублирование ради скорости чтения, например в отчётных витринах.

20. Какие бывают связи между таблицами?

    Один к одному (сотрудник — его пропуск), один ко многим (клиент — заказы: внешний ключ client_id в таблице заказов), многие ко многим (заказы — товары: через связующую таблицу позиций заказа с двумя внешними ключами). Первичный ключ однозначно определяет строку, внешний ссылается на первичный ключ другой таблицы.

21. Какие SQL-запросы могут попросить написать?

    Выборку с фильтром и сортировкой, JOIN двух-трёх таблиц, агрегаты с GROUP BY и HAVING, поиск записей без пары через LEFT JOIN … WHERE … IS NULL, иногда оконные функции. Разбор типовых вопросов и задач — в подборке вопросов по SQL.

22. Что такое индекс и когда он не помогает?

    Структура, обычно B-дерево, которая ускоряет поиск и сортировку по колонке. За это платят местом и более медленными вставкой и обновлением. Индекс мало помогает, если условию подходит большая часть таблицы, если колонка в условии обёрнута в функцию и при поиске LIKE '%текст'.

23. Реляционная база или NoSQL?

    Реляционная — когда важны связи, транзакции и строгая схема: заказы, платежи, учёт. Документные хранилища — для гибкой структуры данных, key-value — для кэша и сессий, для аналитики по большим объёмам берут колоночные СУБД. Выбор объясняют через требования: согласованность, нагрузку, характер запросов.

Проектирование API

24. Как спроектировать REST API для ресурса?

    Ресурс во множественном числе и стандартные методы: GET /orders — список с фильтрами и пагинацией в query-параметрах, GET /orders/{id}, POST /orders, PATCH /orders/{id}, DELETE /orders/{id}. Плюс версия (/v1/), единый формат ошибок, коды ответа, аутентификация и описание контракта в OpenAPI.

25. Offset или курсор: как делать пагинацию?

    limit и offset — просто и можно перейти на любую страницу, но глубокие страницы работают медленно, а при вставке новых записей элементы съезжают между страницами. Курсорная пагинация (?after=<id последней записи>) стабильна и быстра для лент и больших списков, но не даёт прыгнуть на произвольную страницу.

26. Как сделать создание заказа идемпотентным?

    Клиент генерирует уникальный ключ и передаёт его в заголовке, например Idempotency-Key. Сервер запоминает ключ вместе с результатом и на повторный запрос с тем же ключом возвращает сохранённый ответ, не создавая второй заказ. Это важно для платежей и мобильных клиентов с нестабильной сетью.

27. Чем аутентификация отличается от авторизации?

    Аутентификация — проверка, кто вы: пароль, токен, сертификат. Авторизация — проверка, что вам разрешено. Отсюда разница кодов: 401 — аутентифицировать не удалось, 403 — пользователь известен, но прав нет. В API для этого обычно используют OAuth 2.0 и токены, например JWT.

Кейс: постановка задачи

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

1. Цель и стейкхолдеры. Зачем это бизнесу (например, меньше звонков в поддержку), кто заказчик, кто пользователи, по какому признаку поймём, что задача решена.
2. Сценарии. Какие статусы вызывают уведомление, по каким каналам — push, SMS, email, — можно ли отписаться, что делать, если контакта нет или канал недоступен.
3. Интеграции. Сервис заказов публикует событие смены статуса в брокер, сервис уведомлений читает его, выбирает шаблон и отправляет через провайдера. Это удобно показать диаграммой последовательности.
4. Данные и контракт. Формат события: ID заказа, новый статус, время, ID самого события для защиты от дублей. Шаблоны сообщений и журнал отправок.
5. Нефункциональные требования. Допустимая задержка доставки, пиковый объём, повторы при сбоях провайдера, хранение персональных данных, логирование.
6. Критерии приёмки. Проверяемые условия на каждый сценарий, включая ошибочные.

Интервьюер оценивает не идеальную архитектуру, а то, задаёте ли вы уточняющие вопросы и не забываете ли про ошибки и нефункциональные требования. Если вы идёте в аналитику данных, а не в системный анализ, загляните в подборку вопросов для аналитика: SQL и метрики. План подготовки по дням — в материале «Как подготовиться к собеседованию».

Как отрепетировать ответы

Большую часть собеседования системный аналитик рассуждает вслух: уточняет, раскладывает задачу на шаги, объясняет выбор. Проговорите кейс выше с таймером, а потом придумайте свой и разберите его так же. Почувствовать темп живого интервью поможет бесплатное трёхминутное демо «Первый звонок» в Суфлер AI: ИИ-интервьюер Анна задаёт теоретический вопрос, даёт задачу на live coding и код-ревью, а приложение показывает 2–3 тезиса ответа в окне, которого не видно при демонстрации экрана. Подробнее — на странице скрытого помощника на собеседовании.