За годы я провёл и прошёл достаточно собеседований, чтобы заметить неприятную закономерность: аналитиков заваливают редко из-за пробелов в знаниях. Гораздо чаще — из-за того, как человек думает вслух и ведёт себя у экрана. Кандидат с крепким SQL уходит без оффера, потому что десять минут молча смотрел в редактор. А джун, который знает меньше, но рассуждает и переспрашивает, получает «берём».
Ниже — 10 ошибок, которые встречаются чаще всего. Почти все они не про знания, а про мышление и подачу. Хорошая новость: именно поэтому их можно убрать за пару недель осознанной практики, а не за полгода зубрёжки.
Ошибка 1. Пишут SQL молча
Самая частая и самая обидная. Интервьюер дал задачу — кандидат утыкается в редактор и десять минут пишет запрос в тишине. На экране появляется готовый ответ, но собеседующий не понял ничего: как вы рассуждали, где сомневались, почему выбрали именно JOIN, а не подзапрос.
Секрет в том, что технический раунд — это не проверка «умеете ли вы писать SQL». Это проверка «как вы думаете». Правильный ответ, полученный молча, стоит меньше, чем ход мысли вслух с одной опечаткой.
Как надо: проговаривайте всё. «Так, мне нужна выручка по клиентам. Беру orders, группирую по customer_id, суммирую amount. Проверю, нет ли клиентов без заказов — если они тоже нужны, возьму LEFT JOIN». Даже если застряли — озвучьте, где именно. Интервьюер часто подсказывает тому, кто рассуждает, и молчит с тем, кто молчит.
Ошибка 2. Бросаются решать, не уточнив условие
Формулировки на собесе намеренно размытые: «Посчитай активных пользователей за месяц». Кандидат сразу пишет COUNT(DISTINCT user_id). А интервьюер имел в виду другое: активный — это кто заходил или кто совершил целевое действие? Месяц — календарный или скользящие 30 дней? Считаем по всем платформам или только мобилка?
Прыжок к решению без уточнений — красный флаг. В реальной работе аналитик, который приносит цифру не на тот вопрос, хуже того, кто переспросил. Один-два точных уточняющих вопроса показывают, что вы работали с настоящими, неоднозначными задачами, а не только с учебными.
Хорошая привычка — перед кодом проговорить определение: «Под активным я понимаю пользователя хотя бы с одним событием типа X. Окно — календарный месяц по времени события в UTC. Так считаем?»
Ошибка 3. Путают корреляцию и причинность
Классика, на которой валятся даже сильные ребята. «Пользователи, которые оставили отзыв, удерживаются лучше — давайте всех попросим оставить отзыв, и retention вырастет». Звучит логично и абсолютно неверно: отзыв оставляют те, кому и так нравится продукт. Это не отзыв двигает retention, а лояльность двигает оба.
На собесе это проверяют специально. Дают график с двумя растущими линиями или наблюдательные данные и смотрят, скажете ли вы волшебное слово — «а это причинно-следственная связь или просто корреляция?». Почти всегда за красивой корреляцией прячется третий фактор (confounder) или обратная причинность.
Как отвечать: назовите альтернативные объяснения и предложите способ проверить именно причину — рандомизированный A/B-тест, а если эксперимент невозможен, то квазиэксперимент (difference-in-differences, matching). Фраза «чтобы утверждать про причину, я бы поставил A/B» на продуктовом раунде стоит дорого.
Ошибка 4. Решают задачу, а не проблему бизнеса
Аналитик — это не «человек, который пишет запросы». Это человек, который отвечает на вопрос бизнеса цифрами. На кейсах это видно моментально. «Конверсия в покупку упала на 15% за неделю» — слабый кандидат сразу лезет в SQL считать конверсию. Сильный сначала думает: а не выкатили ли релиз, не сломался ли трекинг, не пришёл ли новый трафик из другого канала, не сезонность ли это.
Каждый ваш запрос должен заканчиваться не таблицей, а выводом и действием. Не «вот 5 строк с оттоком по регионам», а «отток сконцентрирован в двух регионах после смены тарифа — предлагаю проверить гипотезу, что дело в цене». Если после вашего ответа менеджер спросит «и что?», значит, вы остановились на шаг раньше, чем нужно.
Потренироваться думать от бизнеса, а не от таблицы, удобно на разборах кейсов — там задачи сформулированы так же криво и по-человечески, как на реальном продуктовом раунде.
Ошибка 5. Пишут SQL, который работает на демо и падает на проде
Запрос отдал красивый результат на трёх строчках примера — и развалится на реальных данных. Три классических грабли, которые интервьюер проверяет специально.
Дубли из-за JOIN fan-out:
-- Хотели выручку по клиентам, а лишний JOIN размножил строки
SELECT c.name, SUM(o.amount) AS revenue
FROM customers c
JOIN orders o ON o.customer_id = c.id
JOIN order_items i ON i.order_id = o.id -- amount задублировался на каждую позицию
GROUP BY c.name;Здесь SUM(o.amount) завышен во столько раз, сколько позиций в заказе. Про гранулярность JOIN нужно думать всегда.
NULL в NOT IN:
-- Вернёт 0 строк, если в подзапросе есть хоть один NULL
SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM orders);Один NULL в user_id — и весь запрос молча отдаёт пустоту. Безопаснее NOT EXISTS или явный WHERE user_id IS NOT NULL.
Ну и деление: AVG по полю, где половина значений NULL, и целочисленное деление, которое отрезает дробную часть. На собесе стоит вслух сказать: «проверю на дубли и на NULL перед тем, как доверять цифре». Отработать эти грабли лучше не в теории, а руками — в SQL-тренажёре на живых данных с дублями, пропусками и разной гранулярностью.
Ошибка 6. Заучивают определения вместо понимания
«Что такое retention?» — «Это удержание». Всё. Кандидат выучил слово, но не может ни формулу написать, ни сказать, чем rolling retention отличается от classic, ни объяснить, почему retention 7-го дня для игры и для B2B-сервиса читаются по-разному.
Определения-наизусть ловятся первым же уточняющим вопросом. Интервьюер спросит «а как посчитаешь?» или «а на каких данных эта метрика соврёт?» — и заученный ответ рассыпается.
Метрики надо понимать до уровня формулы и граничных случаев: что в числителе, что в знаменателе, какая когорта, за какое окно. Если путаетесь в LTV, CAC, DAU/MAU, conversion rate или разнице между retention и churn — прогоните их через справочник метрик с формулами, а потом попробуйте объяснить каждую своими словами без подглядывания. Понимание — это когда можешь объяснить, а не процитировать.
Ошибка 7. Блефуют вместо честного «не знаю»
Спросили про то, чего кандидат не знает, — и он начинает выкручиваться, придумывать на ходу, уверенно нести неправду. Это худшее, что можно сделать. Интервьюер почти всегда видит блеф насквозь, потому что задаёт follow-up, и конструкция рушится.
Честное «точно не сталкивался, но рассуждал бы так…» ценится в разы выше. Вы показываете два важных качества: понимание границ своих знаний и умение рассуждать в незнакомом месте. Именно так выглядит работа реального аналитика — регулярно упираешься в то, чего не знаешь.
Признать незнание — не провал. Провал — уверенно заявить, что p-value это вероятность того, что гипотеза верна (это неправда), и получить три уточняющих вопроса, на которых поплывёшь.
Ошибка 8. Разбирают A/B-тест без статистики
Продуктовые и A/B-вопросы — половина собеса на продуктового аналитика. Типичный провал: «Вариант B дал конверсию 5.2% против 5.0% — значит, катим B». Без размера выборки, без проверки значимости, без доверительного интервала это не вывод, а гадание.
Что должно прозвучать: какой размер выборки нужен под ожидаемый эффект (power-анализ), сколько времени крутить тест, как проверяем значимость. Для конверсий — z-тест для пропорций или хи-квадрат, для средних — t-тест:
from scipy.stats import ttest_ind
# группы A и B — массивы значений метрики по пользователям
stat, p_value = ttest_ind(group_a, group_b, equal_var=False)
# p_value < 0.05 — есть основания считать разницу неслучайнойИ отдельно — про подводные камни, которые любят спрашивать: подглядывание в результаты до конца теста (peeking) раздувает ложноположительные, множественные сравнения требуют поправок, а статистическая значимость не равна практической — рост на 0.1% может быть «значим» на миллионах юзеров и при этом бесполезен для бизнеса. Прогнать такой расчёт руками можно в Python-тренажёре с scipy прямо в браузере.
Ошибка 9. Переусложняют там, где нужно просто
Две крайности, и обе плохи. Первая — не знают оконных функций и городят костыли. Вторая — из желания впечатлить пишут вложенные подзапросы там, где хватило бы одной строки.
Классический пример — пронумеровать заказы клиента по дате:
-- Переусложнённо: коррелированный подзапрос, медленно и нечитаемо
SELECT o.*,
(SELECT COUNT(*) FROM orders o2
WHERE o2.user_id = o.user_id AND o2.created_at <= o.created_at) AS n
FROM orders o;
-- Просто и правильно
SELECT o.*,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at) AS n
FROM orders o;Хороший код на собесе — читаемый и прямой, а не самый хитрый. Если решение можно упростить, лучше упростить и сказать почему. Оконные функции спрашивают почти всегда, так что ROW_NUMBER, LAG/LEAD, running total через SUM() OVER должны быть в пальцах.
Ошибка 10. Проваливают soft skills и рассказ о своём опыте
Технику сдал, а на «расскажите о своём проекте» мнётся, не может назвать ни метрику, которую двигал, ни результат. Или спорит с интервьюером, защищая неверный ответ вместо «да, вы правы, я не учёл». Или в конце на «какие у вас вопросы?» говорит «нет вопросов» — и выглядит незаинтересованным.
Про свой опыт готовьте истории в формате «задача → что сделал → результат в цифрах». Не «анализировал воронку», а «нашёл, на каком шаге теряется 18% пользователей, предложил гипотезу, после правки конверсия выросла». Про зарплату не называйте одну цифру в потолок — держите вилку и спокойно её обоснуйте; конкретные суммы обсуждаются на оффере, а не на первом звонке. И всегда держите пару вопросов про команду, продукт и метрики — это часть оценки.
Как отрепетировать, чтобы не наступить на эти грабли
Все десять ошибок объединяет одно: они не видны, когда решаешь задачи в одиночку. Молчание, блеф, прыжок к решению без уточнений — это вылезает только под наблюдением и под давлением времени. Поэтому лучший способ подготовки — не «прочитать про ошибки», а сымитировать сам стресс собеса.
Прогоните типовые вопросы из банка вопросов для аналитика, чтобы не путаться в базе. А потом сядьте за AI мок-собеседование: интервьюер задаёт вопросы уровня Yandex, Ozon, Сбера и T-Bank, слушает, как вы рассуждаете вслух, ловит на корреляции-причинности и незакрытых уточнениях — и даёт разбор по каждому ответу. Это безопасное место, где можно ошибиться десять раз до того, как это случится на настоящем собесе.
Собеседование выигрывает не тот, кто знает больше, а тот, кто думает вслух, уточняет, честно признаёт границы и держит в голове бизнес. Технику подтянуть можно за месяц. Эти привычки — за две недели, если репетировать по-настоящему.