3 апреля 2026 г.

Собеседование на системного аналитика

Чем занимается системный аналитик

Системный аналитик проектирует техническую сторону решений. Если бизнес-аналитик отвечает на вопрос «что нужно бизнесу», то системный аналитик — на вопрос «как это реализовать технически». Он описывает API, проектирует схемы данных, рисует диаграммы взаимодействия компонентов и пишет технические спецификации, по которым разработчики могут писать код без догадок.

На практике работа системного аналитика включает три основных направления:

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

Моделирование данных и процессов. Схемы базы данных, ER-диаграммы, sequence-диаграммы, state-диаграммы. Системный аналитик визуализирует, как данные перемещаются между системами и как меняется состояние объектов.

Техническая документация. Спецификации требований к системе (SRS), описания интеграций, API-документация. Документ системного аналитика — это не абстрактное ТЗ, а конкретное техническое описание с примерами запросов, кодами ошибок и ограничениями.

Чем отличается от бизнес-аналитика

Этот вопрос задают на каждом втором собеседовании. Главное различие — уровень абстракции.

Бизнес-аналитик работает с потребностями бизнеса: собирает требования, описывает пользовательские сценарии, моделирует бизнес-процессы. Его артефакты — user stories, BRD, диаграммы BPMN.

Системный аналитик берёт эти требования и переводит их в технические решения: API-контракты, схемы данных, диаграммы взаимодействия компонентов. Его артефакты — спецификации API, ER-диаграммы, sequence-диаграммы, описания интеграций.

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

Этапы собеседования

Типичный процесс для системного аналитика — 3–4 этапа:

1. HR-скрининг. Мотивация, ожидания, общее понимание роли. Могут спросить: «Чем системный аналитик отличается от бизнес-аналитика?», «С какими интеграциями вы работали?», «Какой стек технологий знаете?»

2. Техническое интервью. Основной этап — 60–90 минут. Вопросы по REST API, HTTP, SQL, UML, интеграциям. Могут дать задачу: спроектировать API для фичи, описать взаимодействие между сервисами, нарисовать sequence-диаграмму. Здесь же проверяют SQL — от базовых запросов до JOIN и агрегаций.

3. Кейс-интервью. Реальная бизнес-задача, которую нужно разобрать технически: декомпозировать на компоненты, определить контракты, описать потоки данных. Оценивают не знание конкретных технологий, а умение думать системно.

4. Финальное интервью. Разговор с руководителем или командой. Оценивают способность объяснять сложные вещи простым языком, задавать правильные вопросы, работать в их контексте.

REST API и HTTP

Это ядро технического интервью системного аналитика. Знание REST — не опция, а обязательное требование.

HTTP-методы

На собеседовании ожидают, что вы знаете семантику каждого метода и можете объяснить, когда какой использовать:

  • GET — получение ресурса. Идемпотентный, без тела запроса. GET /api/orders/123 — получить заказ.
  • POST — создание ресурса. Не идемпотентный. POST /api/orders — создать новый заказ.
  • PUT — полная замена ресурса. Идемпотентный. PUT /api/orders/123 — заменить заказ целиком.
  • PATCH — частичное обновление. PATCH /api/orders/123 — обновить отдельные поля заказа.
  • DELETE — удаление. Идемпотентный. DELETE /api/orders/123 — удалить заказ.

Частый вопрос: «Чем PUT отличается от PATCH?» PUT заменяет ресурс целиком — если вы не передали поле, оно обнулится. PATCH обновляет только переданные поля. На практике многие API используют PUT как PATCH — но на собеседовании нужно знать разницу по спецификации.

Ещё один частый вопрос: «Что значит идемпотентность?» Метод идемпотентен, если повторный вызов с теми же параметрами даёт тот же результат. GET, PUT, DELETE — идемпотентны. POST — нет: два одинаковых POST создадут два ресурса.

Коды ответов HTTP

Минимум, который нужно знать:

  • 200 OK — успешный запрос.
  • 201 Created — ресурс создан (ответ на POST).
  • 204 No Content — успешно, но тело ответа пустое (часто на DELETE).
  • 400 Bad Request — ошибка в запросе клиента (невалидные данные, пропущенные поля).
  • 401 Unauthorized — не передан или невалидный токен авторизации.
  • 403 Forbidden — авторизация пройдена, но прав недостаточно.
  • 404 Not Found — ресурс не найден.
  • 409 Conflict — конфликт состояний (например, попытка создать дубликат).
  • 422 Unprocessable Entity — запрос синтаксически корректен, но семантически невалиден.
  • 500 Internal Server Error — необработанная ошибка на сервере.
  • 502 Bad Gateway — проксирующий сервер получил некорректный ответ от upstream.
  • 503 Service Unavailable — сервис временно недоступен.

Вас могут попросить: «Какой код вернёте, если пользователь пытается отменить заказ, который уже доставлен?» Здесь подходит 409 Conflict — запрос корректный, авторизация пройдена, но текущее состояние ресурса не допускает эту операцию.

REST vs SOAP

Могут спросить, чем REST отличается от SOAP. REST — архитектурный стиль, работает поверх HTTP, использует JSON (иногда XML). SOAP — протокол, использует XML, работает поверх разных транспортов (HTTP, SMTP, TCP), имеет строгую схему (WSDL) и встроенную обработку ошибок. REST проще, легче, популярнее для новых проектов. SOAP до сих пор живёт в банковских системах, госсервисах и enterprise-интеграциях, где критичны транзакционность и формальные контракты.

SQL

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

На собеседовании обычно проверяют:

  • SELECT, WHERE, GROUP BY, HAVING, ORDER BY
  • JOIN — INNER, LEFT, RIGHT и понимание, когда использовать какой
  • Агрегатные функции: COUNT, SUM, AVG, MAX, MIN
  • Подзапросы и CTE
  • Базовое понимание индексов

Типичная задача: «Есть таблицы users (user_id, name, created_at) и orders (order_id, user_id, amount, status, created_at). Найдите пользователей, у которых нет ни одного заказа».

SELECT u.user_id, u.name
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
WHERE o.order_id IS NULL

Или то же самое через NOT EXISTS:

SELECT user_id, name
FROM users u
WHERE NOT EXISTS (
    SELECT 1
    FROM orders o
    WHERE o.user_id = u.user_id
)

На собеседовании системного аналитика SQL-задачи часто связаны с проверкой данных и интеграциями: «Найдите заказы, которые есть в нашей системе, но отсутствуют во внешней», «Проверьте, что все пользователи из CRM синхронизированы с биллингом». Подробнее — в разделе SQL.

UML и диаграммы

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

Sequence diagram (диаграмма последовательности)

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

Пример: пользователь создаёт заказ. Sequence diagram покажет:

  1. Клиент отправляет POST /api/orders в API Gateway.
  2. API Gateway проверяет токен через Auth Service.
  3. Auth Service возвращает OK.
  4. API Gateway отправляет запрос в Order Service.
  5. Order Service записывает заказ в базу данных.
  6. Order Service отправляет событие в очередь (Kafka/RabbitMQ).
  7. Notification Service получает событие и отправляет push.

На собеседовании могут попросить нарисовать такую диаграмму от руки или описать словами. Важно показать не только happy path, но и обработку ошибок: что произойдёт, если Auth Service вернул 401, если база данных недоступна, если очередь переполнена.

ER-диаграмма (Entity-Relationship)

Описывает структуру данных: сущности, их атрибуты и связи. Могут попросить спроектировать схему для конкретной задачи: «Нарисуйте ER-диаграмму для системы бронирования». Здесь важно правильно определить сущности (User, Booking, Room, Payment), связи (один-ко-многим, многие-ко-многим) и ключевые атрибуты.

State diagram (диаграмма состояний)

Показывает жизненный цикл объекта: какие состояния он проходит и какие события вызывают переходы. Классический пример — статусы заказа: Created -> Paid -> Processing -> Shipped -> Delivered. Плюс альтернативные переходы: Created -> Cancelled, Shipped -> Returned.

На собеседовании могут попросить описать все возможные статусы и переходы для конкретной сущности. Частая ошибка — забыть про крайние случаи: может ли заказ вернуться из Shipped в Processing? Что происходит при частичном возврате?

Интеграционные паттерны

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

Синхронная интеграция (запрос-ответ). Клиент отправляет запрос и ждёт ответа. REST API — типичный пример. Просто в реализации, но создаёт связанность: если один сервис упал, второй не может продолжить работу.

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

Webhook. Механизм обратного вызова: одна система регистрирует URL, и другая система отправляет HTTP-запрос на этот URL при наступлении события. Используется, когда внешняя система должна уведомить вашу о событии — например, платёжный провайдер сообщает о завершении платежа.

Частый вопрос на собеседовании: «Когда вы выберете синхронную интеграцию, а когда асинхронную?» Если результат нужен прямо сейчас для ответа пользователю — синхронная. Если можно обработать позже и важнее отказоустойчивость — асинхронная.

Примеры кейсов

Кейс 1: спроектировать API для фичи

«В мобильном приложении нужно добавить функционал "Избранное" — пользователь может добавлять товары в список и просматривать его. Опишите API».

Ожидаемый ход решения:

  1. Определить ресурс и эндпоинты.

    • POST /api/users/{user_id}/favorites — добавить товар в избранное. Тело: { "product_id": 456 }. Ответ: 201 Created.
    • GET /api/users/{user_id}/favorites — получить список избранного. Ответ: 200 OK, массив товаров с пагинацией.
    • DELETE /api/users/{user_id}/favorites/{product_id} — удалить из избранного. Ответ: 204 No Content.

  2. Описать формат ответа.

    {
  "items": [
    {
      "product_id": 456,
      "name": "Товар",
      "price": 1990,
      "added_at": "2026-04-01T12:00:00Z"
    }
  ],
  "total": 42,
  "page": 1,
  "per_page": 20
}

  3. Обработка ошибок. Повторное добавление — 409 Conflict. Несуществующий товар — 404. Превышен лимит избранного (если есть) — 422.

  4. Дополнительные вопросы. Нужна ли сортировка? Фильтрация по категории? Нужно ли возвращать признак «в избранном» на карточке товара в общем каталоге?

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

Кейс 2: описать интеграцию

«Нужно интегрировать вашу систему с внешним сервисом SMS-рассылок. Как будете проектировать?»

Здесь системный аналитик должен описать:

  • Протокол и формат. REST API, JSON. Аутентификация — API-ключ в заголовке.
  • Основной сценарий. Наша система отправляет POST с телефоном и текстом. SMS-сервис возвращает идентификатор отправки и статус.
  • Получение статуса. Два варианта — polling (мы периодически запрашиваем статус) или webhook (SMS-сервис вызывает наш URL при изменении статуса). Webhook предпочтительнее — меньше нагрузка, быстрее обратная связь.
  • Обработка ошибок. Таймаут, невалидный номер, лимит исчерпан, сервис недоступен. Для каждого случая — стратегия: retry с экспоненциальной задержкой, fallback на другого провайдера, запись в dead letter queue.
  • Идемпотентность. Если наш запрос ушёл, но ответ потерялся — повторная отправка не должна привести к дублированию SMS. Решение: передавать уникальный idempotency_key в каждом запросе.
  • Мониторинг. Логирование всех запросов и ответов, алерт при росте ошибок, дашборд со статистикой доставки.

Инструменты системного аналитика

Swagger / OpenAPI. Стандарт описания REST API. Системный аналитик пишет спецификацию в формате OpenAPI (YAML или JSON), и из неё автоматически генерируется интерактивная документация. На собеседовании могут спросить, чем OpenAPI 3.0 отличается от Swagger 2.0, или попросить описать эндпоинт в формате OpenAPI.

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

PlantUML / Draw.io / Miro. Инструменты для диаграмм. PlantUML — текстовый формат, удобен для version control и code review. Draw.io — визуальный редактор, подходит для быстрых схем. Miro — для совместной работы с командой. Достаточно уверенно владеть одним инструментом.

SQL-клиент (DBeaver, DataGrip). Для работы с базами данных напрямую: проверка структуры, анализ данных, валидация интеграций.

Git. Системный аналитик хранит спецификации в репозитории вместе с кодом. Базовое знание Git (коммиты, ветки, pull requests) — ожидаемый навык.

Частые ошибки на собеседовании

Описывать API без обработки ошибок. Кандидат проектирует только happy path: запрос ушёл, ответ пришёл, все довольны. А интервьюер ждёт, что вы подумаете: что вернёте при невалидных данных, как обработаете дубликат, что произойдёт при таймауте. Обработка ошибок — это половина спецификации.

Путать авторизацию и аутентификацию. Аутентификация — проверка, кто вы (логин/пароль, токен). Авторизация — проверка, что вам разрешено делать (роли, права). На собеседовании это спрашивают часто и ожидают чёткого ответа.

Не думать об идемпотентности. Если сеть нестабильна и клиент повторяет запрос — что произойдёт? Создастся два заказа? Спишутся деньги дважды? Системный аналитик должен учитывать это при проектировании API.

Рисовать диаграммы без объяснения. Диаграмма сама по себе не ответ. Важно проговаривать: почему выбрали эту структуру, какие альтернативы рассматривали, где потенциальные проблемы. Интервьюер оценивает ход мысли, а не красоту стрелок.

Игнорировать нефункциональные требования. Спроектировали API, забыли про нагрузку, время ответа, лимиты, кеширование. Для системного аналитика нефункциональные требования не менее важны, чем функциональные.

Как готовиться

Разберитесь в REST до автоматизма. HTTP-методы, коды ответов, заголовки, идемпотентность, версионирование API. Это спрашивают всегда. Попробуйте спроектировать API для нескольких знакомых продуктов — интернет-магазин, мессенджер, сервис бронирования.

Подтяните SQL. Системному аналитику нужен уверенный средний уровень: JOIN, GROUP BY, подзапросы, CTE. Задачи на собеседовании часто связаны с проверкой данных и интеграциями, а не с аналитикой. Подробнее — в разделе SQL.

Научитесь рисовать sequence-диаграммы. Возьмите любой процесс (оплата, регистрация, отправка уведомления) и нарисуйте взаимодействие между компонентами. Добавьте обработку ошибок. Попробуйте PlantUML — он дисциплинирует: описание текстом не даёт схалтурить.

Изучите основы интеграционных паттернов. Синхронная vs асинхронная интеграция, очереди сообщений, webhook, API Gateway, идемпотентность. Не нужно знать детали реализации Kafka — нужно понимать, когда и зачем она используется.

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

Разберитесь в домене компании. Если идёте в финтех — почитайте про PCI DSS, платёжные протоколы, двухфакторную аутентификацию. Если в e-commerce — про процессы заказа, склад, логистику. Доменные знания показывают мотивацию и ускоряют вход в роль.

FAQ

Нужно ли системному аналитику уметь программировать?

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

Сколько времени нужно на подготовку?

Если у вас есть опыт в IT (разработка, тестирование, аналитика) — 2–3 недели. Ключевые темы: REST API, SQL, UML-диаграммы, интеграционные паттерны. Если переходите из нетехнической роли — 6–8 недель, с упором на технические основы: HTTP, JSON, базы данных, основы архитектуры.

Чем системный аналитик отличается от архитектора?

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

Потренируйтесь решать задачи для аналитиков в Карьернике — тренажёре для подготовки к собеседованиям.

Тренироваться в Telegram