Аналитик на Балтике · Открытая база знаний

Вопросы на собеседовании системного аналитика: 50 частых и как отвечать

Справочник для системного аналитика

Станислав Неверов

Версия от 2 октября 2026

ineverov.ru/knowledge/sa-interview-bank/

Аналитик на Балтике. Открытая база знаний

Вопросы на собеседовании системного аналитика: 50 частых и как отвечать

Списки вопросов к собеседованию длинные, и непонятно, что из них спросят на самом деле. Я собрал больше 2 700 вопросов с реальных собеседований системных аналитиков и посчитал повторы. Здесь 50, которые встречались минимум на пяти собеседованиях. Для каждого показал, что им проверяют и как строить ответ. Такие банки я собираю для менторства аналитиков, PO и UX/UI-дизайнеров.

Аудитория
Системные аналитики · Middle
Опубликовано
Обновлено
Чтение
≈ 33 мин целиком
К списку вопросов ↓ Скачать PDF Как готовиться ↓
Содержание
  1. Как готовиться
  2. Все 50 вопросов
  3. Основа банка
  4. Как читать частоту
  5. 1О себе, мотивация и роль аналитика
  6. 2HTTP, REST и API
  7. 3Данные и SQL
  8. 4Архитектура, интеграции и брокеры
  9. 5UML и BPMN
  10. 6Требования
  11. 7Безопасность
  12. 8Эксплуатация
  13. Middle и отрасли
  14. Что посмотреть и прочитать
  15. Проверь себя

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

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

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

Это справочник для подготовки, а не курс: базу HTTP, SQL и интеграций здесь не объясняем, рассчитан на аналитика, который с ними работал.

Что получится в конце: устные ответы на 15 частых вопросов с примерами из твоей работы или учебных задач.

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

  1. Начни с 15 полных разборов, в таблице они выделены. Ответь вслух и подбери к каждому пример. Отметь, где это твой рабочий опыт, а где учебная задача.
  2. Добавь вопросы по темам твоей вакансии. Что чаще спрашивают у Middle, в банках и телекоме, показано в таблицах после разбора.
  3. Проверь себя по таблице в конце страницы.

Все 50 вопросов

Полужирным — 15 вопросов с полным разбором. Частота: доля описаний собеседований, где прозвучал вопрос.

О себе, мотивация и роль аналитика

№ВопросЧастота
1Расскажите о себе и релевантном опыте полный разбор47%
2Почему вы вышли на рынок и ищете новую работу? полный разбор19%
3Чем занимается системный аналитик и каков результат его работы?12%
4Как была устроена команда и с кем взаимодействовал аналитик?8%
5Расскажите о сложной задаче или проекте и вашем вкладе.7%
6Как выглядит ваш идеальный проект или место работы?6%
7По каким методологиям разработки вы работали?6%
8Какие артефакты создает системный аналитик?5%

HTTP, REST и API

№ВопросЧастота
9Что такое идемпотентность и какие HTTP-методы идемпотентны? полный разбор25%
10Какие HTTP-методы вы знаете и когда их используете? полный разбор20%
11Что такое OpenAPI/Swagger и как описать спецификацию API? полный разбор17%
12Чем REST отличается от SOAP и когда выбирать каждый подход? полный разбор16%
13Чем GET отличается от POST?11%
14Какие группы и коды состояния HTTP вы знаете?10%
15Чем PUT отличается от PATCH?9%
16Что такое REST?7%
17Какие HTTP-заголовки вы использовали и для чего?4%
18Чем REST отличается от gRPC и когда выбирать каждый подход?4%

Данные и SQL

№ВопросЧастота
19С какими БД и SQL вы работали и как оцениваете свой уровень? полный разбор23%
20Какие виды JOIN вы знаете и как они работают? полный разбор17%
21Что такое нормализация и какие нормальные формы вы знаете? полный разбор16%
22Какие виды баз данных и СУБД вы знаете? полный разбор13%
23Что такое индекс в БД, как он работает и когда может вредить?12%
24Какие ключи и типы связей используются в реляционной модели?7%
25Чем SQL-базы отличаются от NoSQL?5%
26Что такое транзакция и какие свойства она обеспечивает?5%
27Что такое шардирование и когда оно нужно?4%

Архитектура, интеграции и брокеры

№ВопросЧастота
28Чем синхронное взаимодействие отличается от асинхронного? полный разбор23%
29Чем Kafka отличается от RabbitMQ? полный разбор18%
30Какие виды и способы интеграции систем вы знаете? полный разбор15%
31Чем монолит отличается от микросервисной архитектуры? полный разбор13%
32Чем горизонтальное масштабирование отличается от вертикального?6%
33Зачем нужно кеширование и как решать проблему актуальности кеша?5%
34Спроектируйте систему по заданным требованиям и нагрузке.4%
35Какие семантики доставки сообщений вы знаете?4%
36Что такое партиции Kafka и как они влияют на параллелизм и порядок?4%

UML и BPMN

№ВопросЧастота
37Как устроена Sequence Diagram и какие конструкции в ней используются? полный разбор17%
38Какие элементы и правила BPMN вы используете?10%
39Как вы используете PlantUML и описываете взаимодействия?6%
40Какие диаграммы UML вы знаете и использовали?5%

Требования

№ВопросЧастота
41Какие нефункциональные требования нужно учитывать при проектировании?12%
42Чем функциональные требования отличаются от нефункциональных?10%
43Как вы собираете требования у стейкхолдеров?6%
44Какие виды требований вы знаете?5%
45Чем User Story отличается от Use Case и когда применять каждый формат?4%

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

№ВопросЧастота
46Чем аутентификация отличается от авторизации?9%
47Как устроен JWT и как проверяется access token?6%
48Как работает OAuth 2.0 и какие потоки вы знаете?4%

Эксплуатация

№ВопросЧастота
49Какие логи, метрики и трассировки нужны для наблюдаемости системы?6%
50Как вы используете Git и организуете работу с изменениями?6%

На чем основан банк

  • больше сотни описаний реальных собеседований, которые кандидаты опубликовали сами, и больше 2 700 вопросов из них;
  • шесть сборников вопросов для бизнес- и системных аналитиков, больше 400 вопросов-кандидатов;
  • 40 записей собеседований и экспертных роликов с разбором;
  • больше 80 роликов и около 250 статей Хабра, проверенных по свежести и рейтингу для подборки материалов.

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

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

Как банк собирался по шагам и как собрать такой же под свою роль с помощью ИИ, описано в инструкции "Как собрать свой банк вопросов к собеседованию с помощью ИИ".

Как читать частоту

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

Перекос. Все описания взяты из одного открытого канала. Больше трети собеседований из банков и финтеха, Senior в выборке больше, чем Middle.

Частота задает порядок подготовки. Вопросы конкретной компании она не предсказывает.

Тема 1. О себе, мотивация и роль аналитика

1Расскажите о себе и релевантном опыте

Как часто

47% описаний. У Middle чаще: 64% против 35% у остальных грейдов.

Что проверяют

связывается ли твой опыт с вакансией и умеешь ли ты выделить главное.

Как отвечать

начни с текущей роли и одного-двух результатов, которые важны для этой вакансии. Назови свою зону ответственности, чем ты силен и что хочешь дальше.

Типичная ошибка

пересказывать всю биографию или присваивать результат команды.

Уточнят

за какое решение отвечал лично ты? Почему этот результат важен?

Каркас ответа

Я системный аналитик, [сколько лет]. Сейчас работаю в [домен], проект [что за система и для кого]. Моя зона: [требования, контракты API, модель данных — что именно твое]. Последняя заметная задача: [задача]; моя часть — [что сделано тобой]; результат — [что изменилось для бизнеса]. В аналитику меня привело [настоящая причина]. Больше всего в работе нравится [что], меньше [что]. Дальше хочу [куда расти], поэтому мне интересна ваша вакансия: [что в ней совпадает].

Слабый ответ

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

Что я слушаю в ответе

Настораживает заученный или прочитанный текст. Особенно когда проекты перечислены гладко, а на вопрос, почему человек выбрал это направление, что в работе привлекает и что отталкивает, ответа нет.

Станислав Неверов

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

↑ к списку

2Почему вы вышли на рынок и ищете новую работу?

Как часто

19%.

Что проверяют

мотивацию и зрелость перехода.

Как отвечать

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

Типичная ошибка

обвинять бывшую команду или придумывать красивую причину.

Уточнят

что должно быть на новом месте, чтобы ты остался надолго?

Каркас ответа

Хочу [к чему иду: масштаб задач, домен, зона ответственности]. На текущем месте [нейтральный факт: проект завершается, задачи перестали расти, команда меняет направление]. В вашей вакансии вижу [что именно из описания], поэтому и пришел на собеседование.

↑ к списку

Коротко

  • 3
    Чем занимается системный аналитик и каков результат его работы? 12% Проверяют, понимаешь ли ты роль через решения и результаты для команды. Аналитик уточняет цели и ограничения, моделирует систему, проектирует контракты и согласует решение, а при реализации отвечает на уточнения и изменения. Ошибка: свести роль к написанию документации.↑ к списку
  • 4
    Как была устроена команда и с кем взаимодействовал аналитик? 8% Проверяют, понимаешь ли ты свою роль в поставке. Назови роли, точки взаимодействия и то, что решал сам, на одном примере. Перечень должностей без потока работы не ответ.↑ к списку
  • 5
    Расскажите о сложной задаче или проекте и вашем вкладе. 7% Проверяют личный вклад. Контекст, твоя зона ответственности, действия, решение, наблюдаемый результат и вывод: что изменил в подходе после этого случая.↑ к списку
  • 6
    Как выглядит ваш идеальный проект или место работы? 6% Проверяют, насколько реалистичны ожидания. Опиши задачи, масштаб ответственности, способ взаимодействия и условия, в которых даешь лучший результат. Список благ без связи с работой не годится.↑ к списку
  • 7
    По каким методологиям разработки вы работали? 6% Проверяют, как модель работы влияет на анализ. Назови, где был Waterfall, Scrum или Kanban, и что менялось у тебя: глубина и момент детализации, согласование, набор артефактов. Ошибка: считать, что в Scrum документация не нужна.↑ к списку
  • 8
    Какие артефакты создает системный аналитик? 5% Проверяют, подбираешь ли ты артефакт под аудиторию и задачу. Постановки задач, модели процессов и взаимодействий, контракты API, модели данных, критерии приемки. Назови, что делал сам и для кого. Название документа вторично: важны версия, владелец и согласование.↑ к списку

Тема 2. HTTP, REST и API

9Что такое идемпотентность и какие HTTP-методы идемпотентны?

Как часто

25%.

Что проверяют

отличаешь ли безопасный метод от идемпотентного и понимаешь ли, что делать при повторной доставке.

Сильный ответ

  • Повтор одного и того же запроса дает на сервере тот же итоговый эффект, что и один запрос.
  • GET, HEAD, OPTIONS и TRACE безопасны, поэтому идемпотентны. PUT и DELETE идемпотентны по семантике. Для POST и PATCH это свойство не гарантируется, но конкретную операцию можно сделать идемпотентной.
  • Ответы на повторы могут различаться. Для неидемпотентной операции повтор распознают по ключу идемпотентности или по данным самого запроса, например по бизнес-ключу в теле. Результат первого выполнения сохраняют.
  • Проверка повтора и запись результата должны быть согласованы: схема "сначала проверили, потом создали" без защиты от двух одновременных запросов оставляет гонку.

Типичная ошибка

утверждать, что повтор обязан вернуть тот же HTTP-ответ или что DELETE всегда возвращает 200.

Уточнят

как сделать идемпотентным создание платежа? Где хранить ключ и сколько он живет?

Каркас ответа

Идемпотентность значит, что повтор того же запроса дает тот же запрошенный эффект на сервере, что и один запрос. HTTP-ответ при этом может отличаться. GET, PUT и DELETE идемпотентны по семантике; POST этого не гарантирует. На [проекте] повторы были опасны в [операции: оплата, создание заказа]. Защищались так: [ключ идемпотентности или бизнес-ключ операции, например номер заказа]. От одновременных повторов защищались [как согласовали проверку и запись]. На повтор система возвращала [сохраненный результат или состояние той же операции], второй записи не появлялось.

Слабый ответ

правило "передай ключ в заголовке" без понимания, что именно и где проверяется.

Что я слушаю в ответе

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

Станислав Неверов

↑ к списку

10Какие HTTP-методы вы знаете и когда их используете?

Как часто

20%.

Что проверяют

знаешь ли ты семантику методов помимо соответствия CRUD.

Сильный ответ

  • GET читает представление ресурса, POST передает данные на обработку, PUT создает или полностью заменяет состояние ресурса по заданному URI, PATCH задает изменения, DELETE удаляет связь ресурса с URI.
  • Для каждого метода названы безопасность, идемпотентность и допустимое кеширование.
  • URI описывает ресурс, а метод выбирается по смыслу операции.

Типичная ошибка

объяснять методы только словами create, read, update, delete.

Уточнят

когда POST уместен для чтения? Чем PUT отличается от PATCH при повторе?

↑ к списку

11Что такое OpenAPI/Swagger и как описать спецификацию API?

Как часто

17%.

Что проверяют

различаешь ли ты спецификацию OpenAPI и инструменты Swagger, умеешь ли описать контракт.

Сильный ответ

  • OpenAPI описывает HTTP API: пути, операции, параметры, тела запросов, ответы, схемы и безопасность.
  • Swagger это семейство инструментов вокруг спецификации. Названия не стоит использовать как полные синонимы.
  • Контракт нужен для согласования, проверки, документации, моков и генерации кода, но его все равно ревьюят.

Типичная ошибка

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

Уточнят

как описать полиморфизм и ошибку? Как управлять обратной совместимостью?

↑ к списку

12Чем REST отличается от SOAP и когда выбирать каждый подход?

Как часто

16%.

Что проверяют

сравниваешь ли ты архитектурный стиль и протокол сообщений по контракту и ограничениям.

Сильный ответ

  • REST это архитектурный стиль работы с ресурсами через единообразный интерфейс. SOAP это протокол обмена сообщениями с конвертом и моделью обработки.
  • JSON не обязателен для REST, и HTTP не единственный транспорт SOAP.
  • Выбор зависит от строгости контракта, экосистемы стандартов, совместимости, безопасности и того, что уже принято в организации.

Типичная ошибка

ответ "REST это JSON, SOAP это XML" без семантики и ограничений.

Уточнят

где SOAP остается оправданным? Как обеспечить строгий контракт REST API?

↑ к списку

Коротко

  • 13
    Чем GET отличается от POST? 11% У Middle чаще: 18% против 5%. GET запрашивает представление ресурса: безопасен, идемпотентен, ответ можно кешировать, а параметры в URI попадают в логи. POST передает данные на обработку и в общем случае не идемпотентен: повтор после таймаута может создать дубль. Ошибка: считать POST защищенным, потому что тело "не видно". Без TLS оно так же открыто.↑ к списку
  • 14
    Какие группы и коды состояния HTTP вы знаете? 10% 1xx информационные, 2xx успех, 3xx перенаправление, 4xx ошибка клиента, 5xx ошибка сервера. Например, 401 означает отсутствие действительных учетных данных и требует заголовка WWW-Authenticate; 403 — сервер понял запрос, но отказывается его выполнить, в том числе из-за недостаточных прав. Ошибка: отвечать 200 с описанием ошибки в теле.↑ к списку
  • 15
    Чем PUT отличается от PATCH? 9% PUT создает или заменяет состояние ресурса по заданному URI целиком и идемпотентен. PATCH описывает изменения; идемпотентность зависит от операции. Повтор "установить статус closed" может ничего не менять, а повтор "увеличить счетчик на один" изменит его еще раз. Уточнят, как защититься от одновременных изменений, например через ETag и If-Match.↑ к списку
  • 16
    Что такое REST? 7% Архитектурный стиль. Обязательные ограничения: разделение клиента и сервера, отсутствие серверного контекста клиентской сессии между запросами, обозначение возможности кеширования, единообразный интерфейс и многоуровневая система. Передача исполняемого кода клиенту — необязательное ограничение. Единообразный интерфейс включает идентификацию ресурсов, работу через представления, самодостаточные сообщения и ссылки на возможные действия (HATEOAS). Stateless не запрещает хранить заказы или пользователей в базе: запрос содержит весь контекст, нужный для его понимания. Ошибка: определять REST как "JSON поверх HTTP".↑ к списку
  • 17
    Какие HTTP-заголовки вы использовали и для чего? 4% Отвечай по задачам: Content-Type и Accept для формата, Authorization для доступа, Cache-Control и ETag для кеша и условных запросов, заголовок с идентификатором запроса для трассировки, ключ идемпотентности для повторов.↑ к списку
  • 18
    Чем REST отличается от gRPC и когда выбирать каждый подход? 4% REST — архитектурный стиль, gRPC — фреймворк удаленного вызова процедур, обычно с контрактом и сериализацией в Protocol Buffers. Нативный gRPC работает поверх HTTP/2 и поддерживает потоковую передачу. Его часто выбирают между сервисами; HTTP API с ресурсами проще использовать из браузера обычными средствами. Для gRPC в браузере есть gRPC-Web, у него свои ограничения. Выбор зависит от клиентов, контракта и требований к обмену.↑ к списку

Тема 3. Данные и SQL

19С какими БД и SQL вы работали и как оцениваете свой уровень?

Как часто

23%. У Middle чаще: 30% против 19%.

Что проверяют

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

Сильный ответ

  • Названы СУБД, объемы и виды задач: чтение, изменение, моделирование, миграции или диагностика.
  • Приведены конструкции SQL и одна задача, которую ты решил сам.
  • Самооценка подкреплена границами: что делаешь уверенно, где нужна помощь, что изучаешь дальше.

Типичная ошибка

общая самооценка вроде "уверенно пишу запросы" без задач, объема данных и проверяемого результата.

Уточнят

какой самый сложный запрос ты писал? Как проверял его корректность и скорость?

Каркас ответа

Работаю с [СУБД] около [срока] на [продукт]. Модель данных знаю изнутри: [ключевые сущности и откуда в них приходят данные]. SQL нужен мне, чтобы [проверять требования, искать причины расхождений, готовить выборки для бизнеса]. Например, [задача]: сначала разбираюсь, что значат поля для бизнеса, потом пишу запрос с [конструкции] и сверяю результат с [чем]. Уверенно делаю [что], вместе с разработчиком [что], сейчас подтягиваю [что].

Что я слушаю в ответе

Уровень в SQL я определяю не по заученным агрегатным функциям и даже не по подзапросам и оконным функциям. Синтаксис нужен, но уровень видно по-другому: понимает ли человек модели данных целиком. На уровне бизнеса: какие сущности есть в продукте и что они означают. В логической модели: ключи, связи, кардинальность. И модули системы: где живут данные и кто их источник. Без этого запрос бывает верным по синтаксису и неверным по смыслу. Например, если соединить заказы с их позициями и просуммировать сумму заказа по каждой полученной строке, итог окажется завышен: один заказ учтен несколько раз.

Станислав Неверов

↑ к списку

20Какие виды JOIN вы знаете и как они работают?

Как часто

17%.

Что проверяют

понимаешь ли ты результат соединения на конкретных данных и влияние кардинальности.

Сильный ответ

  • INNER возвращает совпавшие строки. LEFT сохраняет все строки слева. RIGHT симметричен LEFT. FULL сохраняет обе стороны. CROSS дает все сочетания строк двух таблиц.
  • Условие ON определяет совпадение, а фильтр WHERE после внешнего соединения может убрать строки с NULL.
  • Учтены связи один ко многим, дубликаты и план выполнения.

Типичная ошибка

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

Уточнят

почему LEFT JOIN превратился в INNER после WHERE? Как найти строки без пары?

↑ к списку

21Что такое нормализация и какие нормальные формы вы знаете?

Как часто

16%. У Middle чаще: 23% против 10%.

Что проверяют

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

Сильный ответ

  • Нормализация уменьшает избыточность данных и устраняет аномалии вставки, изменения и удаления с учетом функциональных зависимостей.
  • Первая нормальная форма: значения атомарны в выбранных доменах, повторяющихся групп нет.
  • Вторая: таблица уже в первой форме; атрибуты, не входящие ни в один кандидатный ключ, не зависят от части какого-либо составного кандидатного ключа. Кандидатный ключ минимально идентифицирует строку; первичный — выбранный кандидатный ключ.
  • Третья: для каждой нетривиальной зависимости X → A либо X — суперключ, либо A входит хотя бы в один кандидатный ключ. Суперключ идентифицирует строку, но может содержать лишние поля.
  • Простой пример нарушения третьей формы: в заказе хранятся идентификатор клиента и его адрес, причем адрес зависит от клиента. При смене адреса придется править много заказов. Если нужен текущий адрес, его выносят к клиенту. Если это адрес доставки на момент заказа, он описывает сам заказ — смысл данных другой.
  • Денормализация оправдана для чтения и отчетов. Платят за нее сложностью записи и риском рассогласования.

Типичная ошибка

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

Уточнят

приведи пример нарушения третьей нормальной формы. Когда ты денормализуешь осознанно?

↑ к списку

22Какие виды баз данных и СУБД вы знаете?

Как часто

13%.

Что проверяют

выбираешь ли ты тип хранилища под задачу и данные.

Сильный ответ

  • По модели данных: реляционные, документные, ключ-значение, ширококолоночные (семейства столбцов) и графовые. Колоночное хранение для аналитики — отдельная характеристика, не синоним ширококолоночной модели. По назначению выделяют также поисковые системы и хранилища временных рядов; эти классификации могут пересекаться.
  • Для каждого вида назван типичный сценарий: ключ-значение для сессий и кеша, колоночная для аналитики, поисковая для полнотекстового поиска.
  • Выбор обоснован моделью данных, профилем чтения и записи, требованиями к согласованности, масштабом и ценой эксплуатации.

Типичная ошибка

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

Уточнят

где бы ты хранил корзину, а где историю заказов? Чем транзакционная нагрузка отличается от аналитической?

↑ к списку

Коротко

  • 23
    Что такое индекс в БД, как он работает и когда может вредить? 12% Отдельная структура доступа, которая находит строки без полного просмотра таблицы. Выбор зависит от селективности, порядка столбцов и плана запроса. Цена: место и более медленная запись, эффект проверяют планом выполнения. Ошибка: индекс на каждый столбец.↑ к списку
  • 24
    Какие ключи и типы связей используются в реляционной модели? 7% Кандидатный ключ минимально идентифицирует строку; один из них выбирают первичным. Первичный ключ уникален и не допускает NULL. Внешний ключ обеспечивает ссылочную целостность; UNIQUE задает ограничение уникальности, поведение NULL зависит от СУБД и настройки. Ключ бывает естественным или суррогатным. Связи один к одному, один ко многим, многие ко многим; последнюю обычно реализуют через связующую таблицу.↑ к списку
  • 25
    Чем SQL-базы отличаются от NoSQL? 5% Обычно сравнивают реляционную модель с документной, ключ-значение, графовой и другими моделями NoSQL. Схема, транзакции, согласованность и горизонтальное масштабирование зависят от конкретной СУБД: NoSQL не означает отсутствие ACID, а реляционная база тоже может масштабироваться горизонтально. Выбирают по данным и запросам. Ошибка: "NoSQL быстрее" или "NoSQL всегда жертвует согласованностью".↑ к списку
  • 26
    Что такое транзакция и какие свойства она обеспечивает? 5% Группа операций, которая выполняется целиком или не выполняется совсем. Свойства ACID: атомарность, согласованность, изолированность, долговечность. Дальше спросят про уровни изоляции и аномалии чтения.↑ к списку
  • 27
    Что такое шардирование и когда оно нужно? 4% Данные делят между несколькими узлами по ключу шардирования, когда один узел не выдерживает объем или запись. Цена: запросы через несколько шардов, перебалансировка, распределенные транзакции. Отличай от партиционирования внутри одной базы и от репликации.↑ к списку

Тема 4. Архитектура, интеграции и брокеры

28Чем синхронное взаимодействие отличается от асинхронного?

Как часто

23%.

Что проверяют

выбираешь ли ты модель взаимодействия по требованиям к времени ответа, связанности и надежности.

Сильный ответ

  • Синхронный вызов дает ответ в рамках запроса и связывает доступность и время ответа участников.
  • Асинхронная модель позволяет получить результат позже. При обмене через брокер нужно отдельно продумать состояние операции, повторы, порядок и допустимую задержку согласования данных; гарантии зависят от реализации.
  • Выбор обоснован SLA, допустимой задержкой, нагрузкой, сценарием отказа и тем, нужен ли результат прямо сейчас.

Типичная ошибка

считать асинхронность автоматически более быстрой и надежной.

Уточнят

что увидит пользователь, если потребитель недоступен? Как ты обработаешь дубликат события?

Каркас ответа

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

↑ к списку

29Чем Kafka отличается от RabbitMQ?

Как часто

18%. В телекоме чаще: 50% против 15% в остальных сферах.

Что проверяют

сравниваешь ли ты продукты по модели работы и требованиям, не выбирая победителя вообще.

Сильный ответ

  • Kafka хранит упорядоченный журнал по партициям, и потребитель сам управляет позицией. RabbitMQ с классическими очередями маршрутизирует сообщения через exchange в очереди и ориентирован на подтверждение доставки потребителем; RabbitMQ Streams дает журнал с повторным чтением.
  • В сравнении есть хранение и повторное чтение, маршрутизация, порядок, масштабирование, задержка и эксплуатация.
  • Выбор привязан к сценарию: поток событий и повторное чтение либо рабочие очереди и гибкая маршрутизация.

Типичная ошибка

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

Уточнят

как обеспечить порядок для одного клиента? Что произойдет после падения потребителя?

↑ к списку

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

Как часто

15%.

Что проверяют

различаешь ли ты способы интеграции и выбираешь ли их по требованиям.

Сильный ответ

  • Базовые способы: обмен файлами, общая база данных, вызов API или удаленной процедуры, обмен сообщениями.
  • Синхронность и асинхронность — режимы взаимодействия, а REST, SOAP и gRPC — разные подходы к интерфейсу и обмену. HTTP API может запускать долгую операцию и отдавать ее результат позже.
  • Интеграционная шина организует маршрутизацию и преобразования. Пакетная загрузка и захват изменений из базы (CDC) описывают способы переноса данных; их можно сочетать с файлами, API или брокером.
  • Сравнение идет по связанности, задержке, объему, надежности доставки, контракту и владению данными.
  • У каждого способа названа цена: общая база связывает схемы систем, файлы дают задержку и проблемы с повторной загрузкой, брокер приносит дубли и вопросы порядка.

Типичная ошибка

перечислить протоколы и не сказать, когда какой выбрать.

Уточнят

как передавать большой объем данных раз в сутки? Что выберешь, если ответ нужен сразу?

↑ к списку

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

Как часто

13%.

Что проверяют

связываешь ли ты архитектурный стиль с границами домена и ограничениями организации.

Сильный ответ

  • Монолит упрощает транзакции, разработку и эксплуатацию на старте. Микросервисы дают независимое изменение и масштабирование ценой распределенности.
  • Сравнены границы владения данными, согласованность, деплой, наблюдаемость, тестирование и компетенции команды.
  • Микросервисы оправданы независимыми изменениями и масштабом. Размер кода оправданием не служит.

Типичная ошибка

считать микросервисы обязательным признаком зрелой системы.

Уточнят

по каким границам делить систему? Когда модульный монолит лучше?

↑ к списку

Коротко

  • 32
    Чем горизонтальное масштабирование отличается от вертикального? 6% Вертикальное — добавить ресурсы узлу: CPU, память, диск; у этого есть предел. Горизонтальное — добавить узлы и распределить нагрузку. Сервисы без состояния проще масштабировать, но масштабируют и системы с состоянием — через разделение данных и репликацию. Само увеличение мощности или числа узлов не гарантирует отказоустойчивость. Выбор по нагрузке, цене и требованию к доступности.↑ к списку
  • 33
    Зачем нужно кеширование и как решать проблему актуальности кеша? 5% Кеш снижает задержку и нагрузку на источник. Назови, что кешируешь, ключ и срок жизни, кто источник истины, как сбрасываешь кеш при изменении данных и что будет, если много запросов одновременно промахнутся мимо кеша.↑ к списку
  • 34
    Спроектируйте систему по заданным требованиям и нагрузке. 4% Сама формулировка редкая, но практическая задача какого-то вида была примерно в 70% собеседований Middle. Задачи почти не повторяются, поэтому готовь ход решения:
    1. Уточни цель, пользователей, входы, выходы, ограничения и критерии успеха.
    2. Назови допущения вслух и отдели обязательное от желательного.
    3. Покажи участников, данные, состояния, интерфейсы и основной поток.
    4. Разбери альтернативные сценарии, ошибки, повторы, конкуренцию и права доступа.
    5. Оцени нагрузку, доступность и наблюдаемость в той глубине, которой требует грейд.
    6. Сравни варианты, назови выбранный компромисс и скажи, как проверишь результат.
    ↑ к списку
  • 35
    Какие семантики доставки сообщений вы знаете? 4% Не более одного раза (at-most-once): возможна потеря. Не менее одного раза (at-least-once): возможны повторы. Ровно один раз (exactly-once): нужно назвать границы гарантии — передача сообщения и единственный эффект обработки во внешней БД не одно и то же. Для внешней записи нужно согласовать ее с фиксацией прочитанного сообщения либо обеспечить идемпотентность. Обычные подтверждения доставки сами по себе exactly-once не дают.↑ к списку
  • 36
    Что такое партиции Kafka и как они влияют на параллелизм и порядок? 4% Топик делится на партиции. Порядок записей гарантирован внутри партиции. Ее выбирает продюсер, часто по ключу сообщения; ключ может отсутствовать. В обычной группе потребителей партиция назначается одному потребителю, поэтому параллелизм чтения ограничен числом партиций. Уточнят, как выбрать ключ и что делать с перегруженной партицией.↑ к списку

Тема 5. UML и BPMN

37Как устроена Sequence Diagram и какие конструкции в ней используются?

Как часто

17%. В банках и финтехе чаще: 35% против 11%.

Что проверяют

умеешь ли ты моделировать сценарий взаимодействия и знаешь ли смысл ключевых элементов.

Сильный ответ

  • Участники и линии жизни, сообщения в порядке времени, активации и возвращаемые результаты.
  • Конструкции alt, opt, loop, par и break для условий, повторов, параллельности и прерывания.
  • Показаны синхронность, асинхронность, ошибки и граница выбранного сценария.

Типичная ошибка

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

Уточнят

как изобразить таймаут и повтор? Где остановить детализацию?

↑ к списку

Коротко

  • 38
    Какие элементы и правила BPMN вы используете? 10% События, задачи, шлюзы, потоки управления и сообщений, пулы и дорожки. Исключающий шлюз выбирает одну ветку, параллельный запускает все. Сообщения идут между пулами, поток управления границу пула не пересекает. Ошибка: шлюз как декоративная развилка.↑ к списку
  • 39
    Как вы используете PlantUML и описываете взаимодействия? 6% Диаграмма как текст: хранится рядом с документацией в Git, видно изменения, ее можно ревьюить. Расскажи, какие диаграммы так вел и как их обновляли. Ограничение: сложную раскладку труднее контролировать, чем в графическом редакторе.↑ к списку
  • 40
    Какие диаграммы UML вы знаете и использовали? 5% Структурные: классов, компонентов, развертывания. Поведенческие: последовательности, деятельности, состояний, вариантов использования. Называй те, что применял, и какой вопрос команды закрывала каждая.↑ к списку

Тема 6. Требования

Коротко

  • 41
    Какие нефункциональные требования нужно учитывать при проектировании? 12% В банках и финтехе чаще: 20% против 5%. Проверяют, переводишь ли ты ожидания о качестве в измеримые требования: производительность, доступность, надежность, безопасность, масштабируемость, наблюдаемость. У требования есть метрика, условия измерения, целевое значение и период. Ошибка: "система должна работать быстро" без нагрузки, перцентиля и порога.↑ к списку
  • 42
    Чем функциональные требования отличаются от нефункциональных? 10% Функциональное описывает, что система делает для участника. Нефункциональное задает измеримое качество или ограничение. Ошибка: записать бизнес-правило в нефункциональные только потому, что оно звучит как ограничение. Уточнят: сделай измеримым требование "быстрый поиск".↑ к списку
  • 43
    Как вы собираете требования у стейкхолдеров? 6% Сначала карта стейкхолдеров: влияние, затронутость, полномочия. Затем техника под ситуацию: интервью, наблюдение, анализ документов и систем, воркшоп, прототип. Результат фиксируешь и подтверждаешь. Ошибка: считать стейкхолдером только заказчика.↑ к списку
  • 44
    Какие виды требований вы знаете? 5% Сначала назови классификацию. Например, в BABOK есть бизнес-требования, требования заинтересованных сторон, требования к решению (функциональные и нефункциональные) и переходные требования. Пользовательские — часть требований заинтересованных сторон. Переходные нужны для смены решения: миграция данных, обучение, временная совместимость. Бизнес-правила и ограничения учитывают отдельно. Покажи связь цели бизнеса с требованием и способом проверки.↑ к списку
  • 45
    Чем User Story отличается от Use Case и когда применять каждый формат? 4% История кратко называет роль, намерение и ценность, детали раскрывают критерии приемки. Сценарий использования описывает цель актора, предусловия, основной, альтернативные и ошибочные потоки. Форматы сочетают: история ведет элемент бэклога, сценарий раскрывает сложный случай.↑ к списку

Тема 7. Безопасность

Коротко

  • 46
    Чем аутентификация отличается от авторизации? 9% Аутентификация подтверждает, кто обращается. Авторизация решает, что этому субъекту можно делать с ресурсом. Права проверяются на доверенной стороне при каждом защищенном действии. Ошибка: считать валидный токен разрешением на любую операцию.↑ к списку
  • 47
    Как устроен JWT и как проверяется access token? 6% JWT — формат токена с утверждениями; access token не обязательно имеет этот формат. У обычного подписанного JWT есть заголовок, полезная нагрузка и подпись, содержимое не зашифровано. Проверяют подпись, разрешенный алгоритм, издателя, аудиторию, срок действия и назначение токена: access, а не refresh или ID token. После проверки токена проверяют права на конкретную операцию. Нужны короткий срок жизни и решение для отзыва. Ошибка: доверять данным после декодирования без проверки подписи.↑ к списку
  • 48
    Как работает OAuth 2.0 и какие потоки вы знаете? 4% Протокол делегирования доступа. Роли: владелец ресурса, клиент, сервер авторизации, сервер ресурсов. Для приложений с пользователем основной поток Authorization Code с PKCE, для обмена между сервисами Client Credentials. OAuth про доступ; вход пользователя поверх него дает OpenID Connect.↑ к списку

Тема 8. Эксплуатация

Коротко

  • 49
    Какие логи, метрики и трассировки нужны для наблюдаемости системы? 6% Метрики показывают, что что-то пошло не так: ошибки, задержка, нагрузка. Логи говорят, что именно произошло. Трассировка показывает, где в цепочке сервисов. Связывает их сквозной идентификатор запроса. Аналитик задает, какие события и поля писать, и следит, чтобы в логи не попали персональные данные.↑ к списку
  • 50
    Как вы используете Git и организуете работу с изменениями? 6% Ветки и запросы на слияние с ревью, история изменений спецификаций, документация рядом с кодом. Расскажи, как вели в репозитории требования или контракты и как согласовывали правки.↑ к списку

Что чаще спрашивают у Middle и в твоей отрасли

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

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

Middle против остальных грейдов

ВопросMiddle (44 описания)Остальные (62)
Расскажите о себе и релевантном опыте64%35%
С какими БД и SQL вы работали30%19%
Как устроена Sequence Diagram23%11%
Что такое нормализация23%10%
Чем GET отличается от POST18%5%

У Senior заметнее вопрос о сложной задаче и своем вкладе: 10% против 0% у остальных.

Банки и финтех против остальных сфер

ВопросБанки и финтех (40)Остальные (38)
Идемпотентность35%21%
Как устроена Sequence Diagram35%11%
HTTP-методы28%13%
Индекс в БД23%3%
REST и SOAP23%8%
Нефункциональные требования20%5%
Элементы и правила BPMN18%0%

Телеком

ВопросТелеком (12)Остальные (66)
Kafka и RabbitMQ50%15%
OpenAPI33%14%

Выборка по телекому маленькая, считай это ориентиром. По производству, ритейлу и iGaming описаний слишком мало для выводов.

Что посмотреть и прочитать

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

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

HTTP и API

  • Статья на Хабре

    vsinyavsky, "Idempotency keys: 5 граблей, которые мы поймали на проде"⁠, 27.05.2026. Для вопроса 9 — как разбор ошибок, а не как готовое решение. Полезны четыре "грабли": ключ живет столько же, сколько намерение пользователя, а не одна попытка (1); срок хранения ключа покрывает все окно повторов клиента (2); внешний вызов тоже должен быть идемпотентным (4); повторно отданный ответ может устареть (5). Решение из третьей не копируй: ключ из бизнес-полей и пятиминутного окна по текущему времени меняется, если повтор пришел после смены окна, а снятие резерва при любой ошибке позволяет заново провести уже выполненный платеж. Заголовок Idempotency-Key в статье местами назван RFC, на деле это черновик стандарта.

  • Видео

    Канал "Аналитик маминой подруги", "Системный аналитик? REST/SOAP для собеседований ПРОСТЫМ ЯЗЫКОМ — всё, что нужно знать для собеседований"⁠, 27.04.2026, 16 мин. Для вопроса 12 смотри примерно 5:30–14:00: REST как архитектурный стиль, SOAP как строгий протокол, обработка ошибок и WSDL. Поправка к ролику: HTTP — протокол прикладного уровня, а не транспортный; SOAP-сообщения передают поверх HTTP и других протоколов. Около 14:30 рекламная вставка.

Данные и SQL

Архитектура, интеграции и брокеры

  • Видео

    Максим Белов, "Kafka vs REST. Вопрос, на котором сыпется каждый второй аналитик"⁠, 29.04.2026, 19 мин. Для вопроса 28 смотри примерно 9:00–14:00: даже в системе на Kafka вызов внешнего платежного шлюза остается синхронным. Для вопросов 35 и 36 — 14:00–16:30: offset, доставка "не менее одного раза", идемпотентный обработчик, ключ и партиция. Две поправки: около 5:30 число сочетаний ответов при N сервисах — 2 в степени N, а не N в квадрате; около 16:00 сказано, что партицию по ключу выбирает брокер, на деле ее определяет продюсер, его логика партиционирования (см. карточку 36).

  • Видео

    Андрей Серебрянский, balun.courses, "Kafka vs RabbitMQ - в чем реальная разница?"⁠, 17.02.2026, 10 мин. Для вопроса 29: очереди и обратное давление, каскадные отказы (примерно 3:00–6:30), удаление сообщения из очереди после подтверждения и хранение в Kafka по сроку с повторным чтением (6:00–9:30). Сравниваются классические очереди RabbitMQ; у RabbitMQ есть и Streams — журнал с хранением и повторным чтением. В конце реклама курса.

UML и BPMN

Требования

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

О себе

Проверь себя перед собеседованием

Возьми десять вопросов: пять самых частых и пять по темам из твоей вакансии.

ПроверкаЕсли получилосьЕсли нет
На восемь из десяти вопросов отвечаешь вслух за 60–90 секунд, без текста перед глазамиПереходи к уточнениям из карточекПерескажи сильный ответ своими словами и повтори на следующий день
К каждому из этих восьми есть пример, и ты называешь, рабочий он или учебный; в рабочем понятна твоя часть решенияОставь пример коротким: контекст, твое решение, результатРазбери учебную задачу и прямо назови границу своего опыта
По каждому вопросу называешь ограничение или альтернативуОтвет готов к вопросу "а если иначе"Добавь к ответу один вариант, который ты не выбрал, и причину
Выдерживаешь два уточнения подряд про ошибку, нагрузку, безопасность или изменение требованийБери следующий вопросРазбери уточнения из карточки и ответь на них вслух
Учебная задача: первые две минуты только вопросы и допущенияИдешь дальше по ходу решенияНачинаешь со схемы или технологии: повтори задачу с шага 1

Если выполнены не все пять строк, начни с первой невыполненной.

Скачать PDF

Сохрани банк и открой его перед собеседованием

Знания открыты. Практика вместе.

Банк бесплатный, своими идеями я делюсь свободно. Свой банк под любую роль можно собрать самостоятельно: способ описан в инструкции.

В клубе "Аналитик на Балтике" этот способ разложен на ступени. Ты проходишь их на своей задаче, а промежуточную версию приносишь на живой разбор. Разборов два в месяц. Следующий набор откроется в ноябре, до него запись идет через лист ожидания.

Посмотреть, как устроен клуб

Если собеседование уже на этой неделе, быстрее разобрать твою вакансию один на один.

Разбор один на один

Ваш Аналитик на Балтике

ineverov.ru/knowledge/sa-interview-bank/