Типовой кейс: спроектируйте систему бронирования

Финальный этап собеседования: «Спроектируйте систему бронирования переговорных» — и час на то, чтобы показать весь набор навыков сразу.

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

Как устроен кейс и что оценивают

Формулировка намеренно расплывчата: «нужна система бронирования переговорных для офиса компании». Оценивают четыре вещи: задаёте ли вы уточняющие вопросы до решения; двигаетесь ли структурно; вспоминаете ли про исключения и нефункциональные требования; можете ли объяснить компромисс.

Самая частая и самая дорогая ошибка — начать сразу проектировать экраны. Первые 5–10 минут должны быть вопросами.

Шаг 1. Уточняющие вопросы

Контекст и цель
• Какую проблему решаем: конфликты за переговорные, учёт загрузки
  или сокращение ручной работы администратора?
• Как это происходит сегодня и что именно не устраивает?

Масштаб
• Сколько переговорных, сотрудников, броней в день?
• Один офис или несколько, разные часовые пояса?

Пользователи и роли
• Кто бронирует: любой сотрудник или через ассистента?
• Нужна ли роль администратора: блокировка комнат, ремонт, уборка?

Правила предметной области
• Можно ли бронировать за коллегу? На повторяющиеся встречи?
• Есть ли приоритет у руководства, можно ли «выселить» чужую бронь?
• Максимальная длительность, горизонт бронирования, шаг сетки?
• Что делать с бронью, если встреча не состоялась?

Интеграции и ограничения
• Синхронизация с корпоративным календарём — обязательна?
• Есть ли SSO? Есть ли панели у входа в переговорные?
• Сроки, бюджет, есть ли уже выбранный стек?

Шаг 2. Границы и роли

Проговорите вслух, что входит в первую версию, а что нет. Это сразу поднимает уровень ответа:

В первой версии          Вне рамок первой версии
──────────────────────── ────────────────────────────────
поиск свободной комнаты  мобильное приложение
бронь на слот            панели у дверей переговорных
отмена и перенос         платные внешние переговорные
повторяющиеся встречи    аналитика загрузки по этажам
роль администратора      бронирование оборудования и кейтеринга
синхронизация с календарём (односторонняя)

Роли: Сотрудник, Ассистент (бронирует за других),
      Администратор (блокировка комнат, разбор конфликтов)

Шаг 3. Модель данных и ключевое правило

Достаточно 4–5 сущностей. Главное — назвать инвариант: две подтверждённые брони одной комнаты не могут пересекаться по времени. Это то самое место, где кейс проверяет вашу внимательность.

Room       (id, title, floor, capacity, has_screen, is_active)
Employee   (id, name, email, department)
Booking    (id, room_id, organizer_id, starts_at, ends_at,
            title, status, created_at)
Attendee   (booking_id, employee_id, response)
RoomBlock  (id, room_id, starts_at, ends_at, reason)  ← ремонт, уборка

Инвариант: для одной room_id интервалы [starts_at, ends_at)
броней со статусом confirmed не пересекаются.
Полуинтервал важен: бронь 10:00–11:00 и 11:00–12:00 не конфликтуют.

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

Шаг 4. Основной сценарий и — обязательно — конфликты

Проверка пересечения обязана выполняться на сервере в транзакции, а не только в интерфейсе: два человека могут нажать «Забронировать» одновременно.

POST /rooms/12/bookings
Idempotency-Key: 5b2e...
{ "startsAt": "2026-03-05T09:00:00Z",
  "endsAt":   "2026-03-05T10:00:00Z",
  "title": "Планёрка", "attendees": [7, 15] }

201 Created  → бронь создана
409 Conflict → { "code": "ROOM_BUSY",
                 "detail": "Комната занята с 09:30 до 10:30",
                 "alternatives": [
                   { "roomId": 12, "startsAt": "2026-03-05T10:30:00Z" },
                   { "roomId": 14, "startsAt": "2026-03-05T09:00:00Z" }
                 ] }
422          → длительность превышает лимит 4 часа
403          → бронирование за другого недоступно этой роли

Поле alternatives в ошибке — деталь, за которую цепляются интервьюеры: она показывает, что вы думаете о пользователе, а не только о валидации.

Шаг 5. Нефункциональные требования и крайние случаи

  • Поиск свободных слотов на день — не более 1 с при 60 комнатах и 3000 броней в неделю.
  • Доступность в рабочие часы 99,9%; недоступность системы не должна блокировать вход в комнаты.
  • Переход на летнее время, брони на границе суток, встречи через полночь.
  • Уволенный сотрудник: что делать с его будущими бронями — передать организатору или отменить с уведомлением?
  • Комната выведена в ремонт: существующие брони отменяются с уведомлением и предложением альтернатив.
  • Массовая отмена повторяющейся серии: только это событие или все будущие?

Типичные ошибки кандидатов

  • Сразу рисуют интерфейс, не задав ни одного вопроса о задаче.
  • Не называют инвариант непересечения и проверку на стороне сервера — самое сердце этой задачи.
  • Забывают про повторяющиеся встречи и про то, что редактирование серии — отдельный сценарий.
  • Игнорируют часовые пояса и переход на летнее время.
  • Не задают ни одного нефункционального требования.
  • Молчат и думают про себя. На кейсе мысли надо проговаривать: оценивают именно ход рассуждения.
  • Стесняются сказать «я не знаю, я бы уточнил у …» — а это как раз сильный ответ, если сказано с планом, у кого и что уточнять.

Как ответить кратко

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

Проверьте себя
1. С чего правильно начать решение кейса «спроектируйте систему бронирования переговорных»?
AС набросков экранов и пользовательского пути
BС уточняющих вопросов о проблеме, масштабе, ролях и правилах бронирования
CС выбора базы данных и архитектурного стиля
DС оценки сроков и состава команды
2. Какой инвариант является сердцем задачи о бронировании переговорных?
AУ каждой брони должен быть организатор из числа сотрудников
BПодтверждённые брони одной комнаты не пересекаются по времени, и проверка выполняется на сервере в транзакции
CДлительность брони не превышает четырёх часов
DКомната не может быть забронирована в нерабочее время
3. Какой ответ на кейсе интервьюер оценит как сильный?
AМолча продумать решение целиком и изложить готовый результат
BПроговаривать ход рассуждения вслух и честно сказать, чего не знаете и у кого это уточните
CПредложить максимально полный функционал, чтобы закрыть все возможные пожелания
DСразу назвать конкретный технологический стек