9 апреля 2026 г.

Ошибки на собеседовании аналитика — и как их избежать

Почему эта тема важна

Большинство провалов на собеседованиях — не от незнания. Кандидат знает SQL, понимает A/B-тесты, решал продуктовые кейсы. Но проваливает интервью из-за ошибок, которых мог бы избежать: забыл про edge case, запутался в объяснении, не спросил уточняющий вопрос.

Ниже — типичные ошибки по категориям. Для каждой — почему она опасна и как её не допустить. Если вы готовитесь к собеседованию, пройдитесь по этому списку вместе с чек-листом подготовки.

Ошибки в SQL-задачах

Забывать про NULL

Это ошибка номер один. Вы пишете WHERE status != 'cancelled', а строки с status IS NULL тоже исчезают — потому что NULL != 'cancelled' в SQL возвращает не TRUE, а NULL. Интервьюер тут же спросит: «А что с NULL?».

Как избежать: всегда проговаривайте вслух, есть ли в данных NULL. Используйте COALESCE или добавляйте OR status IS NULL, если нужно сохранить такие строки.

Не думать о дубликатах

Вас просят посчитать количество пользователей, совершивших покупку. Вы пишете COUNT(user_id) вместо COUNT(DISTINCT user_id). Один пользователь с тремя покупками считается трижды.

Как избежать: перед написанием запроса спросите себя (или интервьюера): «Может ли одна сущность встретиться несколько раз?».

JOIN без понимания гранулярности

Два частых промаха: LEFT JOIN, который умножает строки (many-to-many), и INNER JOIN, который теряет строки.

-- Ожидали 1000 строк, получили 5000
SELECT *
FROM orders o
JOIN order_items oi ON o.id = oi.order_id

Как избежать: перед JOIN проговорите гранулярность обеих таблиц. «Orders — одна строка на заказ. Order_items — одна строка на товар в заказе. JOIN даст одну строку на товар.»

Не тестировать запрос мысленно

Интервьюер даёт таблицу из 5 строк. Вы пишете запрос, но не проверяете его на этих данных. Запрос неправильный, и вы этого не видите.

Как избежать: после написания запроса возьмите конкретные строки из условия и «прогоните» запрос в голове. Это занимает 30 секунд и спасает от глупых ошибок.

Ошибки в статистике и A/B-тестах

P-hacking — поиск значимости после теста

«Тест не показал значимый результат на всей аудитории, но на iOS-пользователях из Москвы — p = 0.04!» Это типичный p-hacking. Чем больше срезов проверите, тем выше вероятность случайно найти «значимость».

Как избежать: на собеседовании скажите, что анализ подгрупп — это генерация гипотез, а не доказательство эффекта. Подгруппу нужно проверять отдельным тестом с поправкой на множественное сравнение.

Игнорирование предпосылок тестов

Вас спрашивают: «Можно ли использовать t-test?» Вы говорите «да» — и не проверяете, нормально ли распределены данные, достаточен ли размер выборки, не скошено ли распределение.

Как избежать: при любом вопросе про статистический тест перечислите предпосылки: независимость наблюдений, распределение метрики, размер выборки. Для маленьких выборок или ненормальных распределений — предложите непараметрические тесты или бутстрап.

Путаница между статистической и практической значимостью

«P-value = 0.01, значит эффект большой!» Нет. P-value показывает, насколько маловероятен результат при нулевой гипотезе. Эффект может быть статистически значим и при этом мизерным: +0.01% к конверсии. Бизнесу от этого ни жарко ни холодно.

Как избежать: всегда называйте размер эффекта (в абсолютных числах или процентах) вместе с p-value. «Конверсия выросла на 2 п.п. (с 5% до 7%), p = 0.01» — вот полный ответ.

Ошибки в продуктовых кейсах

Прыжок к решению без уточнения

«Как бы вы улучшили конверсию в покупку?» — и кандидат сразу начинает генерить идеи. Без уточнения: какой продукт, какая текущая конверсия, что уже пробовали, где в воронке потери.

Как избежать: первые 2-3 минуты — только вопросы. Уточните контекст, метрики, целевую аудиторию. Это показывает аналитическое мышление. На собеседованиях кейсов ценят процесс, а не финальный ответ.

Не структурировать ответ

Кандидат начинает рассуждать хаотично: «Ну, можно попробовать... а ещё... и вот...». Интервьюер теряет нить.

Как избежать: начните с фреймворка. «Я бы разделил задачу на три части: 1) диагностика — где в воронке потери, 2) генерация гипотез, 3) приоритизация и тестирование». Структура > содержание.

Не привязывать к метрикам

«Давайте добавим онбординг» — а зачем? Какую метрику это улучшит? На сколько? Как измерим?

Как избежать: каждое предложение привязывайте к метрике. «Добавим онбординг, чтобы увеличить activation rate (% пользователей, совершивших целевое действие в первый день). Измерим A/B-тестом, ожидаемый эффект — +5-10 п.п.».

Поведенческие ошибки

Не задавать вопросы

Собеседование — это диалог, а не экзамен. Кандидат, который молча думает 5 минут и потом выдаёт ответ — проигрывает тому, кто думает вслух и уточняет.

Как избежать: думайте вслух. «Я правильно понимаю, что в таблице одна строка = один заказ?» Это не слабость — это навык коммуникации.

Монолог на 10 минут

Вас спросили «Чем отличается LEFT JOIN от INNER JOIN?». Правильный ответ — 30 секунд. Если вы говорите 5 минут, интервьюер устал и потерял интерес.

Как избежать: отвечайте коротко. Если интервьюер хочет подробнее — он попросит. Структура ответа: определение (1-2 предложения) + пример + нюанс, если есть.

Паника при незнании

Вам задали вопрос, на который вы не знаете ответ. Вы краснеете, мнётесь, начинаете фантазировать.

Как избежать: скажите: «Я не уверен в точном ответе, но рассуждаю так: ...». Честность + логические рассуждения оцениваются выше, чем уверенно высказанная чушь.

Ошибки в подготовке

Не практиковать ответы вслух

Вы прочитали 50 статей, прорешали 100 SQL-задач — но ни разу не отвечали на вопросы устно. На собеседовании оказывается, что объяснить p-value словами — сложнее, чем прочитать про него.

Как избежать: тренируйтесь вслух. Объясняйте концепции воображаемому интервьюеру (или реальному другу). Запишите себя на видео — увидите проблемы в подаче.

Готовиться только по хард-скиллам

SQL и Python — необходимы, но недостаточны. Продуктовые кейсы, soft skills, мотивация, вопросы рекрутёру — всё это влияет на результат. Много сильных технарей проваливают финал из-за «не наш человек».

Как избежать: выделите 30% времени на кейсы, поведенческие вопросы и подготовку рассказа о себе. Резюме — отдельная тема, но на собеседовании вас попросят пересказать его своими словами.

Как восстановиться после ошибки

Ошибки на собеседовании неизбежны. Важно не то, что вы ошиблись, а как отреагировали.

  1. Признайте ошибку. «Подождите, я вижу ошибку в запросе — тут нужен LEFT JOIN, а не INNER». Интервьюер оценит.
  2. Исправьте и объясните. Покажите, что понимаете, почему ошиблись. Это ценнее правильного ответа с первого раза.
  3. Не зацикливайтесь. Ошиблись в первом вопросе — не тащите это чувство во второй. Каждый вопрос — новый шанс.

FAQ

Сколько ошибок можно допустить, чтобы всё равно пройти собеседование?

Жёстких правил нет. Одна-две ошибки в SQL при правильном ходе рассуждений — это нормально. Интервьюер оценивает мышление, а не безошибочность. Системные пробелы (не знаете оконных функций, не понимаете p-value) — это уже проблема.

Что делать, если я не знаю ответ на вопрос?

Скажите честно: «Этот вопрос я раньше не разбирал, но давайте порассуждаю». Попробуйте вывести ответ из того, что знаете. Интервьюеры ценят рассуждения и честность больше, чем угадывание.

Стоит ли проходить mock-собеседования?

Однозначно да. Mock-собеседование выявляет ошибки, которые вы не замечаете при самостоятельной подготовке: скомканные объяснения, привычку не задавать вопросы, проблемы с тайм-менеджментом. Попросите коллегу или используйте запись на камеру.

Потренируйте вопросы из реальных собеседований аналитика — откройте тренажёр. 1500+ вопросов, которые спрашивают на собеседованиях аналитика. Бесплатно.

Тренироваться в Telegram