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

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

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

flowchart TD
  A["Старт собеседования"] --> B["1. HR-скрининг"]
  B --> C["2. Технический блок"]
  C --> D["3. Практическая задача"]
  D --> E["4. Кейс-интервью"]
  E --> F["5. Встреча с командой"]
  F --> G["Оффер"]

  C --> C1["SQL: JOIN, GROUP BY, оконные функции"]
  C --> C2["REST API: методы, коды ответов"]
  C --> C3["Моделирование: диаграммы и нотации"]
  C --> C4["Требования: User Story, Use Case"]

  D --> D1["Спроектировать API-контракт"]
  D --> D2["Запрос на выборку данных"]
  D --> D3["Нарисовать диаграмму"]

  E --> E1["Разбор конфликта требований"]
  E --> E2["Приоритизация и обоснование"]
  E --> E3["Работа с проблемным стейкхолдером"]

  style A fill:#e0e0e0,stroke:#999,color:#333
  style B fill:#e0e0e0,stroke:#999,color:#333
  style C fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style D fill:#f0a500,stroke:#c88400,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style G fill:#50c878,stroke:#3a9a5c,color:#fff
  style C1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C2 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C3 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style C4 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style D1 fill:#f0a500,stroke:#c88400,color:#fff
  style D2 fill:#f0a500,stroke:#c88400,color:#fff
  style D3 fill:#f0a500,stroke:#c88400,color:#fff
  style E1 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E2 fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E3 fill:#7b68ee,stroke:#5a4db2,color:#fff

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

Этап 1: HR-скрининг — не сливайте на старте

Да, это формальность. Но формальность, на которой отсеивают. 15–20 минут по телефону или в зуме. Вопросы простые: «Почему вы хотите быть аналитиком?», «Что знаете о компании?», «Какая у вас зарплатная вилка?»

Ошибка новичка — отвечать как на исповеди. «Ну, я курсы прошёл, вроде интересно, давайте попробуем». HR слышит: «Я не уверен в своём выборе, возьмите меня на тест-драйв». Никто не хочет быть тестовым полигоном.

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

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

Этап 2: Технический блок — здесь ломаются копья

Техническое интервью проводит ведущий аналитик или тимлид. 40–60 минут. Формат — смесь теории и задач. Не экзамен: собеседующий не сверяет ответы с методичкой. Он смотрит, как вы думаете.

SQL — вас спросят без вариантов

Я не встречал ни одной компании, где аналитику не задали бы SQL. Даже если в вакансии написано «работа с требованиями, код не пишем». SQL проверяют.

Типичный вопрос: «Даны таблицы orders, order_items и products. Покажите топ-5 товаров по выручке за последний месяц».

Плохой ответ: «Я не силён в SQL, обычно этим разработчики занимаются». Хороший: не молчать. Начните с «Я напишу примерно так…» и изложите ход мысли: соединить таблицы через JOIN, сгруппировать по product_id, взять SUM по price * quantity, отфильтровать по дате, отсортировать по убыванию и взять TOP 5. Даже если точный синтаксис WHERE или оконной функции вылетел из головы — ход мысли верный, и это ценят.

Второй по популярности вопрос: «Чем LEFT JOIN отличается от INNER JOIN? Когда какой применяете?»

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

REST API — основа интеграций

Без понимания API вы не спроектируете взаимодействие систем. На собеседовании проверят базу.

Базовые вопросы:

• «Какие HTTP-методы знаете и когда какой применяете?»
• «Что возвращает сервер при успешном создании ресурса?»
• «Чем PUT отличается от PATCH?»

Если на вопросе про коды ответов вы зависаете — рекомендую держать в закладках справочник HTTP-кодов. На собеседовании, конечно, закладками не воспользуешься, но к собеседованию точно подготовишься. Минимум на память: 200, 201, 400, 404, 500 для junior. Для middle добавляются 202, 204, 409, 422.

Продвинутый вопрос: «Как бы вы спроектировали эндпоинт для получения списка заказов с фильтрацией и пагинацией?»

Ждут не синтаксис URL. Ждут, что вы скажете о GET /orders?status=active&page=2&limit=20, о том, что фильтры передаются в query-параметрах, что параметры пагинации — page/limit или offset/limit, что метаданные (общее количество, текущая страница) кладут в тело ответа или заголовки. И о сортировке не забудьте: ?sort=created_at&order=desc.

Моделирование — покажите, что диаграмма решает задачу

Вас попросят нарисовать диаграмму. Либо на доске (в офисе), либо в Miro (онлайн). Не важно где. Важно — как вы мыслите.

Типичная задача: «Опишите процесс оформления заказа в интернет-магазине. От корзины до получения».

Плохо: рисовать 15 стрелок без остановки, с кучей сущностей и не связанных блоков. Хорошо: сначала уточнить границы. «Какие системы участвуют? Есть ли интеграция со складом и платёжным шлюзом? Какой уровень детализации вам нужен?» Потом — набросать sequence-диаграмму: пользователь → фронт → API → сервис заказов → склад → платёжка. Показать асинхронность (заказ создан, но склад резервирует позже). Показать, где могут быть ошибки и как их обрабатывать.

Требования — User Story и Use Case

Напишут на доске: «Опишите требование для страницы профиля пользователя».

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

• User Story: «Я как зарегистрированный пользователь хочу видеть страницу профиля с моими данными, чтобы проверить актуальность информации».
• Acceptance Criteria (критерии приёмки): Given пользователь авторизован, When открывает /profile, Then видит имя, email, телефон, дату регистрации.
• Обработку граничных случаев: что показываем, если телефон не указан? А если аватар не загружен?

И про Use Case тоже спросят. Разница простая: User Story описывает ценность для пользователя, Use Case — последовательность шагов, включая альтернативные и ошибочные сценарии. Знать нужно оба.

Этап 3: Практическая задача — ваши руки под микроскопом

Третий этап — живая задача. 30–60 минут. Вам дают описание проблемы и ждут решения в реальном времени. Обычно это одно из трёх: спроектировать API-контракт, написать SQL-запрос на выборку с хитрыми условиями или нарисовать диаграмму по текстовому описанию.

Здесь ловушка — перфекционизм. Новичок пытается выдать идеальное решение, молчит 15 минут, а потом извиняется, что «не до конца продумал». Интервьюеру не нужно идеальное. Ему нужно увидеть ход мысли. А ход мысли видно только когда вы рассуждаете вслух.

Я на своих собеседованиях специально говорю: «Комментируйте всё, что делаете. Даже если сомневаетесь». Идеальный кандидат говорит так: «Я бы сделал эндпоинт POST /orders. В теле — items, delivery_address. Сразу думаю: а если товара нет на складе? Возвращать 409 Conflict с сообщением? Или создавать заказ со статусом pending и резервировать асинхронно через очередь? Второй вариант надёжнее, если склад может тормозить…»

Видите разницу? Кандидат не просто называет метод и URL. Он показывает, что думает о последствиях, об edge cases, о том, что пойдёт не так.

Самые частые форматы практических задач:

• API-контракт. «Спроектируйте REST API для библиотеки: добавление книги, поиск, выдача читателю, возврат». Ждут методы, URL-структуру, коды ответов, обработку ошибок (книга уже выдана — что вернуть?).
• SQL-задача. Дают схему из 3–5 таблиц и вопрос вроде «покажите клиентов, сделавших больше трёх заказов за последний квартал». Ждут JOIN, GROUP BY, HAVING, подзапрос или CTE.
• Диаграмма по тексту. «Опишите взаимодействие сервисов при создании заказа: фронт → API Gateway → сервис заказов → склад → служба доставки». Ждут sequence-диаграмму с таймаутами, альтернативными сценариями и обработкой отказов.

Этап 4: Кейс-интервью — проверка мягких навыков

Самый непредсказуемый этап. 45–60 минут. Вопросы звучат как ситуации из рабочей жизни, и правильного ответа на них не существует. Проверяют софт-скилы: как вы думаете в условиях неопределённости, как договариваетесь, как справляетесь с конфликтами.

Кейс 1: «Заказчик просит фичу X, разработчики говорят — три месяца, продакт настаивает — через две недели. Ваши действия?»

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

Хороший ответ: «Сначала разложу фичу на составляющие. Что из X критично для бизнеса? Можно ли сделать версию, которая закроет 80% ценности за 30% времени? Обсужу с разработчиками, что технически проще и быстрее. Предложу продакту MVP с дорожной картой: версия 1 через две недели, полная версия — в следующие два месяца. И зафиксирую в ADR, почему приняли именно такое решение».

Ключевой момент: вы не принимаете чью-то сторону. Вы находите компромисс.

Кейс 2: «Стейкхолдер не даёт конкретных требований. На все вопросы отвечает «сделайте как у конкурента» или «ну там понятно всё». Что делаете?»

Типичная ситуация. Плохой ответ: «Я задокументирую, что требований нет, и пусть тимлид разбирается». Ну серьёзно — зачем тогда в штате аналитик?

Хороший ответ: «Раз «как у конкурента» — сяду и изучу конкурента. Разложу их функциональность на атомы, приду к стейкхолдеру с конкретным списком: «вот это делаем, а вот это — нет?». Людям проще сказать «это не нужно», чем придумать с нуля. Ещё помогает сценарий: «Давайте представим, что пользователь Иван заходит в приложение и хочет сделать X. Что он видит на первом экране?» Когда стейкхолдер начинает представлять конкретного пользователя — формулировки становятся предметными».

Кейс 3: «Команда спорит о выборе технологии: REST vs gRPC для нового микросервиса. Ваша роль?»

Интервьюер проверяет, понимаете ли вы, что аналитик не просто «пишет требования». Он участвует в архитектурных решениях.

Плохой ответ: «Я запишу оба варианта и отдам на review архитектору». Хороший: «Спрошу: какой характер нагрузки, latency, объём данных? Синхронное или стриминговое взаимодействие? Кто потребители — внутренние сервисы или внешние клиенты? Если REST-подход и gRPC-подход валидны, сведу ключевых людей на встречу с конкретными критериями и зафиксирую решение в ADR. Если один из вариантов отпадает по объективным причинам — аргументирую на месте».

Этап 5: Встреча с командой — совпадение по вайбу

Финальный этап. 30–45 минут в зуме или в офисе. Присутствуют тимлид, продакт, ведущий разработчик — те, с кем вы будете работать каждый день. Технических вопросов почти нет. Скорее, разговор о вас как о человеке.

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

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

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

Типичные ошибки, которые режут глаза

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

Молчание. Интервью — не письменный экзамен. Если вы замолкаете на минуту-другую, интервьюер не знает: вы думаете, зависли или уже сдались. Говорите. Даже «сейчас подумаю над структурой, мне нужно несколько секунд» — уже лучше тишины.

Заученные определения. «REST — это архитектурный стиль взаимодействия компонентов распределённой системы…» — стоп. Интервьюер зевает. Скажите как человек: «REST — это когда сервер и клиент обмениваются данными через HTTP, используют глаголы вроде GET/POST/PUT, и каждый запрос самостоятельный». Потом добавьте пример. Определение никто не запомнит, пример — запомнят.

Неумение сказать «не знаю». Спросили про технологию, с которой вы не работали. Не надо угадывать. Скажите «С этой технологией я не работал, но знаком с аналогом: Kafka не трогал, но c RabbitMQ задачи решал». Это честно и показывает, что вы обучаемы. Гораздо лучше, чем нести дичь про партиции, которых в жизни не видел.

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

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

Чек-лист подготовки по грейдам

Не пытайтесь выучить всё. Сверьтесь с тем, что спрашивают на вашем уровне.

Junior

• Пишу SELECT с JOIN и GROUP BY — синтаксис помню без гугления
• Знаю методы REST API и когда какой применять
• Различаю коды ответов: 200, 201, 400, 404, 500
• Могу нарисовать sequence-диаграмму простого сценария
• Напишу User Story по шаблону «я как… хочу… чтобы…»
• Подготовил историю «почему я выбрал системный анализ»

Middle

• Оконные функции SQL — без подсказок
• Спроектирую REST API с пагинацией, фильтрацией и кодами ошибок
• BPMN-процесс с тремя участниками — задача на 20 минут
• Кейс со сложным стейкхолдером — устно
• Приоритизация бэклога и обоснование перед продактом
• Понимаю разницу между синхронным и асинхронным взаимодействием сервисов

Senior

• Выбираю архитектурный стиль под задачу и защищаю выбор
• Проектирую интеграции с учётом роста нагрузки
• Фасилитирую встречи с противоречивыми интересами
• Разбираю конфликт требований без эскалации
• Могу объяснить CTO, почему в нашем случае модульный монолит лучше микросервисов
• Есть кейс по менторству джунов или мидлов

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