На собеседовании проверяли системного аналитика с практическим опытом интеграций. Вопросы быстро перешли от рассказа о себе к Kafka, REST, нефункциональным требованиям, SQL и рабочим артефактам. Личных данных участников мы не приводим: здесь важны сами вопросы и то, как на них отвечать.
Как отвечать про Kafka и интеграции
Вопрос: с какими способами интеграции вы работали?
Хороший ответ начинается не с длинного списка технологий, а с двух-трёх реальных сценариев. Например: синхронный REST-запрос использовали, когда вызывающей системе нужен немедленный ответ; Kafka — когда сервисы обмениваются событиями и не должны ждать друг друга.
В ответе про Kafka стоит назвать:
- бизнес-событие и его отправителя;
- схему сообщения и правила её изменения;
- топик, ключ партиционирования и группу потребителей;
- повторы, идемпотентность и обработку ошибочных сообщений;
- мониторинг задержки потребителей.
Документация Apache Kafka разделяет производителей, потребителей, топики и партиции. Эти понятия полезно объяснять через свой проект: кто публиковал событие, кто его читал и что происходило при сбое.
Вопрос: кто создавал топики и настраивал брокер?
Аналитику необязательно администрировать кластер. Но он должен понимать границу ответственности: кто согласует контракт, кто заводит топик, кто выдаёт доступ и какие параметры влияют на решение. Фраза «это делали DevOps» слабая. Сильнее: «Я описывал событие и требования, согласовывал схему с командами, а инфраструктурная команда создавала топик и права доступа».
Коротко: сильный ответ о Kafka связывает бизнес-событие, контракт сообщения, владельцев топиков и обработку ошибок.
Что должно быть в ТЗ на REST-сервис
Вопрос: может ли у GET-запроса быть тело?
Технически клиент способен отправить тело, но у содержимого GET нет общепринятой семантики. Некоторые реализации могут отвергнуть такой запрос. Поэтому параметры чтения безопаснее передавать через путь или query string, а сложный поиск оформлять отдельным ресурсом или POST-запросом. Это прямо оговорено в RFC 9110.
Вопрос: какие разделы включить в ТЗ?
Мы бы назвали назначение сервиса, границы ответственности, пользовательские сценарии, методы и модели данных, коды ответов, правила авторизации, ошибки, интеграции, NFR, логирование, мониторинг и критерии приёмки. Для каждого метода нужен контракт: вход, выход, обязательность полей, ограничения и примеры.
Не стоит превращать ответ в перечисление заголовков документа. Интервьюер хочет понять, сможет ли команда по вашему ТЗ реализовать сервис без серии догадок.
Коротко: ТЗ на REST-сервис должно описывать контракт API и проверяемые требования, а не только список методов.
Где фиксировать NFR и как говорить о микросервисах
Нефункциональные требования — производительность, доступность, восстановление, безопасность — сначала задают для системы или бизнес-сценария. Затем их раскладывают по сервисам. Если весь сценарий должен отвечать за две секунды, нельзя каждому из пяти последовательных сервисов обещать те же две секунды.
На вопрос о микросервисах лучше отвечать через границы: за какую бизнес-возможность отвечал сервис, какими данными владел, как общался с соседями и как команда наблюдала сбои. Слово «микросервис» само по себе ничего не доказывает.
Коротко: NFR фиксируют на уровне системы и уточняют для каждого сервиса, который влияет на общий показатель.
Как отвечать про оконные функции, нормализацию и JSONB
Вопрос: где применяли оконные функции?
Оконная функция считает значение по группе строк, но не сворачивает их в одну строку. Практический пример — выбрать последнюю операцию каждого клиента:
SELECT client_id, operation_id, created_at
FROM (
SELECT
client_id,
operation_id,
created_at,
ROW_NUMBER() OVER (
PARTITION BY client_id
ORDER BY created_at DESC
) AS position
FROM operations
) ranked
WHERE position = 1;
В документации PostgreSQL хорошо показана разница между оконными и обычными агрегатными функциями.
Вопрос: до какой формы нормализуете данные?
Правильного универсального числа нет. Для транзакционных данных обычно стремятся убрать дублирование и аномалии обновления, а затем осознанно денормализуют там, где это оправдано чтением. JSONB полезен для действительно гибких атрибутов, но не должен скрывать важные сущности и связи. PostgreSQL отдельно описывает возможности и ограничения типов JSON.
Коротко: в вопросах по SQL важно объяснить не термин, а задачу, ограничения и последствия выбранной модели данных.
Какие артефакты нужны команде
Для разработчиков аналитик готовит контракты API и событий, модели данных, схемы взаимодействия, бизнес-правила и сценарии. Для тестировщиков особенно важны критерии приёмки, проверки ошибок, граничные случаи и ожидаемые результаты.
Use Case можно показать диаграммой, а основной и альтернативные потоки описать текстом. Диаграмма быстро объясняет акторов и границы системы; сценарий сохраняет последовательность шагов и исключения.
Диаграмма показывает акторов и варианты использования; шаги сценария лучше описать рядом. Источник: PlantUML.
Если спрашивают о ГОСТах, называйте только стандарты, с которыми действительно работали. Для части государственных систем актуальны стандарты серии 34, но выдуманный номер выглядит хуже честного ответа об отсутствии практики.
Коротко: артефакты аналитика должны помогать разработчику реализовать решение, а тестировщику — проверить его.
Получил ли кандидат оффер
Да. В финале разбора прямо сказано, что кандидат получил оффер на 350 000 ₽. Ответы были неидеальными: не везде хватало конкретики, а вопрос про ГОСТ вызвал затруднение. При этом кандидат показал настоящий опыт, уверенно обсуждал артефакты и мог объяснить свою роль в проектах.
Это важный вывод для подготовки: интервью не требует энциклопедической безошибочности. Но каждый ответ должен давать интервьюеру основание доверить вам рабочую задачу. Мы рекомендуем тренироваться по схеме «контекст — действие — артефакт — результат — ограничение» и проговаривать ответы вслух.
Коротко: кандидат отвечал неровно, но показал реальный опыт и получил оффер на 350 000 ₽.
Чек-лист перед собеседованием
- Могу объяснить один синхронный и один событийный сценарий интеграции.
- Покажу, какие артефакты готовил лично.
- Объясню контракт REST-метода на конкретном примере.
- Приведу рабочий пример оконной функции.
- Назову NFR и способ их проверки.
- Честно обозначу темы, с которыми не работал.
Источники
частые вопросы
Короткие ответы
Какие темы повторить системному аналитику перед собеседованием?
Повторите интеграции, контракты REST и событий, NFR, SQL, моделирование данных, Use Case и набор артефактов для разработки и тестирования.
Нужно ли системному аналитику знать ГОСТы?
Это зависит от отрасли. В коммерческой разработке чаще проверяют практические артефакты, а в государственных и промышленных проектах знание стандартов может быть обязательным.
Как отвечать, если точный термин забылся?
Не придумывайте название. Объясните задачу, свой способ работы и границы знания, а затем уточните термин у интервьюера.
