Приходилось ли работать с методологиями разработки
Что проверяют
Сможете ли вы работать внутри командного процесса и понимаете ли, чем задачи с данными и моделями отличаются от обычной разработки. Вопрос почти всегда про реальный опыт, а не про определения: интервьюер хочет услышать, как у вас планировались исследовательские задачи, у которых нет предсказуемого срока.
Как отвечать
Назовите процесс, в котором действительно работали, и его артефакты: доска задач, бэклог, дейли, демонстрация результата, ретроспектива. Дальше про специфику работы с данными:
- исследование и продакшн живут по разным правилам. Гипотезу берут таймбоксом (пара дней и решение, продолжать или нет), инженерную задачу оценивают как обычно;
- Kanban с лимитом незавершённой работы часто удобнее Scrum для дата-команды: поток задач неровный, а обязательство на спринт по исследовательской задаче регулярно не выполняется;
- условие готовности для модели формулируется заранее: метрика на отложенной выборке, воспроизводимый пайплайн, зафиксированная версия данных, модель в реестре, а не «у меня в ноутбуке работает»;
- CRISP-DM как рамка проекта (понимание задачи, данные, моделирование, оценка, внедрение) полезен, но это цикл проекта, а не замена командному процессу.
Говорите честно, что было и чего не было. Ответ «работали по Kanban, ретроспективы проводили нерегулярно, оценки давали только по инженерным задачам» звучит сильнее пересказа Agile-манифеста.
Где спотыкаются
Пересказывают теорию: церемонии, роли, гибкость и взаимодействие. Это ответ на вопрос «знаете ли вы, что такое Scrum», а спросили про ваш опыт и про то, что из процесса реально помогало.
Второе: приписывают себе внедрение методологии в одиночку и подкрепляют выдуманным ростом производительности команды. Такую цифру никто не мерил, и следующий вопрос будет именно про методику замера.
Третье: обещают точный срок для задачи вида «улучшить качество модели». Такой задаче нужен не срок, а таймбокс и критерий остановки, иначе она молча съедает спринт целиком.