Какие процессы в команде нравятся

Что проверяют

Как вы работаете в команде, где результат это не только код, но и эксперименты, данные и модели. Хотят понять, цените ли вы воспроизводимость и ревью или привыкли жить в личном ноутбуке. Следом часто спрашивают, как у вас модель попадала из эксперимента в прод.

Как отвечать

Выберите два-три процесса, которые вам действительно помогали, и объясните зачем:

• трекинг экспериментов: каждый запуск с параметрами, версией данных и метриками записан в MLflow или Weights & Biases. Через месяц можно ответить, почему выбрали именно эту модель;
• версионирование данных: DVC или снапшоты в хранилище. Без этого «метрика упала» нельзя отличить от «поменялась выборка»;
• ревью кода и постановки: пайплайны обучения живут в модулях, а не в ноутбуках, и проходят ревью как бэкенд. Отдельно смотрят, нет ли утечки таргета и честно ли разбиение по времени;
• договорённость о метриках: заранее решено, какая офлайн-метрика и какой результат A/B-теста считаются успехом, а не подбираются задним числом;
• регулярный разбор результатов: короткая встреча, где показывают и неудачные эксперименты. Отрицательный результат экономит коллегам недели.

Приведите свой пример: что было, что поменяли, что это дало. Цифры только свои, например сколько времени занимал путь от идеи до A/B-теста до и после изменений. Если опыта с командными процессами нет, скажем, вы работали один или в исследовательской группе, скажите прямо и расскажите, что делали сами для воспроизводимости: фиксировали сиды и версии библиотек, хранили конфиги рядом с кодом.

Где спотыкаются

Отвечают набором слов из Agile. Двухнедельный спринт плохо ложится на исследование с неизвестным исходом, и интервьюер ждёт, что вы это понимаете.

Выдумывают проценты вроде «время разработки сократилось на 30%». На вопрос о методике подсчёта такой ответ разваливается.

Говорят только о встречах и молчат о данных. Для ML-команды самый слабый процесс тот, который не отвечает на вопрос «на чём обучена модель, которая сейчас в проде».