Вопросы на собеседовании системного аналитика: 15 главных для джуна с разбором

Собеседование джуна-аналитика редко проваливают из-за незнания теории. Определение user story выучивается за вечер, а вот ответ на «покажи, где ты это применял» за вечер не выучивается.

Ниже — как обычно устроено собеседование на junior BA/SA, пятнадцать вопросов, которые задают почти всегда, и к каждому два варианта ответа: тот, после которого разговор гаснет, и тот, после которого начинают спрашивать глубже. Второе — хороший знак.

Как устроено собеседование

Обычно это три-четыре разговора, и у каждого своя цель.

1. Скрининг с рекрутером, 20–30 минут. Проверяют формальности: опыт, ожидания по деньгам, формат работы, адекватность. Технических вопросов почти нет.
2. Техническое интервью, 1–1,5 часа. Ведёт аналитик или тимлид. Это основной фильтр — вопросы из этой статьи задают здесь.
3. Живая задача или тестовое. Дают кусок требований, схему или таблицу и смотрят, как ты рассуждаешь вслух. Часто идёт внутри технического.
4. Финал с руководителем. Про мотивацию, про то, как ты работаешь в команде и что будешь делать в конфликте.

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

Как отвечать, чтобы ответ работал

Рабочая схема ответа на технический вопрос — четыре шага:

что это → зачем нужно → пример из твоей практики → где ломается.

Первые два пункта есть у всех, кто прочитал статью. Третий отделяет тех, кто делал, от тех, кто читал. Четвёртый — то, за что джуна начинают считать перспективным: если ты сам называешь границы применимости, значит, ты этим пользовался, а не пересказываешь.

⚠️ Самая частая ошибка — отвечать одним предложением-определением и замолкать. Второй по частоте — говорить пять минут без структуры. Целься в 3–4 предложения и остановись: если интервьюеру мало, он спросит.

Блок 1. Роль и подход к работе

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

Слабый ответ: «Бизнес-аналитик ближе к бизнесу, системный — к разработке». Это правда, но её знает и рекрутер. Ответ не показывает, чем отличается твоя работа.

Сильный ответ: БА отвечает за «зачем и что» — цели, процессы, требования верхнего уровня. СА отвечает за «как это будет работать в системе» — интеграции, модель данных, контракты API, поведение в исключениях. Граница проходит по артефактам: у БА — схема процесса и требования, у СА — sequence-диаграмма, ERD и спецификация метода. В небольших командах это один человек, и на вакансиях названия часто путают, поэтому смотрю не на заголовок, а на список задач.

Что проверяют: понимаешь ли, что это не «одно и то же с разной зарплатой». Подробный разбор границы — в статье «Бизнес-аналитик vs системный аналитик».

2. Расскажи про проект, который ты делал

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

Сильный ответ: один проект — пусть учебный, пусть свой — рассказанный как история: какая была задача, что ты выяснял, какие артефакты сделал, что в них пришлось переделать после ревью. «Сквозной кейс — платная подписка с оплатой картой. Сначала описал as-is, потом to-be, из to-be выросли восемь user story с критериями приёмки, под них — ERD и sequence-диаграмма оплаты. Первую версию ERD переделал: не учёл, что у одного пользователя может быть несколько подписок в истории».

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

3. Заказчик не знает, чего хочет. Твои действия?

Слабый ответ: «Попрошу его сформулировать требования» или «эскалирую».

Сильный ответ: не идти за требованиями, идти за проблемой. Что болит сейчас, какие цифры не устраивают, как люди обходят проблему руками. Дальше принести артефакт — схему as-is или набросок экрана — и обсуждать уже его: люди гораздо лучше критикуют готовое, чем описывают желаемое с чистого листа.

Что проверяют: не сдаёшься ли ты, когда входные данные неполные. Это и есть половина работы аналитика.

4. Что такое as-is и to-be и зачем описывать as-is, если всё равно всё меняем

Слабый ответ: определение двух терминов без ответа на вторую половину вопроса.

Сильный ответ: as-is нужен ради трёх вещей: увидеть объём изменений (разница as-is и to-be — это и есть работа), не потерять исключения, которые сейчас разруливают вручную, и договориться с людьми, которые в этом процессе живут. Если as-is не описан, на приёмке выясняется, что «а ещё бывает вот такой случай», и он не поддержан.

Что проверяют: понимаешь ли ценность, а не соблюдаешь ритуал.

5. Как ты понимаешь, что требование хорошее?

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

Что проверяют: есть ли у тебя внутренний критерий качества. Ответ «требование хорошее, если заказчик его согласовал» — красный флаг.

Блок 2. Требования

6. Что такое user story и что в ней главное?

Слабый ответ: «Как роль, я хочу действие, чтобы ценность» — и всё.

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

Что проверяют: скажешь ли про ценность и про критерии приёмки. Разбор с примерами «до и после» — в статье «Как писать user story».

7. Напиши критерии приёмки к истории «пользователь может отменить подписку»

Это уже мини-задача, и её задают часто. Отвечать в формате Given/When/Then и обязательно с негативными сценариями:

• Given активная подписка, When пользователь подтверждает отмену, Then подписка получает статус «отменена», доступ сохраняется до конца оплаченного периода.
• Given уже отменённая подписка, When пользователь повторяет отмену, Then система не меняет состояние и не списывает деньги повторно.
• Given сбой платёжного провайдера при возврате, When возврат не прошёл, Then заявка остаётся в статусе «в обработке», пользователь видит понятное сообщение.

Что проверяют: вспомнишь ли ты про повтор и про сбой. Джуны почти всегда пишут только первый пункт — а именно второй и третий отделяют требование от пожелания.

8. Как приоритизировать требования?

Сильный ответ: MoSCoW — когда нужно договориться про объём релиза; «ценность против трудоёмкости» или RICE — когда сравниваешь разнородные фичи. И главное: приоритет ставит владелец продукта, аналитик приносит для этого данные. Если аналитик расставил приоритеты сам и молча — это не приоритизация, а личное мнение.

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

Блок 3. Моделирование

9. Чем отличается шлюз XOR от AND в BPMN?

Сильный ответ: XOR — выбор ровно одной ветки по условию, AND — параллельный запуск всех веток, и сходящийся AND ждёт их все. Типовая ошибка — развести поток XOR-шлюзом, а свести AND-ом: процесс встанет навсегда, потому что второй ветки не было. Пулы и дорожки при этом не про логику, а про ответственность: дорожка — роль внутри организации, отдельный пул — внешний участник, с которым общаются только сообщениями.

Что проверяют: рисовал ли ты схемы сам. Ошибку «разошлись по XOR, сошлись по AND» знают только те, кто её ловил. Базовый разбор нотации — в статье «BPMN для начинающих».

10. Use case или user story — что когда?

Сильный ответ: user story — короткий формат для бэклога, ценность плюс критерии приёмки. Use case — развёрнутый сценарий с основным потоком, альтернативами и исключениями, полезен там, где сценарий длинный и ветвистый: оплата, подключение внешней системы, сложная форма. Это не конкуренты: одна история может раскрываться одним use case.

Что проверяют: не заучил ли ты «use case — это устарело».

11. Зачем нужна sequence-диаграмма?

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

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

12. Как в базе реализуется связь «многие ко многим»?

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

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

Блок 4. Данные и интеграции

13. Живая задача на SQL

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

Здесь проверяют три вещи: возьмёшь ли LEFT JOIN вместо INNER JOIN (иначе клиенты без заказов пропадут), не перепутаешь ли WHERE и HAVING (условие на период — в WHERE, условие на агрегат — в HAVING) и проговоришь ли вслух, что делаешь.

⚠️ Молчаливое написание запроса — упущенная возможность. Интервьюер оценивает ход мысли: если ты вслух скажешь «беру LEFT JOIN, потому что нужны и клиенты без заказов», ты уже ответил на половину следующих вопросов.

14. Что такое идемпотентность и зачем она в API?

Сильный ответ: повторный вызов с теми же данными не меняет результат. Нужна там, где запрос может прийти дважды: сеть моргнула, клиент нажал «оплатить» второй раз, очередь доставила сообщение повторно. Реализуется ключом идемпотентности: сервис запоминает ключ и на повтор возвращает прежний результат вместо создания второго платежа. GET, PUT и DELETE идемпотентны по спецификации, POST — нет, поэтому именно его защищают ключом.

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

15. Внешняя система не отвечает. Что должно произойти?

Слабый ответ: «Показать пользователю ошибку».

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

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

Поведенческий вопрос, на котором чаще всего спотыкаются

«Разработчик говорит: этого в требованиях не было. А пользователь получил баг. Твои действия?»

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

Что проверяют: берёшь ли ты ответственность и умеешь ли отделять «починить сейчас» от «не повторить потом».

Вопросы, которые стоит задать самому

Отсутствие вопросов читается как отсутствие интереса. Три рабочих:

• Кто ставит задачи аналитику и через кого идёт согласование с бизнесом?
• Какие артефакты приняты в команде и где они живут — Confluence, репозиторий, задачи?
• Как выглядит первый месяц джуна: есть ли наставник и на чём меня будут проверять?

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

План подготовки на две недели

Если готовиться системно, а не читать списки вопросов подряд:

• Дни 1–3. Пройди по пятнадцати вопросам выше и отметь те, где ответ не складывается в три-четыре предложения. Это твой личный список пробелов — с ним и работай, остальное не трогай.
• Дни 4–7. Собери один сквозной кейс: as-is и to-be процесса, 5–8 user story с критериями приёмки, ERD, sequence-диаграмма для сценария с оплатой. Один кейс, доведённый до конца, работает лучше десяти разрозненных артефактов.
• Дни 8–10. Прорешай SQL на любом тренажёре: JOIN, GROUP BY, HAVING, подзапросы. Цель не в скорости, а в том, чтобы не зависать на LEFT JOIN.
• Дни 11–12. Проговори кейс вслух на 10 минут — так, как будешь рассказывать на интервью. Запиши себя, послушай, сократи.
• Дни 13–14. Прогони поведенческие вопросы и подготовь свои три вопроса работодателю.

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

Итог

• Джуна проверяют по трём осям: понимание смысла артефактов, умение задавать вопросы и наличие своих работ.
• Формат сильного ответа: что это → зачем → пример из практики → где ломается.
• Три вопроса, которые чаще всего отделяют подготовленного кандидата: критерии приёмки с негативными сценариями, идемпотентность, поведение при недоступности внешней системы.
• Портфолио важнее списка выученных определений. Один сквозной кейс, доведённый до конца, закрывает половину вопросов из этой статьи.

Именно так устроена практическая часть курса «Аналитик.Старт»: один сквозной проект, по которому ты собираешь BPMN, user story с критериями приёмки, ERD, sequence-диаграммы и спецификацию API — то есть ровно те артефакты, о которых спрашивают на собеседовании. Первые блоки открыты бесплатно.