Вопросы и задачи для подготовки к собеседованию на позицию системного аналитика

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

Ошибка в постановке не чинится патчем. Она уходит в модель, код, тесты и интеграции. Поэтому ниже собраны вопросы и задачи именно для системного аналитика: требования, BPMN и UML, SQL, REST и документация.

Формулировки в компаниях разные. Важно не заучить чужой банк, а уметь уточнить AS-IS, назвать допущение и довести ответ до контракта, схемы или критерия приёмки.

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

Найм системного аналитика обычно не сводится к одному «техническому часу». Сначала рекрутер сверяет роль: продукт или интегратор, BPMN и SQL в вакансии, опыт с постановками и API.

Дальше идёт разговор про требования и моделирование. Вас просят отличить проверяемое требование от пожелания, нарисовать AS-IS и TO-BE, выбрать BPMN или sequence. Затем отдельно проверяют данные и интеграции.

По материалам iFellow за август 2026 техническая секция часто длится 60–90 минут. Её собирают из пяти блоков плюс практика: требования, нотации, БД и SQL, API, архитектура с нефункциональными требованиями.

Практикум Яндекса в июне 2025 описывает такое интервью как экзамен по базе. Спрашивают стейкхолдеров, use case и user story, UML и BPMN, SQL, REST, SOAP, брокеры. В вакансии на госзаказ плюсом будут ГОСТы, в банке сильнее смотрят SQL и проектирование.

Грейд меняет глубину, а не список тем. Junior чаще объясняет виды требований и простой JOIN. Middle разбирает противоречия, ошибки API и sequence. Senior держит измеримые НФТ и последствия решения для команд.

Ниже типичная нарезка этапов. Это не единый стандарт: продуктовая команда дольше сидит в требованиях, интегратор в enterprise отдаёт больше времени API.

Какие типы вопросов ждут системного аналитика

Профессиональный блок почти всегда крутится вокруг пяти тем. Требования и стейкхолдеры. BPMN и UML. Данные и SQL. Интеграции REST, SOAP и очереди. Документация: BRD, SRS, user stories, критерии приёмки.

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

Практика показывает не словарный запас, а последовательность. Сначала границы и AS-IS, потом допущения, потом модель, контракт или запрос.

Профессиональные вопросы системному аналитику

Разберём банк по рабочим темам, а не по Junior, Middle и Senior. Так удобнее повторять то, что реально спрашивают: от сбора требований до контракта API. Грейд проявится в глубине ответа, а не в отдельной главке.

Открытые подборки 2025–2026 на Хабре, конспекты подготовки и разборы iFellow сходятся в одном наборе. Требования, нотации, БД и SQL, интеграции. Selecty отдельно советует освежить REST, способы обмена и плюсы монолита против микросервисов.

Требования и стейкхолдеры

Как собрать требования, если заказчик говорит обрывками?

Что проверяют. Умеете ли вы выявлять потребность, а не записывать чужие слова как ТЗ.

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

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

Кто такие стейкхолдеры и зачем их карта?

Что проверяют. Не путаете ли заказчика, пользователя, спонсора и команду, которая будет жить с решением.

Как отвечать. Стейкхолдер влияет на систему или зависит от неё. Для аналитика это бизнес-заказчик, пользователь, владелец продукта, разработка, тестирование, безопасность, поддержка, иногда регулятор. Карта нужна, чтобы не собрать требования только у самого громкого человека в чате.

Чем функциональные требования отличаются от нефункциональных?

Что проверяют. Отличаете ли «что система делает» от «как хорошо она это делает».

Как отвечать. Функциональное требование описывает поведение: создать заявку, посчитать сумму, отдать статус. Нефункциональное задаёт качество и ограничения: время отклика, доступность, роли доступа, аудит. «Система должна работать быстро» это ещё не требование. «p95 создания заявки не больше 2 секунд при 200 заявках в минуту» уже можно проверить.

Как понять, что требование можно отдать в разработку?

Что проверяют. Критерии качества, а не красивый шаблон в Confluence.

Как отвечать. Хорошее требование однозначное, полное, согласованное, проверяемое и реализуемое. У него есть источник, приоритет и критерий приёмки. Если два человека читают текст по-разному, в разработку рано. Сначала глоссарий, потом формулировка.

Что такое переходные требования и зачем они?

Что проверяют. Думаете ли вы про путь из AS-IS в TO-BE, а не только про целевой экран.

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

BPMN и UML

Когда рисовать BPMN, а когда UML?

Что проверяют. Выбор нотации под задачу, а не привычку «рисую то, что знаю».

Как отвечать. BPMN берёте для бизнес-процесса с ролями, событиями и развилками. UML нужен, когда говорите о системе: use case, sequence, состояния, иногда классы. Для обмена между сервисами по шагам обычно sequence. Для жизненного цикла заявки сильнее state machine, чем простыня из шлюзов.

Какие шлюзы в BPMN реально спрашивают?

Что проверяют. Понимаете ли XOR, AND и OR, а не только прямоугольники и стрелки.

Как отвечать. Эксклюзивный шлюз пускает один путь. Параллельный запускает все ветки и на слиянии ждёт все. Инклюзивный запускает одну или несколько по условиям. Event-based ждёт, какое событие придёт первым: ответ сервиса или таймер. Если нарисовать параллельный шлюз там, где заявка идёт либо в авто, либо к оператору, процесс разъедется.

Какие UML-диаграммы ждут от аналитика?

Что проверяют. Рабочий минимум, а не весь стандарт UML наизусть.

Как отвечать. Чаще всего use case, activity, sequence и state. Use case показывает цели акторов и границы системы. Activity удобна для алгоритма внутри сценария. Sequence показывает сообщения во времени. State описывает статусы и запрещённые переходы. Class и ER не одно и то же: класс несёт поведение, ER говорит про хранение данных.

Чем sequence-диаграмма отличается от activity?

Что проверяют. Не смешиваете ли поток работ и обмен сообщениями.

Как отвечать. Activity отвечает на вопрос, в каком порядке выполняются шаги и решения. Sequence отвечает, кто кому что отправил и в каком порядке. Если нужно показать CRM, шину и биллинг с таймаутом, activity потеряет участников. Если нужен процесс согласования в отделе, sequence будет лишней.

Данные и SQL

SQL на интервью системного аналитика обычно про проверку данных и интеграций, а не про витрину маркетинга. Selecty прямо советует повторить запросы своего уровня: от JOIN до оконных функций, если они у вас есть. Отдельный разбор задач собрали в материале SQL на собеседовании аналитика.

Зачем аналитику модель данных, а не только SELECT?

Что проверяют. Понимаете ли сущности, ключи и связи, прежде чем писать постановку на хранение.

Как отвечать. Модель показывает, что система считает объектом: заявка, клиент, платёж, статус. Без неё легко получить дубли, потерять историю и сломать интеграцию. Нормализация убирает повтор данных. Денормализация осознанно добавляет повтор, чтобы быстрее читать. Сначала назовите, какую аномалию чините, потом уже «добавим поле в эту таблицу».

Какие JOIN вы используете и когда?

Что проверяют. Не путаете ли INNER и LEFT, когда сверяете две системы.

Как отвечать. INNER оставляет только совпавшие строки. LEFT сохраняет все строки левой таблицы и подставляет пустые поля, если справа нет пары. Для «заявки у нас есть, во внешней системе нет» нужен LEFT JOIN и фильтр по пустому ключу справа, а не INNER. RIGHT и FULL спрашивают реже, но смысл тот же: какая сторона не должна потеряться.

Чем WHERE отличается от HAVING?

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

Как отвечать. WHERE фильтрует строки до агрегации. HAVING фильтрует уже группы после GROUP BY. «Заявки за вчера» это WHERE по дате. «Клиенты, у которых больше трёх заявок» это HAVING по COUNT. Если засунуть агрегат в WHERE, запрос просто не сделает то, что вы описали словами.

Как SQL-запросом проверить потерю записей в интеграции?

Что проверяют. Связываете ли SQL с реальной сверкой контуров, а не с учебным SELECT *.

Как отвечать. Берёте ключ обмена, соединяете источник и приёмник, ищете строки без пары, смотрите статусы и время. Отдельно проверяете дубли: один business_id не должен размножиться в приёмнике. Если ключа нет, сначала фиксируете правило сопоставления, иначе сверка врёт.

Интеграции REST, SOAP и очереди

iFellow в августе 2026 называет интеграции главным блоком года для системного аналитика в enterprise. Аналитик здесь готовит документ, по которому две команды пишут код, не сидя в одной комнате. Счастливый путь без ошибок обычно слабый ответ.

Чем REST отличается от SOAP на практике?

Что проверяют. Критерий выбора, а не лозунг «REST современнее».

Как отвечать. REST обычно работает поверх HTTP с ресурсами, JSON и кодами статуса. SOAP это конверт XML, контракт WSDL, строгая схема. SOAP чаще оставляют, где уже есть корпоративная шина, формальный контракт или требование безопасности. REST удобнее для новых HTTP API. Если в вакансии XSD и WSDL, будьте готовы объяснить, зачем схема, а не только «это XML».

Чем PUT отличается от PATCH и что такое идемпотентность?

Что проверяют. Не путаете ли создание, полную замену и частичное обновление.

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

Когда делать синхронный вызов, а когда очередь?

Что проверяют. Думаете ли вы про недоступность второй системы, а не только про «так быстрее».

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

Что должно быть в описании API-контракта?

Что проверяют. Комплект артефактов, по которому можно разрабатывать без автора постановки рядом.

Как отвечать. Системы, цель обмена, триггер, направление, протокол, формат, поля, обязательность, примеры, авторизация, ошибки, ретраи, логирование. Для HTTP ещё путь, метод, коды, идемпотентность, версия. Для очереди ещё топик, ключ, гарантия доставки и что делать с «ядом» в конце очереди. OpenAPI помогает, но без правил на 4xx, 5xx и таймаут это неполный контракт.

Документация и артефакты

Чем User story отличается от Use case?

Что проверяют. Не выдаёте ли карточку бэклога за полное описание сценария.

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

Что входит в постановку, BRD и SRS?

Что проверяют. Понимаете ли, для кого документ, а не коллекционируете аббревиатуры.

Как отвечать. BRD фиксирует бизнес-цель и рамки. SRS описывает требования к системе достаточно полно для проектирования и приёмки. Постановка в трекере это рабочий кусок: контекст, правила, макет, критерии, ссылки на API. Пользователи артефакта разные. Разработчик собирает поведение, тестировщик проверки, архитектор ограничения. Если документ читает только аналитик, он ещё не постановка.

Чем верификация требований отличается от валидации?

Что проверяют. Не путаете ли «написали правильно» и «делаем нужную вещь».

Как отвечать. Верификация отвечает, соответствует ли текст правилам и спецификации: полнота, непротиворечивость, тестируемость. Валидация отвечает, закрывает ли это реальную потребность стейкхолдера. Можно идеально оформить SRS на функцию, которую никто не будет использовать. Тогда верификация пройдена, валидация нет.

Как написать критерии приёмки, по которым можно тестировать?

Что проверяют. Умеете ли превратить историю в проверяемые условия, а не в «должно быть удобно».

Как отвечать. Критерий атомарный, наблюдаемый, с понятным результатом. Удобен формат Given, When, Then или нумерованный список. Отдельно опишите ошибки и пустые данные. «Пользователь может отфильтровать заявки по статусу» слабо. Сильнее: выбран статус «Новая», список показывает только такие заявки, счётчик совпадает, пустой набор даёт понятную заглушку.

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

МегаФон

сегодня

системный аналитик телеком

зп не указана

middle

офис Москва

NDA

вчера

системный аналитик ролевых моделей 1с

от 260 000 ₽

senior

удалённо по РФ

Handle Recruitment

сегодня

system analyst for hris

зп не указана

middle

гибрид Лондон

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

Про опыт спрашивают не «расскажите о себе», а про артефакты и следы решений. Какой документ реально читали разработчик и тестировщик. Где вы остановили спор, а не записали оба требования сразу.

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

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

Конфликт с разработчиком. Обычно спор не «кто умнее», а дыра в постановке. Покажите, что уточнили ограничение, зафиксировали решение и изменили критерий приёмки. Фраза «разработчик просто не хотел делать» звучит слабо.

Требование поменяли после согласования. Назовите, что изменилось в цели, какой объём вырезали, кого предупредили. Важно показать трассировку: бизнес-цель, история, задача, тест.

Пропущенное требование. Разберите, где оборвалась цепочка: не тот стейкхолдер, не проверили TO-BE, не описали ошибку. Затем что изменили в процессе, чтобы дыра не повторилась. Прятать пропуск хуже, чем показать, как закрыли его.

Какие кейсы дают системному аналитику

Ситуационные вопросы проверяют ход мысли, когда вводных мало. iFellow отдельно описывает приём: сначала уточняющие вопросы, и только потом схема. Молча рисовать «правильное» решение обычно минус.

Заказчик не может сформулировать, что хочет

Сначала цель и кто пользователь, не экран. Спросите, какую работу сейчас делают руками и где теряют время. Покажите AS-IS, соберите 2–3 варианта TO-BE, сравните цену и риск. Демонстрационный каркас: «кто, зачем, как сейчас, что будет успехом через месяц».

Два стейкхолдера требуют взаимоисключающее

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

В середине спринта меняют согласованное требование

Отделите уточнение от нового скоупа. Уточнение можно вставить, если критерии ещё живые. Новый скоуп идёт как изменение: влияние на срок, соседние истории, контракт API. Скажите, что именно сломается, если впихнуть молча.

Нужно разобрать legacy без документации

Идите от фактов системы, не от легенд. Логи, код интеграций, таблицы, пользователи, которые помнят обходные пути. Соберите карту контура, пометьте гипотезы отдельно от подтверждённого. Первая поставка часто «зафиксировать AS-IS», а не сразу новая шина.

Партнёрский сервис отвечает 500 и таймаутами

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

Какие задания дают системному аналитику

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

Смоделируйте процесс обработки заявки

Условие. Клиент подаёт заявку. Система проверяет данные. Часть заявок уходит в авто, часть к оператору. Клиент получает статус.

Подход. Сначала роли и границы: клиент, система, оператор, внешний скоринг. Затем события: заявка получена, проверка прошла, отказ, таймаут. XOR между авто и ручной веткой, таймер на ответе партнёра. Не начинайте с красивых иконок, пока не назвали, что будет, если скоринг молчит.

Напишите критерии приёмки для пользовательской истории

Условие. «Как клиент, я хочу видеть статус заявки, чтобы понимать, нужно ли ждать звонка.» История демонстрационная.

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

Найдите расхождение двух систем SQL-запросом

Условие. Демонстрационные таблицы crm_orders и billing_orders. Ключ order_id. Нужны заказы, которые есть в CRM и нет в биллинге за вчера.

Подход. LEFT JOIN по ключу, фильтр по дате в WHERE, пустой ключ биллинга, исключение отменённых, если так договорились. Затем отдельно дубли. Не пишите SELECT * и не молчите про часовой пояс: «вчера» без таймзоны даст ложный разъезд.

Набросайте контракт API создания заявки

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

Подход. Метод POST, путь, тело, обязательные поля, 201 с идентификатором, 409 при повторе ключа, 422 при валидации, 503 если очередь не приняла. Напишите заголовок идемпотентности и что возвращаете на повтор. Добавьте sequence на случай, когда антифрод отвечает дольше двух секунд.

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

Готовьте не словарь терминов, а короткий набор рабочих действий. Разберите вакансию: какие нотации, какая СУБД, какой обмен. Повторите свои артефакты. Напишите одну user story с критериями, одну sequence, один SQL на сверку, один контракт с ошибками.

Selecty отдельно напоминает пройтись по SQL своего уровня и освежить интеграции, с которыми не работали вчера. Если в вакансии Postgres, готовьте поведение запроса, а не абстрактный синтаксис. iFellow в 2026 прямо связывает грейд с планом запроса и сбоями API, а не с умением назвать JOIN.

Полезно проговорить ответы вслух. Для этого можно пройти пробное интервью в ИИ-тренажёре HireHi. Выберите системного аналитика, грейд и формат, отвечайте голосом, затем разберите, где не хватило структуры.

Шаг 1. Выберите специальность, грейд и формат

В форме укажите аналитику, системного аналитика, свой грейд и тип встречи. Для технической секции берите технический формат: так вопросы ближе к требованиям, SQL и API, а не к общему рассказу о себе.

Шаг 2. Запустите тренировку и отвечайте

В живом прогоне отвечайте голосом, как на встрече с ведущим аналитиком. Для этой роли полезно сначала уточнить AS-IS и ограничения, назвать допущение и только потом предлагать BPMN, SQL или контракт.

Экран вопроса и запись голоса открываются после входа и старта сессии. Без этого дальше формы тренажёр не пускает, поэтому ниже опирайтесь на сам сценарий, а не на кадр диалога.

Шаг 3. Посмотрите результат

После завершения сравните, где ответ был верный по сути, но без структуры. Для системного аналитика типичные дыры: нет критерия приёмки, нет ветки ошибки, JOIN выбран не для сверки, нотация не подходит задаче.

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

Шаг 4. Повторите слабые темы

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

Как отвечать, когда условий мало

На интервью системного аналитика молчаливое «сейчас нарисую решение» часто выглядит хуже, чем пауза с вопросами. Сначала восстановите AS-IS: кто инициирует, какие данные уже есть, чем заканчивается успех.

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

Удачный ход: вопрос, допущение, развилка, артефакт. Неудачный: сразу REST «как в учебнике», без статусов, повторов и роли стейкхолдера. Если термина не знаете, скажите об этом и покажите, как уточнили бы его в документации или у техлида.

Какие вопросы задать команде аналитиков

Вопросы работодателю здесь не про «как устроен онбординг вообще». Они показывают, сможете ли вы работать с требованиями в этом контуре.

• Кто владеет приоритетом требований, если продукт и операционный заказчик расходятся?
• В каком инструменте живёт модель процесса и кто имеет право менять BPMN?
• Есть ли доступ к прод-данным или только к обезличенному стенду для сверки?
• Какое соотношение аналитиков и разработчиков на контуре, кто пишет постановку на интеграцию?
• Как команда фиксирует изменение контракта API и срок жизни старой версии?
• Кто принимает решение по НФТ, если бизнес хочет «быстрее», а эксплуатация держит SLA?