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

О чём эта статья

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

Собеседование на эту роль охватывает широкий спектр тем: от требований и BPMN-моделирования до SQL, REST API и архитектурных паттернов. Junior-у достаточно понимать основы, от Middle ждут глубины в нескольких областях, Senior должен демонстрировать системное мышление на уровне архитектуры предприятия.

Что в этом гайде:

• Карта компетенций — что спрашивают на Junior, Middle и Senior
• 7 тематических блоков — вопросы с ответами и ссылками на подробные материалы
• Репозитории и внешние ресурсы — где брать реальные вопросы и задачи
• Типичные ошибки — что нельзя говорить на собеседовании
• Чек-лист подготовки — что повторить за 2 недели, 3 дня и 1 час до собеседования

На каждый вопрос даётся не просто ответ, а ссылка на статью из Кладовочки, где тема разобрана подробно. Материал основан на реальном опыте прохождения собеседований, планах развития аналитиков уровня Middle/Senior (Хабр), шпаргалке по требованиям и гайде по System Design Interview.

Для кого: Junior — основы требований, SQL, BPMN, REST. Middle — Use Cases, BRD/SRS, проектирование API, оптимизация SQL. Senior — System Design, DDD, архитектура предприятия, управление изменениями. Каждый уровень найдёт свой блок — см. карту компетенций ниже.

Ключевые понятия

Карта компетенций системного аналитика

Что спрашивают на каждом уровне — сводная таблица на основе реальных требований из вакансий и опыта собеседований:

Блок 1: Требования и анализ

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

Виды требований

Бизнес-требования (Business Requirements) — отвечают на вопрос «зачем?». Формализуются в документе BRD (Business Requirements Document). Пример: «Сократить время обработки заявки с 3 дней до 4 часов».

Функциональные требования (Functional Requirements) — «что система должна делать?». Документируются в SRS (Software Requirements Specification) или FRD. Пример: «Система должна отправлять уведомление на email после изменения статуса заявки».

Нефункциональные требования (Non-Functional Requirements) — «как система должна это делать?». Модель FURPS+:

• Functionality — функциональная пригодность
• Usability — юзабилити, доступность интерфейса
• Reliability — надёжность, отказоустойчивость
• Performance — производительность, время отклика
• Supportability — сопровождаемость, масштабируемость
• + — безопасность, локализация, регуляторные требования

Типичный вопрос: «Опишите нефункциональные требования для интернет-банка». Ожидается: время ответа API (p95 < 200 мс), доступность (99,9%), безопасность (шифрование, аудит), масштабирование под пиковые нагрузки.

Use Cases и User Stories: когда что применять

Типичный вопрос: «Опишите Use Case для возврата товара в интернет-магазине». Ожидается:

• Precondition: заказ доставлен, не прошло 14 дней
• Trigger: пользователь нажимает «Оформить возврат»
• Main flow: выбор товара → указание причины → генерация трек-номера → инструкция по отправке
• Extensions: товар повреждён (фото), частичный возврат, возврат денег vs баллы

Подробнее: гайд по написанию Use Cases.

Критерии приёмки (Acceptance Criteria)

Формат Given-When-Then:

Given: пользователь авторизован и имеет активный заказ
When: пользователь нажимает «Повторить заказ»
Then: создаётся новый заказ с теми же позициями, применяются актуальные цены

14 критериев качества требований (по Мейеру): Correct, Justified, Complete, Consistent, Unambiguous, Feasible, Abstract, Traceable, Delimited, Readable, Modifiable, Verifiable, Prioritized, Endorsed. На собеседовании достаточно знать 5–7 ключевых и уметь применить их к примеру требования.

Типичные ошибки в требованиях

На основе «Топ-10 ловушек» (IBM, перевод Шамрая А.В.) — вот ключевые, которые всплывают на собеседованиях:

Ловушка 1: Расползание границ (scope creep). Добавление фич без пересмотра бюджета и сроков. Избегать: фиксировать бизнес-требования в BRD, явно указывать исключения (G.6 Limitations and exclusions).

Ловушка 2: Спрашивать заказчика «чего вы хотите». Заказчики склонны говорить о фичах, а не о потребностях. Избегать: спрашивать «какой результат вы ожидаете?», уводить обсуждение от конкретных решений к проблемам.

Ловушка 3: Неспособность адаптироваться к изменениям. Замороженные требования → нерелевантный продукт. Избегать: планировать итеративные уточнения, приоритизировать требования (critical/important/nice-to-have).

Ловушка 4: Плохая коммуникация. Разработчики и бизнес говорят на разных языках. Избегать: глоссарий (единый для всех), визуализация (диаграммы понятнее текста), адаптация формата под аудиторию.

Ловушка 7: Неоднозначность (ambiguity). Расплывчатые формулировки типа «быстрый отклик», «удобный интерфейс», «и т.д.». Избегать: метрики вместо субъективных оценок, исключать «etc.» из спецификаций.

Подробнее обо всех критериях качества — в справочнике аналитика по требованиям.

Документы: BRD, SRS, FRD

Типичный вопрос: «Вам нужно описать требования к мобильному приложению — какой документ вы выберете?» Правильный ответ: SRS (или FRD в зависимости от принятой в компании классификации) + обоснование, почему не BRD.

Блок 2: Моделирование и нотации

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

BPMN 2.0: ключевые элементы

Типичный вопрос: «Опишите процесс оформления кредита в BPMN». Ожидаемые элементы: заявка → проверка скоринга (XOR-шлюз: одобрено/отказ) → для одобренных: выбор условий → подписание договора.

UML: диаграммы для аналитика

Диаграмма вариантов использования (Use Case Diagram):

Актёр (человечек) ──── Use Case (овал)

Показывает кто и что делает с системой, но не как. Базовый инструмент для обсуждения границ системы с заказчиком.

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

Клиент → API Gateway → Сервис заказов → База данных

Показывает обмен сообщениями во времени. Незаменима при проектировании API-интеграций.

Диаграмма активностей (Activity Diagram): Близка к BPMN, но больше ориентирована на системные процессы, чем на бизнес. Полезна для описания алгоритмов.

ERD: модель сущность-связь

База: сущность (прямоугольник) → атрибуты → связи (1:1, 1:M, M:N). Нотация «воронья лапка» (crow's foot) — стандарт де-факто.

Типичный вопрос: «Спроектируйте схему БД для интернет-магазина». Ожидаемые сущности: User, Product, Category, Order, OrderItem. Связи: Order 1:M OrderItem, Product M:1 Category.

DFD: потоки данных

Процесс (круг/прямоугольник со скруглением) → поток данных (стрелка) → хранилище (две линии) → внешняя сущность (прямоугольник). Применяется реже BPMN/UML, но удобна для описания движения данных между системами.

Ссылки: C4 Model — архитектурные диаграммы, ключевые концепты архитектуры.

Блок 3: SQL и данные

SQL — обязательный навык. На собеседовании могут дать как устный вопрос, так и live-кодинг.

База: что обязаны знать

-- JOIN: INNER, LEFT, RIGHT, FULL
SELECT o.id, u.name
FROM orders o JOIN users u ON o.user_id = u.id;

-- GROUP BY + HAVING
SELECT user_id, COUNT(*) as cnt
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;

-- Подзапросы
SELECT name FROM users
WHERE id IN (SELECT user_id FROM orders WHERE amount > 1000);

Оконные функции и CTE

-- Оконная функция: ранг по сумме заказов
SELECT user_id,
       SUM(amount) as total,
       RANK() OVER (ORDER BY SUM(amount) DESC) as rank
FROM orders GROUP BY user_id;

-- CTE (Common Table Expression)
WITH user_totals AS (
    SELECT user_id, SUM(amount) as total
    FROM orders GROUP BY user_id
)
SELECT * FROM user_totals WHERE total > 5000;

Оптимизация и индексы

Типичный вопрос: «Запрос к таблице с 10 млн записей выполняется 30 секунд. Ваши действия?»

• EXPLAIN SELECT ... — смотрим план выполнения
• Проверяем индексы: есть ли индекс на полях из WHERE/JOIN
• Seq Scan (полное сканирование) на большой таблице — красный флаг
• Проверяем JOIN-порядок, убираем лишние JOIN
• Рассматриваем партиционирование, материализованные представления для отчётов

Примеры задач с собеседований

Задача 1: «Найти пользователей, сделавших заказ в каждом месяце 2024 года».

SELECT user_id FROM orders
WHERE order_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY user_id
HAVING COUNT(DISTINCT EXTRACT(MONTH FROM order_date)) = 12;

Задача 2: «Вывести второй по величине оклад в каждом отделе».

SELECT DISTINCT department, salary FROM (
    SELECT department, salary,
           DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rnk
    FROM employees
) ranked WHERE rnk = 2;

Ссылки: SQL-шпаргалка для начинающих, продвинутый SQL.

Блок 4: API и интеграции

REST API: база

Коды ответов:

• 2xx — успех: 200 OK, 201 Created, 204 No Content
• 3xx — перенаправление: 301/302
• 4xx — ошибка клиента: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable Entity
• 5xx — ошибка сервера: 500 Internal, 502 Bad Gateway, 503 Service Unavailable

Типичный вопрос: «Спроектируйте REST API для библиотеки книг». Ожидаемые эндпоинты:

• GET /books — список с пагинацией и фильтрами
• GET /books/{id} — детали книги
• POST /books — добавить книгу
• POST /books/{id}/borrow — взять книгу
• GET /users/{id}/borrowed — книги на руках у пользователя

OpenAPI / Swagger

На собеседовании могут попросить «прочитать» Swagger-документацию и ответить на вопросы по ней. Или спроектировать спецификацию для простого эндпоинта. Основные поля: paths, parameters, requestBody, responses, schemas.

Форматы: JSON, XML

• JSON: легковесный, нативный для JS, стандарт де-факто для REST API
• XML: самодокументируемый через XSD-схемы, строгая типизация, используется в SOAP и гос. системах

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

Типичный вопрос: «Чем отличается очередь (point-to-point) от топика (pub-sub)?» В очереди сообщение получает один потребитель и удаляется. В топике сообщение получают все подписчики и оно сохраняется.

Ссылки: FastAPI шпаргалка.

Блок 5: Архитектура

Базовые архитектурные стили

Оркестрация vs Хореография

• Оркестрация: центральный координатор управляет потоком (например, Camunda, Conductor). Плюс: полный контроль. Минус: единая точка отказа.
• Хореография: сервисы обмениваются событиями без центрального управляющего. Плюс: независимость. Минус: сложнее отследить сквозной процесс.

Типичный вопрос: «Спроектируйте систему заказа такси». Примерный поток:

1. Пользователь → указывает адреса, тариф
2. Сервис заказов → ищет ближайших водителей (geo-index)
3. Матчинг → отправляет предложение водителям (push/poll)
4. Водитель принимает → обновление статуса, трекинг через WebSocket
5. Завершение поездки → расчёт стоимости, списание, рейтинг

Масштабирование и отказоустойчивость

Горизонтальное масштабирование: добавление новых экземпляров сервиса. Вертикальное: увеличение ресурсов одного сервера. Вопросы на собеседовании: репликация БД, шардирование, кэширование (Redis), балансировка нагрузки, Circuit Breaker.

System Design: подход к задачам

Из методологии Тинькофф (Александр Поломодов):

1. Формализация задачи — уточнить требования: нагрузка (DAU, RPS), функциональные и нефункциональные требования, ограничения.
2. Границы системы — что внутри, что снаружи? Чётко определить API системы.
3. Основной поток — happy path: какие компоненты задействованы, через что проходит запрос.
4. Концептуальная схема — Architecture Building Blocks (ABB): какие типы компонентов нужны.
5. Реальная схема — Solution Building Blocks (SBB): конкретные технологии (PostgreSQL, Redis, Kafka, S3).
6. Масштабирование — как схема выдерживает нагрузку, где узкие места.
7. Читаемость — схема должна быть понятна без автора.

Ссылки: архитектурные концепты, роли архитектора, C4 Model.

Блок 6: Процессы и методологии

Agile / Scrum / Kanban

Waterfall: когда применяется

Каскадная модель не умерла — она применяется там, где требования фиксированы и изменения дороги:

• Гос. контракты (ГОСТ 34)
• Строительство, промышленность (переделка невозможна)
• Медицинские/авиационные системы (сертификация)

Жизненный цикл требований

Сбор → Анализ и приоритизация → Согласование → Моделирование → Ревью → Управление изменениями → Тестирование.

Ключевое: требования — живой артефакт, а не «написал и забыл». Даже в Agile нужен минимальный upfront (G.1/G.3/G.7, S.1/S.2, E.3 по Мейеру).

CI/CD и контроль версий

Базовое понимание: Git (commit, branch, merge, pull request), пайплайны CI/CD (автоматическая сборка, тесты, деплой). Аналитик работает с кодом документации в репозитории.

Блок 7: Soft skills и кейсы

Как решать конфликты с заказчиком

Типичный кейс: «Заказчик требует функционал, который технически нереализуем в заданные сроки. Ваши действия?»

1. Не говорить «нет» сразу — выяснить, какую проблему решает фича
2. Предложить альтернативу (другой способ достичь цели)
3. Декомпозировать: что можно сделать сейчас, а что — в следующей версии
4. Оцифровать стоимость: «это добавит 3 недели и сдвинет запуск MVP»
5. Эскалировать, если договориться не удалось

Приоритизация требований

Техники:

• MoSCoW: Must have / Should have / Could have / Won't have
• Virtual budget: стейкхолдеры распределяют $100 между требованиями
• Kano-модель: базовые (обязательные) / линейные (чем больше, тем лучше) / восхищающие
• Матрица важность × срочность (Eisenhower)

Коммуникация с разработчиками

Правила эффективного взаимодействия:

• Глоссарий — единые термины. «Сущность» в БД ≠ «сущность» в DDD.
• Диаграмма > текст — одна Sequence Diagram заменяет 5 страниц описания API.
• Acceptance Criteria — Given-When-Then для каждого требования. Разработчик должен понимать, когда считать задачу сделанной.
• «Почему», а не «как» — аналитик описывает ЧТО, разработчик решает КАК.

Типичные кейсы на собеседовании

Кейс 1: «В середине спринта заказчик просит срочную фичу. Как поступите?» → Оценить влияние на текущие задачи, предложить замену (swap) вместо добавления, обсудить с PO. Не брать «сверх спринта» без формального решения.

Кейс 2: «Разработчик говорит, что требование невозможно реализовать. Ваши действия?» → Выяснить причину (техническое ограничение? сроки? неоднозначность?). Уточнить требование, декомпозировать, согласовать компромисс с заказчиком.

Кейс 3: «Два стейкхолдера требуют противоречащих друг другу изменений.» → Зафиксировать оба требования, оценить влияние на цели (G.3), провести общую встречу с визуализацией конфликта, приоритизировать по бизнес-ценности.

Репозитории и внешние ресурсы

GitHub и подборки вопросов

• The System Design Primer — карта тем для System Design + практические задачи
• getanalyst.ru/interview — подборка вопросов по темам (gist.github.com/val1141)
• Architectural Katas — архитектурные задачи от Нила Форда (без ответов, но с примерами)
• Hacking the Software Engineer Interview — теория + практика System Design

Хабр-статьи

• «Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills» — 13 блоков компетенций
• «System Design Interview в Тинькофф» — критерии оценки и методология
• Топ-150 вопросов системному аналитику — обширная подборка

Книги

Обязательные к прочтению:

• Карл Вигерс, Джой Битти — «Разработка требований к программному обеспечению» (Software Requirements, 3-е изд.) — настольная книга аналитика.
• Алистер Коберн — «Современные методы описания функциональных требований к системам» (Writing Effective Use Cases) — Use Cases от создателя методологии.
• Bertrand Meyer — «Handbook of Requirements and Business Analysis» (Springer, 2022) — академический фундамент: PEGS-модель, 14 критериев качества, Standard Plan.

Для System Design:

• Martin Kleppmann — «Designing Data-Intensive Applications» (DDIA) — как работают распределённые системы «на пальцах».
• Alex Xu — «System Design Interview» (vol. 1–2) — практические задачи с решениями.

Частые ошибки

Чек-лист подготовки

За 2 недели до собеседования

• Повторить виды требований (бизнес/функциональные/нефункциональные), FURPS+
• Освежить SQL: JOIN, GROUP BY, оконные функции, EXPLAIN, индексы
• Пройти 3–5 задач на проектирование API (спроектируйте REST API для X)
• Посмотреть 1–2 System Design-разбора (url shortener, чат, такси)
• Повторить BPMN 2.0: задачи, шлюзы, события, пулы
• Перечитать INVEST-критерии и формат Given-When-Then

За 3 дня до собеседования

• Подготовить ответ на «Расскажите о самом сложном проекте» — с акцентом на вашу роль, проблему и решение
• Прорешать 3–5 кейсов («заказчик просит невозможное», «меняются требования»)
• Пройтись по списку типичных ошибок (см. таблицу выше)
• Подготовить вопросы к компании — это показывает вашу вовлечённость:
  • «Как у вас устроен процесс работы с требованиями?»
  • «Какие нотации используете для моделирования?»
  • «Как происходит онбординг аналитика в проект?»

За 1 час до собеседования

• Открыть шпаргалку по SQL (основные JOIN-ы, GROUP BY + HAVING)
• Вспомнить структуру ответа на System Design-задачу (формализация → границы → поток → концептуальная схема → масштабирование)
• Проверить, что камера/микрофон работают

Что дальше

Все ключевые статьи сайта, релевантные подготовке системного аналитика:

• Справочник аналитика: требования к ПО — полный гайд по требованиям: PEGS, критерии качества, техники сбора, ГОСТ 34
• Гайд по написанию Use Cases — структура, примеры, лучшие практики
• Как писать ТЗ: шаблоны, ГОСТы, этапы — практическое руководство по техническому заданию
• SQL-шпаргалка для начинающих — SELECT, JOIN, GROUP BY, подзапросы
• Продвинутый SQL — оконные функции, CTE, оптимизация
• C4 Model: архитектурные диаграммы — уровни контекста, контейнеров, компонентов и кода
• Ключевые концепты архитектуры — виды архитектур, паттерны, масштабирование
• Архитектурные роли в IT — Solution, Enterprise, System Architect
• FastAPI шпаргалка — проектирование REST API
• Scrum, Kanban, Waterfall: сравнение методологий — когда и что применять