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

Проверь себя · 1/3разбор после ответа

В таблице sessions 5 строк. Значения utm_source: 'google', NULL, 'email', NULL, NULL. Чему равны COUNT(*) и COUNT(utm_source)?

Что спрашивают на собесе системного аналитика

Собеседование системного аналитика стоит на стыке бизнес-анализа и инженерии. От кандидата не ждут, что он напишет production-код, но ждут, что он переведёт расплывчатое «хотим, чтобы пользователь мог оплатить заказ» в техническое задание, которое разработчик возьмёт в работу без десятка уточняющих вопросов. Поэтому вопросы на собесе крутятся вокруг одного навыка: умения формализовать неопределённость и описать систему так, чтобы её можно было собрать и проверить.

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

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

Нотации: BPMN и UML. Системный аналитик описывает процессы и поведение системы графически, чтобы убрать двусмысленность из текста. Спрашивают BPMN (потоки процессов, шлюзы, события), UML (use case, sequence, диаграммы классов и состояний), иногда C4 для архитектуры. Важно не вызубрить значки, а понимать, какую диаграмму выбрать под задачу и что именно она проясняет для команды.

API: REST, SOAP, gRPC. Аналитик проектирует контракты взаимодействия между сервисами. Разбирают принципы REST, семантику HTTP-методов и кодов ответа, отличия REST от SOAP и gRPC, версионирование и обратную совместимость API. Нужно уметь описать эндпоинт: метод, путь, параметры, тело запроса и ответа, ошибки.

Базы данных и SQL. Глубина не как у дата-аналитика, но JOIN, GROUP BY, агрегаты, индексы и понимание нормализации — обязательны. Часто просят спроектировать схему под сценарий, объяснить выбор между реляционной БД и NoSQL, рассказать про транзакции, ACID и уровни изоляции.

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

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

Документация. Финальный артефакт работы аналитика — это документ. Спрашивают, как вы структурируете ТЗ, какие разделы включаете, как фиксируете архитектурные решения (например, через ADR) и как поддерживаете документацию в актуальном состоянии, когда требования меняются по ходу разработки.

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

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

Скрининг с рекрутером (20–30 минут). Разговор про опыт, грейд, доменную область, инструменты и ожидания по зарплате. Технических вопросов почти нет — задача рекрутера отсеять явное несоответствие вакансии и сверить мотивацию. Здесь важно коротко и внятно рассказать, какие системы вы описывали и какую роль играли в команде.

Техническая секция (60–90 минут). Самый весомый этап. В него обычно сворачивают архитектуру, проектирование API, работу с базами данных и SQL. Спрашивают про REST и контракты, микросервисы, протоколы взаимодействия, CAP, ACID, идемпотентность, нормализацию и индексы. Оценивают не количество выученных терминов, а способность объяснить trade-off: почему здесь синхронный вызов, а там очередь; почему CP, а не AP. Проговаривайте рассуждение вслух — половина оценки именно в ходе мысли.

Кейс на проектирование и требования (60–90 минут). Дают бизнес-сценарий — «спроектируй интеграцию оформления заказа с платёжным сервисом», «как обработать сбой одного из сервисов при оформлении» — и смотрят, как вы движетесь от требований к решению. Хороший кандидат сначала уточняет границы и неявные условия, затем формализует требования, рисует процесс и контракты, проговаривает крайние случаи и отказоустойчивость. Здесь же часто просят сформулировать критерии приёмки для спроектированного функционала.

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

Почему проваливают собеседование

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

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

Третья — заученные термины без trade-off. Кандидат бодро перечисляет «CAP, ACID, Saga», но не может объяснить, когда выбрать одно, а когда другое, и какой ценой. Системный аналитик существует ради компромиссов, поэтому ответ «всегда делаем strong consistency» хуже, чем честный разбор, где она нужна, а где избыточна. И последнее — забывают про крайние случаи: пустой ответ, дубль запроса, недоступность смежного сервиса, частичный сбой. Кандидат, который сам проговаривает эти случаи, выглядит сильнее того, кто описал только happy path.

Примеры вопросов с разбором

Попробуйте ответить сами, прежде чем читать разбор.

Чем требование отличается от ограничения? Требование описывает, что система должна делать (функциональное) или каким свойством обладать — скорость, надёжность, безопасность (нефункциональное). Ограничение — это рамка, в которой нельзя выходить за пределы: использовать только определённую СУБД, уложиться в legacy-протокол, соблюсти 152-ФЗ. Требование можно реализовать по-разному, ограничение сужает пространство решений.
Что входит в API-контракт? Контракт фиксирует, как два сервиса договариваются взаимодействовать: эндпоинты (метод и путь), формат запроса и ответа (структура полей, типы, обязательность), коды ошибок и их семантику, правила аутентификации, версионирование и гарантии обратной совместимости. Контракт — это обещание, на которое опирается клиент, поэтому ломать его молча нельзя.
Что такое идемпотентность и какие методы идемпотентны? Идемпотентный вызов при многократном повторении даёт тот же результат, что и единичный. GET, PUT, DELETE идемпотентны по семантике HTTP, POST обычно нет — он создаёт новую сущность на каждый вызов. Идемпотентность критична для retry-логики и платежей; обеспечивается через client-supplied ID, idempotency-key в заголовке или MERGE по ключу.
Что такое нормализация и до какой формы доводить? Нормализация убирает избыточность данных и аномалии вставки, обновления и удаления, разбивая данные по таблицам и связывая их ключами. На практике обычно доводят до третьей нормальной формы: каждый неключевой атрибут зависит от ключа, всего ключа и только от ключа. Денормализуют осознанно ради скорости чтения, понимая, чем платят — рисками рассинхрона.
Как описать критерии приёмки? Через проверяемые условия, чаще в формате Given-When-Then: «Given пользователь с подтверждённой почтой, When он запрашивает сброс пароля, Then письмо с одноразовой ссылкой приходит в течение 30 секунд». Хорошие критерии однозначны, тестируемы и покрывают не только успешный путь, но и ошибки и граничные случаи.
REST vs gRPC — когда что выбрать? REST — текстовый протокол поверх HTTP, человекочитаемый, удобен для публичных и партнёрских API, где важна простота интеграции для любого клиента. gRPC — бинарный, на Protocol Buffers, строго типизирован и быстрее, поэтому его берут для внутренних вызовов сервис-к-сервису под высокой нагрузкой. Выбор — про аудиторию API и требования к скорости, а не про «что новее».
Что такое CAP-теорема и как применять? В распределённой системе при сетевом разделении нельзя одновременно гарантировать согласованность (Consistency) и доступность (Availability) — приходится выбирать. Partition tolerance практически обязательна, потому что сети ненадёжны. Для банковских операций выбирают CP — лучше отказать, чем показать неверный баланс; для ленты соцсети обычно AP — лучше показать слегка устаревшие данные, чем недоступность.
2PC vs Saga — что выбрать для распределённой транзакции? Two-phase commit даёт атомарность через координатора и сильную согласованность, но блокирует ресурсы и плохо масштабируется. Saga — цепочка локальных транзакций с компенсирующими действиями на откат, она не блокирует и устойчивее, но даёт eventual consistency и сложнее в проектировании. В современных микросервисах чаще берут Saga, осознавая, что согласованность станет отложенной.
Чем JSON отличается от XML и когда что использовать? JSON компактнее, проще читается и стал стандартом для REST и веб-интеграций. XML многословнее, но богаче на схемы (XSD), пространства имён и валидацию, поэтому встречается в SOAP, legacy-системах, банковских и государственных интеграциях, где строгая схема — требование. Выбор обычно диктует протокол и сторона, с которой вы интегрируетесь.
SQL или NoSQL — как выбрать под задачу? Реляционная БД подходит, когда данные структурированы, важны связи, транзакции и согласованность — финансы, заказы, учёт. NoSQL берут под слабоструктурированные данные, гибкую схему, горизонтальное масштабирование и высокую нагрузку на запись — логи, профили, кэш, ленты. Решает не мода, а характер данных, паттерны доступа и требования к согласованности.

Подробные разборы по подтемам

Архитектура и системный дизайн

API и контракты

Базы данных

Моделирование процессов

Безопасность

Гайды по компаниям

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

Доведите до автоматизма границы понятий. Функциональное против нефункционального требования, требование против ограничения, аутентификация против авторизации, идемпотентность против безопасности метода. Это первое, что проверяют, и именно здесь чаще всего плывут.
Тренируйте формализацию на сырых постановках. Берите расплывчатое пожелание и раскладывайте его на требования, критерии приёмки и крайние случаи. Навык важнее знания нотаций: умение задать правильный уточняющий вопрос ценится выше, чем красивая диаграмма.
Освойте API и интеграции на уровне проектирования. Уметь с нуля описать контракт эндпоинта, выбрать REST или gRPC под сценарий, объяснить идемпотентность и обработку ошибок при повторных вызовах — это ядро технической секции.
Подтяните SQL и базы данных. JOIN, GROUP BY, индексы, нормализация, транзакции и ACID — обязательный минимум, даже если вы не пишете запросы каждый день.
Практикуйтесь на коротких вопросах с разбором. На собесе проверяют понимание концепций, а не умение написать ТЗ на сорок страниц. Решайте много мелких задач с быстрым объяснением — так паттерны закрепляются лучше всего. Удобно гонять их в формате примеров вопросов: короткие вопросы с моментальным разбором.

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

Главная ошибка — молчать и сразу проектировать. Интервьюер хочет услышать, как вы уточняете границы, проговариваете неявные требования и сценарии ошибок, а не готовое решение под угаданную задачу. Вторая частая ошибка — переусложнять: тащить Saga и event sourcing туда, где хватает одной транзакции, лишь бы показать кругозор. Зрелость читается в обратном — в умении выбрать простое решение и объяснить, почему сложное здесь избыточно.

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

Другие темы

FAQ

Какие вопросы задают на собеседовании системного аналитика?

Чаще всего: сбор и формализация требований, отличие функциональных требований от нефункциональных и ограничений, нотации BPMN и UML, проектирование REST API и контрактов, идемпотентность, базы данных и SQL, нормализация, транзакции и ACID, форматы JSON и XML, критерии приёмки в формате Given-When-Then. На senior-уровне добавляются CAP, выбор между 2PC и Saga, отказоустойчивость.

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

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

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

Писать production-код обычно не требуется. Junior-аналитику желательно понимать базовый Python или JavaScript, middle и senior — уверенно читать код, понимать архитектуру и писать SQL. Главный навык — не программирование, а формализация требований и проектирование систем.

Сколько времени готовиться к собесу системного аналитика?

Зависит от старта. С нуля или из смежной роли — обычно 3–6 месяцев. Действующему аналитику для смены работы хватает 1–3 месяцев, чтобы освежить архитектуру, API и SQL и потренироваться на кейсах.

Какие нотации нужно знать — BPMN, UML, C4?

BPMN — must have для описания процессов. Из UML чаще всего нужны use case и sequence-диаграммы, реже — классы и состояния. C4 пригодится для архитектуры на собесах уровня middle и выше. Важнее не вызубрить нотацию, а понимать, какую диаграмму выбрать под задачу.

Насколько глубоко спрашивают SQL?

Не на уровне дата-аналитика, но базу проверяют почти всегда: JOIN, GROUP BY, агрегаты, подзапросы, индексы и нормализацию. Чаще просят спроектировать схему под сценарий и объяснить выбор, чем написать сложный запрос с оконными функциями.

Тренировать SA в Telegram