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

Техническое интервью аналитика держится на пяти блоках: требования, нотации, базы данных и SQL, интеграции и API, архитектура с нефункциональными требованиями. Поверх — практическая задача: спроектировать обмен между системами, вытащить требования из расплывчатой формулировки или написать ТЗ на небольшую фичу. Формат ближе к экзамену, чем к беседе: проверяют широту покрытия, а не одну глубокую компетенцию. Дальше разберём вопросы на собеседовании системного аналитика по блокам — что именно слушают в каждом ответе, как отличают заученное от рабочего и почему на один и тот же вопрос middle и senior отвечают по-разному.

Ключевые факты

Базовые определения — UML и BPMN, функциональные и нефункциональные требования, способы документирования — разобраны в отдельном материале блога [«Подготовка к собеседованию аналитика: топ вопросов и рекомендации»](https://ifellow.ru/media-center/podgotovka-k-sobesedovaniyu-analitika-top-voprosov-i-rekomendatsii/). Здесь мы их не повторяем и идём глубже: к критериям оценки и задачам.

Как устроено техническое собеседование системного аналитика

Секция длится 60–90 минут и почти всегда собрана из пяти тематических блоков плюс практика. Ведёт её ведущий или главный аналитик, часто вдвоём с архитектором или техлидом — второй участник обычно молчит первые двадцать минут, а потом задаёт три самых неудобных вопроса.

Доли времени — отраслевая практика, а не стандарт: у продуктовой команды акцент уходит в требования, у интегратора в enterprise-проектах интеграционный блок съедает половину интервью. Общий процесс найма — этапы, роли интервьюеров, сроки — разобран в статье [о техническом собеседовании в ИТ](/blog/tehnicheskoe-sobesedovanie-v-it/).

Блок 1. Требования: как отличают «писал документацию» от «управлял требованиями»

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

Любимый приём интервьюера — дать заведомо дефектное требование и попросить найти проблемы. Например:

«Система должна быстро обрабатывать заявки и уведомлять пользователя об изменении статуса».

Здесь минимум четыре дефекта. «Быстро» непроверяемо. Не сказано, при какой нагрузке. Не определён канал уведомления. Не описано поведение, если канал недоступен. Переписанная версия звучит иначе:

«Заявка переходит в статус „Принята“ не позднее 3 секунд после отправки при нагрузке до 200 заявок в минуту. Уведомление отправляется push и дублируется письмом, если push не доставлен за 60 секунд. При недоступности канала уведомление ставится в очередь и повторяется до 3 раз с интервалом 5 минут».

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

Блок 2. Нотации: рисовать умеют все, выбирать — не все

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

Вопрос на границу знания обычно такой: чем sequence отличается от communication и когда нужна state machine. Ответ «использую то, что понятно команде» засчитывается, если за ним следует пример: где именно отказались от формальной нотации в пользу таблицы и почему это сработало.

Блок 3. Базы данных и SQL: где заканчивается синтаксис

JOIN и GROUP BY спрашивают у всех, и они грейд не определяют. Грейд определяют вопросы про поведение запроса под нагрузкой.

Порядок усложнения примерно такой:

1. Соединения, агрегаты, подзапросы — базовый уровень, ожидается от всех.

2. Оконные функции — типовой рубеж между junior и middle.

3. План запроса: что покажет EXPLAIN, почему полное сканирование вместо индекса.

4. Индексы: какие бывают, почему индекс не помог, чем платим за каждый новый.

5. Нормализация и осознанная денормализация: когда третьей нормальной формой сознательно жертвуют.

6. Транзакции, уровни изоляции, блокировки: что такое грязное чтение и фантомы, где ловится дедлок.

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

Вопросы всё чаще формулируют в терминах PostgreSQL: по обзору рынка СУБД 2026 года (TAdviser) он остаётся технологической основой большинства проектов импортозамещения и де-факто стандартом российского рынка. Если в вакансии указан Postgres, спросят про его специфику, а не про абстрактный SQL.

Блок 4. Интеграции и API: главный блок 2026 года

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

Комплект артефактов на интеграционную задачу устойчив по рынку:

1. описание API внешних систем;

2. use cases обмена;

3. маппинг данных между моделями систем;

4. правила валидации;

5. обработка ошибок;

6. требования к логированию;

7. sequence-диаграмма для сложных сценариев.

Вопросы и то, что за ними стоит:

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

Блок 5. Архитектура и нефункциональные требования

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

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

Проверка на измеримость — короткая. «Система должна работать быстро» не требование. «p95 ≤ 500 мс при 2 000 запросов в секунду» — требование, потому что его можно проверить. Отсюда обычно уходят в смежные темы: как эти цифры подтверждаются (см. материал [о нагрузочном тестировании](/blog/nagruzochnoe-testirovanie/)) и как они попадают в договор с заказчиком (см. разбор [метрик SLA](/blog/sla-na-podderzhku-informacionnyh-sistem/)).

Задачи на собеседовании: четыре формата и что в них оценивают

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

Формат 1. Спроектировать интеграцию двух систем

Классическая формулировка: «Опишите интеграцию CRM с ERP». Оценивают полноту комплекта и работу со сбоями.

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

Формат 2. Выжать требования из расплывчатой формулировки

Формулировка вроде «нужен сервис пользователей» даётся намеренно пустой. Проверяют умение задавать вопросы и структурировать неопределённость.

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

Формат 3. Написать ТЗ на небольшую фичу

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

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

Формат 4. Смена вводных по ходу решения

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

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

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

[Вставка: обезличенные задачи, которые команда iFellow даёт аналитикам на интервью, и критерии их оценки. Разбор выше — типовая отраслевая практика.]

Один вопрос — три ответа: как отвечают junior, middle и senior

Одни и те же вопросы системному аналитику на собеседовании закрываются по-разному в зависимости от уровня. Хорошая иллюстрация — «как бы вы спроектировали обмен данными между двумя системами». Одна формулировка, три разных разговора.

Разница не в объёме знаний, а в горизонте: junior отвечает про «как сделать», middle — «как сделать правильно для этой задачи», senior — «как это будет жить два года и кто будет чинить». Поэтому заученные ответы на собеседовании системного аналитика работают плохо: они выдают уровень «знаю термин», даже когда термин назван верно.

[Вставка: грейдовая матрица iFellow — как компания различает уровни по одному вопросу.]

Что изменилось в 2026 году

Три сдвига, которые видно по составу вопросов.

Импортозамещение перестало быть темой для галочки. Спрашивают про PostgreSQL вместо Oracle, про отечественные брокеры и платформы, про опыт миграции. По обзору рынка СУБД 2026 года (TAdviser) рынок ушёл от простой замены зарубежных решений к требованиям по нагрузкам, защите данных и предсказуемости критичных систем — от аналитика ждут понимания, что миграция меняет в поведении системы, а не только в лицензии.

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

Рынок сузился, требования расширились. С начала 2025 года число ИТ-вакансий в РФ сократилось на 22%, в 2026 году их примерно на 35% меньше, чем в 2025. Одновременно 64% работодателей отмечают нехватку специалистов — сокращение бьёт по входу в профессию, а не по сильным кандидатам. Практическое следствие: от аналитика чаще ждут понимания архитектуры и умения читать код, хотя писать его не требуют.

[Вставка: позиция iFellow по использованию ИИ при выполнении тестового задания и способ проверки.]

Как пройти собеседование системного аналитика: подготовка по блокам

Готовиться к собеседованию на системного аналитика списком вопросов бесполезно — их сотни, и спросят не те. Работает подготовка, привязанная к пяти блокам.

1. Разберите две свои интеграции по схеме. Задача → выбранный способ обмена → отвергнутые варианты → как обрабатывали ошибки → что бы изменили сейчас. Это закрывает главный блок интервью целиком.

2. Поднимите SQL на живой базе, а не в тетради. Наполните таблицу миллионом строк, напишите медленный запрос, посмотрите EXPLAIN, добавьте индекс, посмотрите снова. Один такой вечер даёт больше, чем неделя чтения про индексы.

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

4. Соберите мини-портфолио артефактов. Две-три обезличенные диаграммы, фрагмент спецификации API, пример требования с критериями приёмки. Показать быстрее, чем рассказать.

5. Освежите терминологию стека из вакансии. Указан Kafka — вспомните про гарантии доставки и партиционирование. Указан Postgres — про уровни изоляции.

6. Подготовьте вопросы к команде. Кто пишет требования сейчас, как устроена приёмка, есть ли архитектор, что с техдолгом в документации. Эти вопросы заодно покажут ваш уровень.

Ошибки, из-за которых отказывают сильным аналитикам

1. Начал решать молча. Ход мысли не виден, оценивать нечего. Верный итог при этом спасает не всегда.

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

3. Ответ «зависит» без продолжения. Формально верно, содержательно пусто. Работает только конструкция «зависит от того-то; если так — делаю это, если иначе — то».

4. Неумение сказать «не знаю». Выдумка вскрывается уточняющим вопросом и обесценивает всё сказанное до неё.

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

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

1. Сколько длится техническое интервью и из чего состоит?

   Собеседование на системного аналитика в технической части обычно занимает 60–90 минут: пять тематических блоков (требования, нотации, БД и SQL, интеграции, архитектура и НФТ) плюс практическая задача. Состав и акценты зависят от проекта: в интеграционных проектах секция про API занимает до трети времени, в продуктовых больше спрашивают про работу с требованиями.

2. Нужно ли аналитику писать SQL наизусть?

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

3. Дают ли тестовое задание и сколько времени на него уходит?

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

4. Что отвечать, если нет опыта с нужной технологией?

   Сказать прямо и перенести на смежный опыт: «с Kafka не работал, работал с RabbitMQ — задача была такая, гарантии доставки настраивали так; разница, насколько понимаю, вот в этом». Такой ответ показывает и границы знания, и способность переносить опыт. Импровизация вместо признания вскрывается следующим вопросом.

5. Спрашивают ли у аналитика про код и языки программирования?

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

6. Можно ли пользоваться ИИ при выполнении тестового?

   Единой нормы на рынке нет: одни компании запрещают, другие допускают при условии, что вы объясните каждое решение. По публикации РБК от января 2026 года есть случаи найма специалистов без базовых навыков, прошедших тестирование с помощью ИИ, — из-за этого требования ужесточаются. Спросите правила у рекрутера заранее: несогласованное использование выясняется на защите решения.