Собеседование системного аналитика: архитектура, события и SQL

На собеседовании начинающего системного аналитика проверяли роль аналитика в команде, прототипирование, архитектуру, события и SQL. Компания не названа. Вопросов много, поэтому мы объединили их в смысловые группы и сохранили последовательность разговора внутри каждой группы.

Чем системный анализ отличается от бизнес-анализа

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

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

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

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

Что такое прототип и жизненный цикл

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

Цикл разработки охватывает путь от требований до выпуска конкретного изменения. Жизненный цикл ПО шире: планирование, разработка, эксплуатация, развитие и вывод из использования. Поэтому работа аналитика не заканчивается передачей ТЗ разработчику. После запуска приходят метрики, ошибки и новые требования.

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

Как объяснить архитектуру, нотации и события

В трёхуровневой архитектуре разделяют представление, бизнес-логику и данные. Это не обязательно три физических сервера: речь прежде всего о разных обязанностях компонентов.

Интерфейс обращается к логике приложения, а та работает со слоем данных. Источник: Fahrenheit Rus, Wikimedia Commons, CC BY-SA 3.0.

Нотацию выбирают по вопросу. BPMN показывает бизнес-процесс, UML sequence — порядок сообщений, ER-диаграмма — сущности и связи. Официальные спецификации доступны у Object Management Group для UML и BPMN.

Событие — зафиксированный факт изменения: OrderCreated, а не команда CreateOrder. Аналитик описывает источник, схему, обязательные поля, версию, потребителей, порядок и реакцию на повтор.

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

Как работают оконные функции

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

SELECT
  client_id,
  order_id,
  ROW_NUMBER() OVER (
    PARTITION BY client_id
    ORDER BY created_at DESC
  ) AS order_number
FROM orders;

В отличие от GROUP BY, результат сохраняет каждую строку. Это ключевое различие также показано в документации PostgreSQL.

Коротко: оконная функция считает значение по связанным строкам и при этом сохраняет каждую строку результата.

Чем отличаются CROSS, INNER и FULL JOIN

CROSS JOIN создаёт декартово произведение: каждую строку первой таблицы соединяет с каждой строкой второй. INNER JOIN оставляет только пары, которые прошли условие. Поэтому его можно выразить через CROSS JOIN и WHERE, хотя явный JOIN ... ON читается лучше:

SELECT users.id, orders.id
FROM users
CROSS JOIN orders
WHERE users.id = orders.user_id;

FULL JOIN сохраняет совпавшие пары и несовпавшие строки обеих таблиц, заполняя отсутствующую сторону NULL. В руководстве PostgreSQL соединения объясняются именно через пары строк и условие.

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

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

Что ответить про индекс, PRIMARY KEY и ALTER TABLE

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

PRIMARY KEY однозначно идентифицирует строку и не допускает NULL. Составной первичный ключ включает несколько столбцов. ALTER TABLE меняет схему: добавляет или удаляет столбец, ограничение или индекс. В рабочей системе такое изменение планируют с учётом блокировок, старого кода и обратной совместимости.

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

Итог: получил бы кандидат оффер

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

Наш вывод — скорее не получил бы оффер на самостоятельную позицию. Для стажировки шанс остаётся, если команда готова обучать. Усилить результат можно одним способом: к каждому термину подготовить рабочий артефакт и пример решения, а SQL отрабатывать руками.

Коротко: результат не раскрыт; по показанным ответам кандидат скорее не получил бы оффер без более точных примеров и SQL-практики.

Чек-лист подготовки

• Объясняю границу бизнес- и системного анализа на одном кейсе.
• Выбираю диаграмму под конкретный вопрос.
• Описываю контракт события и повторную доставку.
• Пишу оконную функцию без подсказки.
• Предсказываю число строк после JOIN.
• Объясняю цену индекса при записи.

Источники

• OMG: спецификация UML 2.5.1
• OMG: спецификация BPMN 2.0.2
• PostgreSQL: оконные функции
• PostgreSQL: соединения таблиц
• Wikimedia Commons: схема трёхуровневой архитектуры