Как подготовиться к собеседованию системному аналитику? Вопросы и темы
К собеседованию системного аналитика готовятся по тексту вакансии: из неё берут список тем (требования, моделирование процессов, API и интеграции, SQL) и повторяют их на примерах. Отдельно заранее собирают рассказ о проектах с указанием личной роли. Интервью обычно проходит в три этапа: HR-скрининг, техническая часть с теорией и практическими задачами, встреча с командой, причём больше всего кандидатов отсеивается на технической части.
Содержание статьи
- Выпишите из вакансии технологии и обязанности и сопоставьте каждую с темой для повторения.
- Подготовьте рассказ о проектах на пять минут: контекст, ваша роль, действия и проверяемый итог.
- Повторите виды требований, нотации BPMN и UML, методы HTTP, коды ответов и запросы SQL с JOIN.
- Отрабатывайте кейс вслух: сначала уточните условия, затем назовите сущности, затем предложите решение.
- Составьте пять-семь вопросов о команде, документации и первых месяцах работы.
Разговор на интервью строится вокруг резюме, поэтому его сверяют с вакансией до начала подготовки: роль, стек и проекты в документе должны совпадать с тем, что вы собираетесь рассказывать. Документ удобно собрать по образцу резюме и держать открытым во время разговора, ведь интервьюер сверяет ваши слова с написанным, а расхождение снижает доверие к остальным ответам.
Как изучить требования вакансии системного аналитика?
Требования вакансии системного аналитика изучают по тексту объявления: из каждой строки выписывают технологию или обязанность и сопоставляют её с темой для повторения. Это нужно потому, что границы роли в компаниях проведены по-разному: в одной аналитик ведёт документацию по ГОСТ, в другой проектирует API, в третьей совмещает работу с бизнес-аналитиком.
Работа с текстом вакансии занимает около часа и состоит из пяти шагов:
- Подчеркните все технологии и нотации: REST, SOAP, SQL, BPMN, UML, Jira, Confluence.
- Отметьте обязанности: сбор требований, описание интеграций, ведение документации, участие в проектировании.
- Найдите слова о предметной области (банк, торговля, логистика) и прочитайте о продуктах компании.
- Для каждой отметки запишите один пример из рабочего или учебного опыта.
- Выберите три темы, где знаний меньше всего, и повторите их первыми.
Если границы роли в объявлении расплывчаты, их уточняют у рекрутера заранее: нужно выяснить, дают ли готовое техническое задание или требования придётся собирать у заказчика. Общий порядок подготовки к любому интервью описан в статье о том, как подготовиться к собеседованию.
Как подготовить рассказ о проектах и личной роли?
Рассказ о проектах и личной роли готовят как монолог на пять минут: кто вы, какие задачи решали, какой была ваша часть работы и чем всё закончилось. В рассказ берут проекты, похожие на будущие задачи. Каждый проект делят на три части: контекст («на прошлом проекте мы переводили выгрузки заказов в API»), действие («я описала процесс и нарисовала диаграмму последовательности») и результат с цифрой.
Пример · условные данные. Кандидат Андрей рассказывает об интеграции с платёжным сервисом в условной компании «Север-Платёж».
«Мы делали интеграцию с платёжным сервисом, я участвовал в описании и общался с командой.»
«Я был единственным аналитиком на интеграции с платёжным сервисом: описал три метода API, согласовал с разработкой коды ошибок и построил диаграмму последовательности. После запуска доля отказов из-за неверных данных снизилась с 7% до 2%.»
После размытого «мы» интервьюер почти всегда спрашивает, какую часть работы кандидат выполнил лично. Ответ называет документы и решения: контракт метода, схему процесса, список требований с критериями приёмки. Проект, в котором вы не участвовали, в рассказ не включают, потому что при первом вопросе о деталях расхождение станет заметным.
Рассказ должен совпадать с резюме, и резюме удобнее подготовить заранее: его можно собрать в конструкторе резюме онлайн и перечитать за день до встречи.
Какие вопросы задают о сборе требований?
О сборе требований на интервью спрашивают про виды требований, способы их выявления и проверку, потому что работа с требованиями лежит в основе профессии. Требования принято делить на бизнес-требования, пользовательские и функциональные, к ним добавляют нефункциональные, и отвечать стоит в этой логике.
Выявление потребностей заказчика
Выявление потребностей заказчика проверяют вопросом о том, что вам потребуется, чтобы спроектировать названную систему. Сильный ответ начинается с уточнений: кто пользователи, какую проблему решает система, сколько данных и пользователей ожидается. Среди способов выявления требований называют беседу с представителями бизнеса, разговор с группой пользователей, метод «5 почему» и карту пути клиента.
Пользователи часто сразу предлагают решение, а аналитик выясняет причину. Если менеджер просит добавить в форму поле «Комментарий», потому что пожелания клиентов приходится вносить в чат, потребность состоит в хранении пожеланий в карточке заказа.
Проверка и согласование требований
Проверка и согласование требований сводятся к трём вопросам: понятна ли формулировка, можно ли проверить выполнение и нет ли противоречия с другими требованиями. Нефункциональные требования записывают числами. Условный пример для учебного приложения доставки продуктов: карточка товара открывается за одну секунду, экран списка выдерживает заданное число запросов в секунду, а само число согласуют с командой.
Если аналитик находит противоречие, он сначала обсуждает его с заказчиком и фиксирует принятое решение в документе. Ответ «сделаю, как попросили» на вопрос об изменении требований в разгаре разработки считается слабым, потому что кандидат не оценивает последствия.
Что повторить о моделировании процессов?
О моделировании процессов повторяют нотации BPMN и UML и умение объяснить готовую диаграмму человеку без технической подготовки. Практическое задание обычно короткое: нарисовать процесс по описанию и ответить на вопросы о каждом элементе.
Описание процесса и участников
Описание процесса и участников начинается с вопроса о том, кто и какие действия выполняет, и лишь затем переходит к рисунку. Для заказа в интернет-магазине участниками будут покупатель, магазин, платёжный сервис и склад, а основным сценарием станет путь от оформления заказа до отгрузки.
Альтернативные сценарии показывают зрелость кандидата сильнее основного: платёж отклонён, товара нет на складе, покупатель отменил заказ. Для тренировки подходит бытовой процесс, например снятие денег в банкомате с вариантами неверного пин-кода и пустого банкомата. Ещё интервьюер может попросить объяснить диаграмму так, будто заказчик позвонил и спросил, как её читать, и ответ нужно дать без терминов.
Выбор нотации и уровня детализации
Нотацию и уровень детализации выбирают под задачу и под читателя диаграммы. BPMN создавали так, чтобы её могли использовать сами участники бизнес-процессов, а UML применяют, когда нужно показать обмен сообщениями между системами и устройство данных.
| Нотация | Что показывает | Когда выбирать |
|---|---|---|
| BPMN | Шаги процесса, роли участников, события и развилки | Объяснение процесса бизнесу и согласование регламента |
| UML Sequence (диаграмма последовательности) | Порядок запросов и ответов между системами во времени | Описание интеграции и работы API для разработчиков |
| ER-диаграмма | Сущности и связи между таблицами | Проектирование структуры базы данных |
Уровень детализации задают читателем: заказчику показывают крупные шаги и роли, разработчику добавляют вызовы между системами, форматы данных и ошибки. Интервьюер редко требует конкретную нотацию и смотрит, какими элементами кандидат наполнил диаграмму.
Совет редакции
Спросите у интервьюера разрешения показать диаграммы BPMN и UML Sequence, которые вы рисовали раньше. Разговор перейдёт к вашим работам, и вы сами выберете детали, в которых сильны.
Как подготовиться к вопросам об API и интеграциях?
К вопросам об API и интеграциях готовятся по трём направлениям: контракт метода, коды ответов и способ обмена данными между системами, синхронный или асинхронный. Диалог ниже показывает, как кандидат описывает метод и отвечает на уточнение интервьюера.
Интервьюер просит описать метод API
Контракты API и обмен данными
Контракт API и обмен данными описывают одним набором сведений: адрес и метод, входные параметры, успешный ответ и ошибки с примерами запроса и ответа в JSON. Для описания таких интерфейсов существует спецификация OpenAPI. Она задаёт стандартную запись, не зависящую от языка программирования, и позволяет понять, что умеет сервис, без доступа к исходному коду.
Получатель контракта (разработчик, тестировщик, команда смежной системы) должен суметь проверить каждую строку без вопросов к автору. Для проверки используют песочницу Swagger UI и программы для запросов вроде Postman: в них видно, как описаны параметры, и можно отправить тестовый запрос.
Типичная ошибка
В примере ответа остались настоящие имя и телефон клиента из тестовой базы. Документация попадает в чаты и на скриншоты, поэтому такие данные получает вся команда. Исправление: заменить значения вымышленными и убрать токены доступа из примеров.
Ошибки интеграции и обработка исключений
Ошибки интеграции и обработку исключений описывают через коды ответов и поведение системы при сбое. По стандарту HTTP коды 4xx сообщают об ошибке клиента, а 5xx говорят, что сервер ошибся или не справился, и для каждого кода в требованиях записывают, что видит вызывающая система.
| Код | Значение | Что описать в требованиях |
|---|---|---|
| 400 | Сервер не может или не станет обрабатывать запрос из-за ошибки клиента, например неверного синтаксиса | Формат входных данных и текст сообщения об ошибке |
| 401 | В запросе нет действительных данных для аутентификации | Способ авторизации и срок действия токена |
| 404 | Сервер не нашёл ресурс, который запросили | Что возвращать для несуществующего идентификатора |
| 422 | Синтаксис верный, но обработать содержание запроса не удалось | Бизнес-проверки, например заказ уже оплачен |
| 500 | На сервере возникла непредвиденная ситуация | Повтор запроса, журнал ошибок, уведомление дежурных |
Повтор запроса после сбоя ведёт к вопросу об идемпотентности: при потерянном ответе клиент отправит тот же запрос ещё раз, и оплата не должна списать деньги дважды.
Термин · идемпотентный метод
Метод, у которого несколько одинаковых запросов дают тот же эффект на сервере, что и один. В HTTP к идемпотентным относятся PUT, DELETE и безопасные методы вроде GET, а POST в этот перечень не входит.
С асинхронными интеграциями связан второй типичный вопрос: чем обмен через очередь сообщений отличается от прямого вызова. Хороший ответ даёт живой пример: при подаче заявки на кредит клиент не ждёт решение пятнадцать минут, система сразу отвечает, что заявка принята, а результат приходит позже в SMS.
Какие задачи могут дать по базам данных?
По базам данных системному аналитику дают задачи двух видов: спроектировать структуру таблиц со связями и написать запрос SQL с объяснением результата. Оба вида проверяют, умеет ли кандидат переводить описание предметной области в данные.
Структура данных и связи
Структуру данных и связи на интервью проверяют просьбой выделить сущности и показать, как таблицы соединены. Для системы бронирования авиабилетов это авиабилет, профиль пользователя, покупки и атрибуты билета, а кандидата просят назвать типы связей (один к одному, один ко многим, многие ко многим).
Для интернет-магазина безопасный вариант строится так: клиент связан с заказами связью «один ко многим», а заказ с товарами связью «многие ко многим» через отдельную таблицу позиций. Типичная ошибка состоит в хранении списка товаров в одном текстовом поле, потому что по такому полю нельзя сделать выборку и посчитать количество.
SQL-запрос и объяснение результата
SQL-запрос и объяснение результата проверяют на небольшой задаче, например найти по таблице сотрудников максимальную или среднюю зарплату, а затем пересказать, что вернёт запрос. Редакционный совет для начинающего аналитика: отработать SELECT с WHERE, сортировку, группировку с HAVING и различия между типами JOIN; точный уровень зависит от вакансии.
| Тип соединения | Что попадает в результат | Пример |
|---|---|---|
| INNER JOIN | Только строки, для которых нашлась пара в обеих таблицах | Клиенты, у которых есть хотя бы один заказ |
| LEFT JOIN | Все строки левой таблицы, недостающие значения правой пустые | Все клиенты, а у тех, кто ничего не заказывал, поле заказа пустое |
| FULL JOIN | Все строки обеих таблиц с пустыми значениями там, где пары нет | Сверка клиентов и заказов в обе стороны |
Пример · условные данные
Исходные условия. Даны таблицы employees (id, name, department_id, salary) и departments (id, name). Нужно вывести максимальную зарплату в каждом отделе.
Запрос и объяснение. SELECT d.name, MAX(e.salary) FROM employees e JOIN departments d ON d.id = e.department_id GROUP BY d.name. Результат содержит по одной строке на отдел. Сотрудники без отдела в него не попадут, потому что JOIN без уточнения работает как внутреннее соединение.
Как рассуждать над практическим кейсом?
Над практическим кейсом рассуждают вслух по четырём шагам: уточняют условия, называют сущности и участников, предлагают решение с вариантами и проверяют его на ошибочных сценариях. Интервьюеру важен ход мысли, поэтому рассуждать нужно вслух.
Кейс: онлайн-бронирование авиабилетов
Условия задачи полезно уточнять несколько раз по ходу решения, и у большинства задач есть несколько верных решений. Кандидат называет два-три варианта и объясняет, почему выбирает один. Если для ответа не хватает знаний, честнее сказать об этом и продолжить рассуждение: совместными усилиями с интервьюером обычно приходят к ответу.
Когда заказчик просит добавить новую функцию незадолго до релиза, покорное согласие считается слабой реакцией: аналитик уточняет цель, оценивает влияние на сроки и предлагает вариант, который решает задачу бизнеса. Другие типы вопросов интервью перечислены в статье о том, какие вопросы задают на собеседовании.
Совет редакции
Тренируйте кейс на приложении, которым пользуетесь каждый день: опишите для одной функции три функциональных и два нефункциональных требования с числами и попросите знакомого найти в них противоречия.
Какие вопросы задать о команде и документации?
О команде и документации задают пять-семь вопросов в конце интервью, когда интервьюер оставляет время для кандидата.
- С какими системами и проектами предстоит работать в первые месяцы?
- Какие методологии разработки используются в команде и какую роль в них играет аналитик?
- Где хранятся требования и кто обновляет документацию после изменений?
- В каком формате аналитик ставит задачи разработчикам и на каком уровне детализации?
- Чего ждут от аналитика в первый месяц работы и в первые полгода?
Вопросы о зарплате и отпуске на первой встрече лучше отложить до финальной стадии, потому что они уводят разговор от рабочих задач. Вопросы о документации особенно полезны системному аналитику: ответ показывает, ведётся ли в команде единое описание требований или всё хранится в переписке.
Ответ интервьюера проверяют так же, как свой: сверяют с вакансией, записывают и пересказывают, чтобы убедиться, что поняли его верно. Если ответ расплывчат, например «документация есть, но не вся», помогает уточнение, где она лежит и кто за неё отвечает. Фраза «всё знает один человек» даёт повод спросить, как новичок получает контекст в первый месяц.
Частые вопросы
Частые вопросы о собеседовании системного аналитика собраны здесь: три ответа на то, что остаётся у кандидатов после чтения разделов выше.
Нужно ли знать все нотации?
Знать все нотации не нужно: достаточно уверенно владеть одной-двумя и уметь объяснить выбор. Новичкам на интервью часто предлагают нарисовать диаграмму последовательности UML, но точный набор нотаций задаёт вакансия (редакционное наблюдение, не требование).
Что сказать без коммерческого опыта?
Без коммерческого опыта рассказывают об учебных проектах так же, как о рабочих: контекст, ваша роль, действия и итог, например описанный API тренировочного сервиса и диаграмма к нему. Честно скажите, что опыт учебный, и покажите результат: документ, схему или запрос. Как построить такой рассказ, описано в статье о том, что рассказать о себе на собеседовании.
Как подготовить примеры проектов?
Примеры проектов готовят по схеме «контекст, роль, действия, результат» и записывают по одному на каждую тему вакансии: требования, моделирование, API, SQL. К каждому примеру держат под рукой диаграмму или документ, которые можно показать, если интервьюер разрешит.