Собеседование на Data Scientist
Exponential(λ). По выборке среднее время ожидания равно 5 секунд. Какая точечная оценка MLE для параметра λ?Что спрашивают на собесе у Data Scientist
Собеседование на Data Scientist — это марафон, а не спринт. От кандидата ждут не одной сильной стороны, а равномерного покрытия сразу нескольких областей: машинного обучения, статистики, программирования и продуктового мышления. Именно широта проверки отличает DS-собес от собеседования на аналитика данных, где центр тяжести — SQL и метрики. Здесь же провал в любом из блоков может перечеркнуть сильные ответы в остальных.
Хорошая новость: набор тем предсказуем. Интервьюеры из года в год возвращаются к одним и тем же концепциям, потому что именно они отделяют человека, который понимает модель, от того, кто запускал model.fit() по туториалу. Если разобрать эти блоки до уровня «могу объяснить вслух и на пальцах», большая часть собеседования становится управляемой.
ML-теория. Ядро DS-собеса. Сюда входят bias-variance trade-off, переобучение и способы с ним бороться, регуляризация L1/L2, принцип работы основных алгоритмов и интуиция за градиентным спуском. Вопросы редко требуют вывода формул — гораздо чаще просят объяснить, почему модель ведёт себя так, а не иначе, и что вы измените, если она не работает.
Классический ML. На практике большинство задач закрывается не нейросетями, а градиентным бустингом, логистической регрессией и деревьями. Спрашивают, чем бустинг отличается от случайного леса, когда линейная модель предпочтительнее, как устроен feature engineering и зачем нужно масштабирование признаков. Умение выбрать простой и подходящий алгоритм ценится выше, чем знание экзотики.
Статистика и эксперименты. DS обязан уверенно говорить о проверке гипотез, p-value, ошибках первого и второго рода, доверительных интервалах и дизайне A/B-тестов. На senior-уровне добавляются продвинутые методы снижения дисперсии, причинно-следственный вывод и ситуации, когда классический A/B неприменим.
Python и SQL. Кодинг-секция проверяет, что вы умеете превратить идею в работающий код: pandas и numpy для обработки данных, базовые алгоритмы и структуры, плюс SQL-запросы под аналитическую задачу. SQL на DS-собесе обычно не сложнее, чем у аналитика, но решать его нужно быстро и без ошибок.
Продуктовое мышление и метрики. Модель сама по себе бизнесу не нужна — нужен эффект. Поэтому спрашивают, как вы свяжете offline-метрику качества модели с продуктовой метрикой, как замерите эффект внедрения и как выберете, что вообще оптимизировать. Это раздел, где DS отличают от человека, который просто тренирует модели.
Deep Learning и NLP — по необходимости. Для большинства ролей глубокое обучение не обязательно, но в командах, работающих с текстом, изображениями или рекомендациями, спросят про эмбеддинги, архитектуры, трансформеры и метрики ранжирования. Если в вакансии это есть — готовьтесь предметно, если нет — хватит базовой эрудиции.
Этапы собеседования
Типичный цикл состоит из четырёх-шести этапов и растягивается на несколько недель. Точный набор зависит от компании и направления — ML Engineer, Research, Applied или Product DS, — но общая логика повторяется: сначала отсев, потом глубокая техническая проверка, в конце — продуктовый и поведенческий раунды.
Скрининг с рекрутером открывает цикл и длится двадцать-тридцать минут. Здесь обсуждают опыт, мотивацию и зарплатные ожидания, а заодно уточняют направление, чтобы дальше дать профильные секции. Технических вопросов почти нет, но размытый рассказ о своих проектах уже на этом шаге может стоить продвижения.
Секция ML-теории и статистики — главный фильтр. За час интервьюер проходит по распределениям, проверке гипотез, регрессии и классификации, метрикам качества, переобучению и регуляризации. Оценивают не заученные определения, а понимание механики: почему именно эта метрика, что произойдёт при изменении порога, как поведёт себя модель на новых данных.
Кодинг-секция проверяет SQL и Python в формате live-coding. Дают схему из нескольких таблиц и просят написать запрос вслух, затем — задачу на pandas или базовый алгоритм. Важно проговаривать ход мысли: какие джойны берёте, как обрабатываете пропуски, почему выбрали такой подход. Детали — в разделах SQL и Python.
Кейс и ML system design — устный раунд, где просят спроектировать систему: рекомендации для маркетплейса, классификатор fraud, модель оттока. Ждут структуры: как соберёте данные, какие признаки возьмёте, какую модель, как измерите качество offline и как проверите эффект в A/B. От senior разбирают детально, от junior — общими словами, но логика рассуждения важна на любом уровне.
Поведенческое интервью закрывает цикл. STAR-вопросы про проекты, конфликты и провалы проверяют, как вы работаете в команде и берёте ли ответственность за результат. Финал нередко проводит руководитель направления — там оценивают стратегическое мышление и совпадение с командой.
Почему проваливают
Чаще всего кандидата заваливают не сложные темы, а зазубренный ответ без понимания. Человек называет регуляризацию способом борьбы с переобучением, но не может объяснить, чем L1 отличается от L2 и почему первая обнуляет признаки. Интервьюер сразу видит границу между выученным и понятым.
Вторая частая ловушка — игнорировать постановку задачи ради «правильного» алгоритма. Кандидат хватается за нейросеть там, где хватило бы логистической регрессии, или оптимизирует accuracy на сильно несбалансированном классе, не замечая, что метрика бессмысленна. Сильный DS сначала уточняет данные, бизнес-цель и ограничения, и только потом выбирает инструмент.
Третья — неумение связать модель с бизнесом. Кандидат подробно рассказывает про архитектуру, но на вопрос «зачем это компании» отвечает общими словами. Без метрики, baseline и плана проверки через эксперимент даже технически верное решение выглядит как упражнение ради упражнения.
Наконец, проваливают молчанием. ML system design и кодинг — это диалог: интервьюер оценивает ход мысли, а не только итог. Кандидат, который думает вслух и сам проговаривает edge-кейсы — утечку данных, дисбаланс, переобучение, — производит куда более сильное впечатление, чем тот, кто молча выдаёт ответ.
Примеры вопросов с разбором
Попробуйте ответить сами, прежде чем читать разбор.
1. Что такое bias-variance trade-off?
У любой модели ошибка складывается из двух частей. Bias — систематическая ошибка из-за слишком простых предположений: такая модель недообучается и одинаково плохо работает и на train, и на тесте. Variance — чувствительность к конкретной выборке: сложная модель цепляется за шум, отлично работает на train и рассыпается на новых данных. Уменьшая одно, обычно увеличиваешь другое, поэтому цель — баланс, минимизирующий суммарную ошибку, а не ноль по любому из слагаемых.
2. Как понять, что модель переобучилась, и что с этим делать?
Главный признак — разрыв между train и validation: если на обучении accuracy 95%, а на отложенной выборке 70%, это переобучение. Лечится несколькими способами: больше данных, регуляризация L1/L2, упрощение модели, early stopping и dropout в нейросетях, ансамбли. Надёжно поймать переобучение помогает кросс-валидация — она показывает разброс качества по фолдам, а не одну случайную цифру.
3. Чем L1-регуляризация отличается от L2?
Обе добавляют штраф за величину весов, но по-разному. L1 (Lasso) штрафует сумму модулей и склонна обнулять часть коэффициентов — фактически отбирает признаки. L2 (Ridge) штрафует сумму квадратов и плавно ужимает веса к нулю, не обнуляя их полностью. L1 полезна, когда нужна разреженная модель и feature selection; L2 — когда признаки коррелируют и важно стабилизировать обучение.
4. В чём разница между precision и recall?
Precision и recall отвечают на разные вопросы. Precision — какая доля предсказанных «положительными» объектов действительно положительна (цена ложной тревоги). Recall — какую долю всех настоящих положительных мы поймали (цена пропуска). Их почти всегда приходится балансировать: повышая порог, растишь precision и теряешь recall, и наоборот. F1 — их гармоническое среднее, удобное, когда нужен один компромиссный показатель.
5. Что показывает ROC-AUC и когда он обманывает?
ROC-AUC — вероятность того, что случайный положительный объект получит больший скор, чем случайный отрицательный; метрика не зависит от выбранного порога. Её слабость — сильный дисбаланс классов: на данных с долей положительных в один процент ROC-AUC может выглядеть высоким, хотя модель почти бесполезна. В таких случаях информативнее PR-AUC, построенный по precision и recall.
6. Как выбрать метрику под задачу?
Метрика должна отражать цену ошибки в конкретной задаче, а не выбираться по привычке. Для fraud detection с долей мошенников в пару процентов accuracy бесполезна — модель, всегда отвечающая «не fraud», даст 98%. Здесь смотрят на precision при фиксированном recall или PR-AUC. Для ранжирования берут метрики качества порядка, для регрессии — MAE или RMSE в зависимости от чувствительности к выбросам. Общий принцип — сначала бизнес-цель, потом метрика.
7. Что такое утечка данных (data leakage)?
Утечка — это когда в обучение просачивается информация, недоступная в момент реального предсказания, и метрики на тесте оказываются завышенными. Классика: посчитать нормализацию или отбор признаков на всём датасете до разбиения, использовать признак, который заполняется уже после события-цели, или допустить пересечение объектов между train и test. Сигнал тревоги — подозрительно высокое качество; лечится честным разделением выборок и расчётом всех преобразований только на train.
8. Как работать с дисбалансом классов?
При дисбалансе сначала меняют метрику — accuracy заменяют на precision/recall, F1 или PR-AUC. Дальше есть несколько рычагов: взвешивание классов в функции потерь, oversampling редкого класса (в том числе SMOTE), undersampling частого, подбор порога под бизнес-требование. Важно оценивать качество на исходном распределении, а ресэмплинг применять только к обучающей части — иначе получите ту же утечку данных.
9. Зачем нужна кросс-валидация и какие у неё подводные камни?
Кросс-валидация даёт более надёжную оценку качества, чем одно разбиение: данные делят на k фолдов и усредняют метрику по ним. Подводные камни — про структуру данных: для несбалансированных классов нужна стратификация, для временных рядов — разбиение по времени без подглядывания в будущее, а при наличии групп (например, один пользователь с несколькими записями) — группировка, чтобы объекты одной группы не попали и в train, и в test.
10. Когда A/B-тест не работает?
A/B ломается в нескольких ситуациях: сетевые эффекты (действия одних пользователей влияют на других), долгий отложенный эффект, слишком маленькая выборка при большом MDE и загрязнение контрольной группы. В таких случаях берут альтернативы — switchback, гео-эксперименты, difference-in-differences и другие методы причинно-следственного вывода.
Разборы по подтемам
- ML-теория: bias-variance, регуляризация, переобучение
- Классический ML: бустинг, деревья, линейные модели
- Метрики качества модели
- Feature engineering
- A/B-тесты и causal inference
- ML system design
- Live-coding: Python и SQL
- Deep Learning на собесе
- NLP-задачи
- Временные ряды
Главные темы по разделам
Machine Learning
- Causal inference: причинность vs корреляция
- Cross-validation и валидация моделей
- AUC-ROC и метрики классификации
- Precision vs Recall и F1
- Uplift modeling
- Time series decomposition
Статистика и эксперименты
- Размер выборки A/B
- P-value простыми словами
- CUPED для снижения дисперсии
- Guardrail-метрики
- Selection bias простыми словами
- Парадокс Симпсона
- Bootstrap-статистика
- Bayesian A/B testing
- Difference-in-Differences
- Propensity score matching
SQL и Python для DS
- Подготовка к SQL-интервью
- Подготовка к Python-интервью
- Pandas-шпаргалка
- Как посчитать LTV в SQL
- Cohort retention в SQL
Продуктовая аналитика для DS
- Метрики продукта на собесе DS
- Шпаргалка метрик продукта
- Юнит-экономика
- Кейсы на собеседовании аналитика
Системный дизайн ML
Гайды по компаниям
Особенности собеса DS по компаниям, где сильные DS-команды:
Как готовиться
Соберите фундамент по ML и статистике. Без уверенного понимания bias-variance, регуляризации, кросс-валидации и метрик качества дальше двигаться бессмысленно — именно это спрашивают в первую очередь. Разбирайте каждую тему до уровня «могу объяснить вслух своими словами», а не пересказа определения.
Доведите A/B и эксперименты до продвинутого уровня. Размера выборки и p-value мало: на senior-секциях ждут CUPED, switchback и причинно-следственные методы. Понимание, когда классический тест неприменим, отличает сильного кандидата от среднего.
Тренируйте кейсы вслух. ML system design — устный жанр, и молча тут не пройти. Берите задачу вроде «спроектируй рекомендации» и проговаривайте решение структурно за тридцать минут, как на реальном собесе.
Решайте короткие вопросы каждый день. Память на паттерны нарабатывается объёмом, а не одним большим проектом. Удобно прогонять примеры вопросов с моментальным разбором — так ловушки по метрикам, переобучению и статистике закрепляются и перестают застигать врасплох.
Соберите один-два end-to-end проекта. Полный цикл от данных до проверки гипотезы в A/B даёт материал для поведенческой секции и доказывает, что вы доводите модель до продукта, а не только до ноутбука.
Частые ошибки на собеседовании
Главная ошибка — отвечать определениями вместо понимания. Фразу «регуляризация борется с переобучением» интервьюер слышал сотни раз; ценится умение объяснить, почему L2 ужимает веса, а L1 обнуляет, и что вы выберете в конкретной ситуации. Зубрёжка вскрывается первым же уточняющим вопросом.
Вторая ошибка — пропускать постановку задачи. Перед выбором модели стоит уточнить, как выглядят данные, какой класс редкий, что считается ценой ошибки и какая бизнес-цель за этим стоит. Кандидат, который сразу пишет код, рискует решить не ту задачу и красиво оптимизировать бесполезную метрику.
Третья — забывать про edge-кейсы. Утечка данных, дисбаланс классов, пропуски, нестабильность на новых данных: проговаривание этих рисков показывает зрелость сильнее, чем безошибочный, но наивный ответ. И, наконец, не молчите — и в кодинге, и в system design оценивают ход мысли, поэтому думать вслух не слабость, а часть оценки.
Другие темы
- Продуктовая аналитика на собесе
- SQL на собеседовании
- Python на собеседовании
- A/B-тестирование на собесе
- Статистика и вероятности
FAQ
Какие вопросы задают на собеседовании Data Scientist?
Ядро — ML-теория (bias-variance, переобучение, регуляризация, метрики качества), статистика и A/B-тесты, кодинг на Python и SQL, плюс продуктовые кейсы и ML system design. В командах с текстом или изображениями добавляются вопросы по deep learning и NLP. Конкретный набор зависит от направления — Applied, Research или Product DS.
Чем собеседование Data Scientist отличается от аналитика данных?
У аналитика данных центр тяжести — SQL, метрики и продуктовые кейсы. У Data Scientist к этому добавляется глубокая ML-теория, продвинутая статистика и проектирование ML-систем. Грубо говоря, аналитика спрашивают «как измерить», а DS — ещё и «как построить модель и доказать её эффект».
Сколько математики нужно для DS-собеса?
База: линейная алгебра (матрицы, собственные значения), математический анализ (производные, градиент), теория вероятностей и статистика (распределения, мат. ожидание, дисперсия, проверка гипотез). От junior ждут знания формул, от senior — понимания, как это работает под капотом моделей. Вывод формул на доске требуется редко.
Нужен ли deep learning для роли Data Scientist?
Не всегда. Большинство задач закрывается классическими методами — градиентным бустингом и логистической регрессией. Deep learning нужен в специфических доменах: компьютерное зрение, NLP, рекомендательные системы на больших данных. Если в вакансии это не заявлено, хватит базовой эрудиции.
Сколько готовиться к собеседованию Data Scientist?
Зависит от старта. Junior после базовой подготовки обычно тратит несколько месяцев интенсива, middle — меньше, senior фокусируется на ML system design и продуктовых кейсах, так как технический фундамент уже есть. Это ориентиры, а не гарантия — всё упирается в исходный уровень и регулярность практики.
Чем DS отличается от ML Engineer?
Data Scientist ближе к исследованию: гипотезы, эксперименты, продуктовый эффект. ML Engineer отвечает за production — деплой моделей, MLOps, инфраструктуру, latency и масштабирование. На практике границы размыты, и во многих командах один человек делает и то, и другое.