Собеседование системного аналитика: вопросы, ошибки API и учебный кейс

Семь вопросов системному аналитику

Это учебные вопросы, а не требования или программа собеседования конкретного работодателя.

1. Что входит в контракт API?

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

2. Чем 201 отличается от 202?

   201 сообщает о создании ресурса. 202 — о принятии запроса на обработку; результат работы ещё может быть неизвестен. Для отложенной операции нужен способ проверить состояние.

3. Как описать ошибку?

   Свяжите HTTP-статус с конкретным сценарием и стабильным машинным кодом. Клиенту должно быть понятно, что исправить; внутренние трассировки и персональные данные в ответ не нужны.

4. Зачем нужен ключ идемпотентности?

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

5. Что показать на ER-диаграмме?

   Сущности, ключи, связи и ограничения с объяснением бизнес-смысла. Укажите, какая запись может отсутствовать и какие связи обязательны.

6. Чем sequence diagram дополняет контракт?

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

7. Что делать с неясным правилом?

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

Кейс: запрос на создание брони ушёл, а ответ потерян

Вымышленный пример. Клиент отправил создание бронирования и получил тайм-аут. Неизвестно, успел ли сервер сохранить запись.

Тайм-аут не доказывает отказ до записи. Новый независимый POST может создать вторую бронь. Сначала выясните, есть ли ID операции, ключ идемпотентности и разрешённый способ чтения результата.

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

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

Пример вопроса про данные и SQL

Есть учебные таблицы Room(id, name) и Booking(id, room_id, status). Нужно показать все комнаты и число активных бронирований, включая комнаты без броней.

SELECT r.id, r.name, COUNT(b.id) AS active_count
FROM Room AS r
LEFT JOIN Booking AS b
  ON b.room_id = r.id AND b.status = 'active'
GROUP BY r.id, r.name;

Здесь считают b.id, а не все строки соединения. Условие статуса находится в ON, чтобы комнаты без активных броней остались в результате. Проверьте пустую таблицу бронирований, только отменённую бронь и несколько активных записей.

Не объявляйте этот запрос проверкой конфликтов времени: для неё нужны интервалы и отдельное правило. Полный учебный набор правил и контракта есть в примере портфолио СА.

Как оценить свой ответ

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

Подготовьте рассказ об одном своём решении: какие варианты рассмотрели, почему выбрали этот и что осталось непроверенным. Не заучивайте чужой проект как собственный.