Есть ли жесткая привязка ко времени в команде
Что проверяют
Под этим вопросом обычно две вещи: как вы относитесь к фиксированному графику (ядро рабочего времени, стендап в 10:00, дежурства) и как работаете со сроками. Интервьюер сверяет ваши ожидания с устройством команды, чтобы через месяц не выяснилось, что вы рассчитывали на свободный график. Часто тот же вопрос задаёт кандидат, и тогда по нему видно, что для вас важно.
Как отвечать
Если непонятно, о чём речь, уточните: о часах работы или о дедлайнах. Дальше каркас:
- ваш режим: в какие часы вы продуктивны и какое пересечение с командой готовы гарантировать. Например: «Удобно с 10 до 19, ядро с 11 до 16 соблюдаю без проблем»;
- обязательные точки: стендапы, планирование спринта, релизные окна. К ним вы подстраиваетесь, это нормальная часть командной работы;
- дежурства: для .NET-бэкенда в продакшене это частая история. Если готовы к on-call, скажите, на каких условиях: график, компенсация, время реакции;
- сроки: как вы оцениваете задачи, когда предупреждаете о риске срыва и что предлагаете взамен: урезать объём, сдвинуть срок, подключить ещё человека. Подкрепите коротким примером из своей практики: задача, срок, что пошло не так, как договорились.
Если вы работали только со свободным графиком, так и скажите и объясните, готовы ли к фиксированному. Честное «жёсткий старт в 9:00 мне не подойдёт» лучше, чем уход после испытательного срока.
Если вопрос задаёте вы, уточните: есть ли core hours, в каких часовых поясах команда, как часто бывают авралы перед релизом и чем они компенсируются.
Где спотыкаются
Отвечают «я гибкий, мне всё равно». Это не информация: интервьюер так и не понял, совпадают ли ожидания.
Рассказывают историю про героический аврал как про норму. Для многих команд регулярные переработки это сигнал проблемы, а не повод для гордости.
Не различают привязку ко времени и привязку к результату. Сильный ответ показывает, что фиксированные часы нужны для синхронизации, а сроки для предсказуемости, и обе вещи держатся на прозрачной коммуникации.