Типовой кейс: спроектируйте систему бронирования
Финальный этап собеседования: «Спроектируйте систему бронирования переговорных» — и час на то, чтобы показать весь набор навыков сразу.
Кейс проверяет не правильный ответ — его не существует, — а ход мысли: как вы уточняете задачу, какие вопросы задаёте, как обосновываете решения и признаёте ограничения.
Как устроен кейс и что оценивают
Формулировка намеренно расплывчата: «нужна система бронирования переговорных для офиса компании». Оценивают четыре вещи: задаёте ли вы уточняющие вопросы до решения; двигаетесь ли структурно; вспоминаете ли про исключения и нефункциональные требования; можете ли объяснить компромисс.
Самая частая и самая дорогая ошибка — начать сразу проектировать экраны. Первые 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 отдаю альтернативные слоты. Обязательно проговариваю нефункциональные требования и крайние случаи: часовые пояса и переход на летнее время, повторяющиеся встречи и правку серии, увольнение организатора, вывод комнаты в ремонт. И рассуждаю вслух — на кейсе оценивают ход мысли, а не единственно верный ответ.