Как подготовиться к собеседованию на аналитика: план на 2 недели

Коротко: что делать в эти две недели

Сначала узнайте у рекрутера, из каких этапов состоит ваш отбор, и не готовьтесь «ко всему». Затем распределите дни по слабым местам: большинству кандидатов в аналитику больше всего дают ежедневные SQL-задачи вслух и пять-шесть разобранных продуктовых кейсов. Статистику достаточно довести до уровня, на котором вы считаете z-тест для двух долей на бумаге и объясняете, что значит мощность. Поведенческие истории пишутся один раз и репетируются вслух.

Главный навык, который проверяют на всех технических этапах, — не память, а привычка уточнять условие и проверять собственный результат. Его можно натренировать за две недели; выучить все функции оконного SQL за то же время нельзя, да и не нужно.

• День 1: узнать этапы, формат SQL-секции (редактор, доска, база) и роль — аналитик данных, продуктовый, BI.
• Каждый день: две-три SQL-задачи с проговариванием вслух и проверкой результата.
• Каждые два дня: один продуктовый кейс за семь-десять минут с таймером.
• Один раз и с повторением: рассказ о себе, три истории по STAR, вопросы будущей команде.
• Накануне: без новой теории, только повтор своих конспектов и чек-лист.

Из каких этапов состоит собеседование на аналитика

Порядок и число этапов зависят от компании и грейда: где-то скрининг и финал совмещены, где-то тестовое заменяет SQL-секцию, где-то статистику проверяют внутри продуктового кейса. Таблица ниже — типовой набор, а не обещание конкретного работодателя. Чтобы понять, что ждёт вас, спросите рекрутера прямо: «Какие будут этапы и сколько длится каждый? Будет ли SQL в редакторе с базой или на доске?» Это нормальный вопрос, его задают сильные кандидаты.

Если вы ещё выбираете направление, сначала посмотрите виды аналитиков и их задачи: у системного и бизнес-аналитика отбор устроен иначе, там больше требований, процессов и нотаций, чем SQL. Для них есть отдельные разборы: собеседование системного аналитика, бизнес-аналитика и аналитика 1С. Ожидания по уровню описаны в статье о грейдах аналитика.

Скрининг, резюме и разговор о деньгах

Скрининг кажется формальностью, но на нём отсеивают много людей: кандидат не может за минуту объяснить, чем занимался, или называет ожидания, которые не сходятся с вилкой. Подготовьте короткий рассказ о себе по схеме «что делаю сейчас → чем это доказано → почему эта роль». Он должен совпадать с резюме: рекрутер сверяет одно с другим.

Про деньги лучше подумать до звонка, а не на нём. Посмотрите разбор о том, сколько получает аналитик данных, и назовите вилку, с которой вам комфортно. Если вы откликались с письмом, освежите его в памяти: на скрининге часто спрашивают ровно о том, что было в сопроводительном письме.

Последние пять минут скрининга — ваши. Спросите о составе этапов, формате SQL-секции, сроках решения и о том, кто будет на финале. Ответы нужны для плана подготовки, а не для вежливости.

Тестовое задание и портфолио

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

Если опыта работы нет, тестовое и учебные проекты заменяют строку «опыт» в резюме. Два проекта с понятным вопросом, проверенным расчётом и выводом сильнее десяти тетрадок с графиками без смысла — об этом подробно в статье о портфолио аналитика данных. Если вы только входите в профессию, начните с маршрута аналитика данных без опыта и посмотрите, как устроены стажировки: у них отбор мягче по опыту, но строже по базовому SQL.

На интервью по тестовому вас почти наверняка попросят объяснить решение. Перечитайте свою работу накануне и найдите в ней одно слабое место сами: «здесь я не проверил дубли», «здесь окно наблюдения короче, чем хотелось бы». Кандидат, который называет ограничение первым, выглядит сильнее того, у кого его находит интервьюер.

SQL-секция: как вести себя на live-coding

На SQL-секции вам дают схему из двух-четырёх таблиц и просят написать запрос — в редакторе с базой, в общем документе или на доске. Проверяют не скорость печати, а три вещи: понимаете ли вы, что лежит в строке таблицы, не размножаете ли строки соединением и проверяете ли результат, прежде чем сказать «готово».

Порядок, который работает почти на любой задаче. Первое — переспросите условие своими словами и уточните определения: «платящий — это хотя бы один платёж любого типа? Регистрации за июнь — по дате регистрации?» Второе — назовите зерно каждой таблицы: в users одна строка — пользователь, в payments — платёж, у одного пользователя их может быть несколько. Третье — проговорите план до кода: «отфильтрую когорту, для каждого проверю наличие платежа, сгруппирую по каналу». Четвёртое — напишите запрос. Пятое — проверьте результат: сходится ли сумма по группам с общим числом, правдоподобна ли доля, не выросло ли число строк после JOIN.

Думать вслух — не значит комментировать каждую нажатую клавишу. Достаточно озвучивать решения: почему LEFT JOIN, а не JOIN, почему COUNT(DISTINCT), почему граница даты полуоткрытая. Если застряли, скажите, где именно: интервьюер часто подсказывает, когда видит ход мысли, и не может помочь молчащему кандидату. Подборки для тренировки: SQL на собеседовании аналитика: 20 задач, вопросы по SQL с короткими ответами и SQL-задачи с решениями.

Пример SQL-задачи: доля платящих по каналам

Условие: «Какая доля пользователей, зарегистрированных в июне, заплатила хотя бы раз? Разбейте по каналам привлечения». Таблицы users (одна строка — пользователь) и payments (одна строка — платёж, первый или продление). Запрос выполняется на учебной базе «Маяк» — той же, что в песочнице симулятора SQL-аналитика.

Ключевое решение — не соединять таблицы напрямую. Наличие платежа проверяется через EXISTS: так каждый пользователь остаётся одной строкой, сколько бы раз он ни платил. Граница периода полуоткрытая: от 1 июня включительно до 1 июля не включительно.

SELECT u.channel,
       COUNT(*) AS users,
       COUNT(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM payments p WHERE p.user_id = u.user_id
       )) AS payers,
       ROUND(CAST(100.0 * COUNT(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM payments p WHERE p.user_id = u.user_id
       )) / COUNT(*) AS numeric(18, 6)), 1) AS payer_pct
FROM users u
WHERE u.signup_date >= DATE '2026-06-01'
  AND u.signup_date < DATE '2026-07-01'
GROUP BY u.channel
ORDER BY u.channel;

Как проверить результат прямо на интервью

Первая проверка — сумма. 478 + 272 + 292 = 1042 пользователя, 138 + 53 + 91 = 282 плательщика; общая доля 27,1%. Если интервьюер знает общее число, он сверит именно его.

Вторая — строк всего три, а каналов в базе четыре. Это не ошибка запроса: регистрации из paid_search начинаются 1 июля. На собеседовании такую вещь стоит сказать вслух: «канала paid_search в июне нет — проверю минимальную дату регистрации по нему». Молча удивиться или молча промолчать хуже.

Третья — что было бы при прямом соединении. Запрос ниже показывает цену ошибки: после LEFT JOIN payments строк становится 1261 вместо 1042, а строк платежей 501 при 282 плательщиках. Кандидат, который поделит COUNT(p.payment_id) на COUNT(*), получит 39,7% вместо 27,1% и уверенно назовёт неверную долю. Привычка сравнивать число строк до и после JOIN ловит эту ошибку за десять секунд.

SELECT COUNT(*) AS rows_after_join,
       COUNT(DISTINCT u.user_id) AS users,
       COUNT(p.payment_id) AS payment_rows,
       COUNT(DISTINCT p.user_id) AS payers
FROM users u
LEFT JOIN payments p ON p.user_id = u.user_id
WHERE u.signup_date >= DATE '2026-06-01'
  AND u.signup_date < DATE '2026-07-01';

Пример вопроса о метрике: как измерить успех экспорта отчётов

Вопрос звучит так: «Мы сделали выгрузку отчёта в файл. Как понять, что функция работает?» Слабый ответ — список из восьми метрик. Сильный начинается с вопроса, какое решение команда примет по этой цифре: развивать функцию, оставить как есть или убрать. Затем — одна основная метрика с явным знаменателем, одна-две ограничительные и способ проверить данные.

Основная метрика здесь — доля авторов отчёта, которые выгрузили его в течение семи дней после первого отчёта. Знаменатель — не все зарегистрированные, а те, кому функция вообще доступна по сценарию: у кого есть отчёт. Разница существенная: 988 экспортёров от всех 4613 регистраций — 21,4%, а от авторов отчётов картина совсем другая. Окно в семь дней требует зрелости: берём только тех, чей первый отчёт создан до 24 августа, потому что данные заканчиваются 30 августа.

Ограничительная метрика — что экспорт не заменил работу внутри продукта: например, доля авторов, которые вернулись в отчёт после выгрузки. Её рост не обязателен, а резкое падение — повод для разговора. Подробные продуктовые кейсы — в разборе метрик и кейсов на собеседовании продуктового аналитика и в кейс-интервью; о том, чем вообще занят продуктовый аналитик, — отдельная статья.

WITH first_report AS (
  SELECT user_id, MIN(event_time) AS report_at
  FROM events
  WHERE event_name = 'report_created'
  GROUP BY user_id
)
SELECT COUNT(*) AS report_creators,
       COUNT(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM events e
         WHERE e.user_id = r.user_id
           AND e.event_name = 'export_completed'
           AND e.event_time >= r.report_at
           AND e.event_time < r.report_at + INTERVAL '7 days'
       )) AS exported_7d,
       (SELECT COUNT(DISTINCT user_id) FROM events
        WHERE event_name = 'export_completed') AS exporters_total,
       (SELECT COUNT(DISTINCT e.user_id) FROM events e
        WHERE e.event_name = 'export_completed'
          AND NOT EXISTS (
            SELECT 1 FROM events c
            WHERE c.user_id = e.user_id AND c.event_name = 'report_created'
          )) AS exporters_without_report
FROM first_report r
WHERE r.report_at < TIMESTAMP '2026-08-24 00:00:00';

Что в этом примере ценит интервьюер

Основная цифра — 612 из 1611, то есть 38,0%. Но интереснее последний столбец: 331 человек выгрузил отчёт, ни разу не создав его. Числитель не вкладывается в знаменатель, и это надо сказать до любых выводов. Объяснений минимум два: люди выгружают чужие отчёты из общего рабочего пространства, или событие создания отчёта теряется в логировании. Первое меняет определение метрики (знаменатель — те, кто видел отчёт, а не создавал), второе — повод идти к разработчикам.

На собеседовании не нужно угадать правильное объяснение. Нужно заметить расхождение, назвать гипотезы и сказать, чем их различить: проверить, состоят ли эти 331 человека в рабочих пространствах с другими авторами. Такой ход ценится выше, чем безупречная формулировка метрики, построенной на непроверенных данных.

Пример задачи по статистике: значим ли рост конверсии

Условие: «В контроле 1000 пользователей и 100 конверсий, в тесте 1000 и 120. Можно ли выкатывать?» Это условный пример, числа подобраны так, чтобы считать на бумаге. Конверсии 10% и 12%, разница 2 процентных пункта.

Объединённая доля p = 220 / 2000 = 0,11. Стандартная ошибка разницы при нулевой гипотезе: √(0,11 · 0,89 · (1/1000 + 1/1000)) ≈ 0,0140. Статистика z = 0,02 / 0,0140 ≈ 1,43, двустороннее p-value ≈ 0,15. 95-процентный доверительный интервал разницы — примерно от −0,7 до +4,7 п.п.: он накрывает ноль. Вывод: данные не позволяют утверждать, что эффект есть, но и не доказывают, что его нет.

Сильный ответ на этом не останавливается. Мощность такого теста для настоящего эффекта в 2 п.п. — около 30%: даже если вариант действительно лучше, в семи случаях из десяти тест этого не покажет. Чтобы ловить такой эффект с мощностью 80% при alpha 0,05, нужно примерно 3840 пользователей в группе; быстрая оценка 16 · p̄(1 − p̄) / δ² даёт близкое число, около 3900. Значит, правильный ответ — «не выкатывать на основании этого теста и не закрывать идею, а оценить, можно ли набрать нужный объём». Подробнее о типичных вопросах — в статье о статистике на собеседовании аналитика.

from math import sqrt
from scipy.stats import norm

x1, n1, x2, n2 = 100, 1000, 120, 1000
p1, p2 = x1 / n1, x2 / n2
p = (x1 + x2) / (n1 + n2)
z = (p2 - p1) / sqrt(p * (1 - p) * (1 / n1 + 1 / n2))
p_value = 2 * norm.sf(abs(z))
se = sqrt(p1 * (1 - p1) / n1 + p2 * (1 - p2) / n2)
low, high = p2 - p1 - 1.96 * se, p2 - p1 + 1.96 * se
power = norm.sf(norm.ppf(0.975) - (p2 - p1) / se)

za, zb, pbar = norm.ppf(0.975), norm.ppf(0.8), (p1 + p2) / 2
n_needed = (za * sqrt(2 * pbar * (1 - pbar)) + zb * sqrt(p1 * (1 - p1) + p2 * (1 - p2))) ** 2 / (p2 - p1) ** 2

print(f"z = {z:.2f}, p = {p_value:.3f}")          # z = 1.43, p = 0.153
print(f"95% ДИ: {low:+.4f} .. {high:+.4f}")       # -0.0074 .. +0.0474
print(f"мощность = {power:.2f}")                  # 0.30
print(f"нужно на группу: {n_needed:.0f}")         # 3841

Логика, Excel, Python и ML: секции, которые бывают не везде

Логические задачи и задачи на оценку («сколько заказов такси в городе за день») есть не во всех компаниях — спросите о них на скрининге. Их цель — увидеть, как вы раскладываете неизвестное на допущения, а не проверить знание ответа. Разбор подходов — в статье о логических задачах на собеседовании.

Excel проверяют чаще на позициях BI- и финансового аналитика: сводные таблицы, ВПР или ИНДЕКС с ПОИСКПОЗ, условное форматирование, иногда небольшая модель. Что спрашивают и как не утонуть в формулах — в материалах Excel на собеседовании аналитика и собеседование BI-аналитика.

Python на позиции аналитика данных обычно означает pandas: группировки, соединения, работа с датами и пропусками. Если в вакансии он указан как обязательный, добавьте в план три-четыре задачи из подборки Python и pandas на собеседовании; если сомневаетесь, на что делать ставку, прочитайте SQL или Python: что учить первым. Для ролей на стыке с машинным обучением отдельно готовят метрики моделей: precision, recall, F1 и ROC-AUC и собеседование Data Scientist. Инженерный трек описан в разборе собеседования Data Engineer.

Поведенческое интервью и финал с командой

Поведенческие вопросы звучат как «расскажите о случае, когда…»: вы ошиблись в расчёте, заказчик не согласился с выводом, сроки горели. Готовьте три-четыре истории заранее по схеме STAR: ситуация, задача, ваши действия, результат. Самое частое слабое место — действия, где «мы» скрывает, что сделали лично вы. Одна история может отвечать на несколько вопросов, если в ней есть конфликт, ошибка и проверяемый итог.

Финал часто проходит с будущим руководителем и командой. Здесь иногда дают ещё один кейс, но в основном выясняют совпадение ожиданий. Подготовьте вопросы работодателю: откуда берутся задачи, кто владеет данными, как часто решения принимают по анализу, а не вопреки ему. Ответы на них помогут вам выбрать между предложениями — это не меньше половины смысла финала.

План подготовки к собеседованию по дням

План рассчитан на 1,5–2 часа в будни и 3–4 часа в выходные. Если до встречи неделя, оставьте дни 1, 3, 5, 7, 9, 12 и 13; если у вас нет тестового, освободившиеся дни отдайте SQL. Отличие от подготовки к конкретной компании — в том, что здесь нет ставки на один формат: например, для Яндекса или Сбера, Т-Банка, Ozon и Авито план стоит подстроить под их опубликованные этапы.

Чек-лист за день до и в день собеседования

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

• Проверьте ссылку на встречу, камеру, микрофон и зарядку; для онлайн-кодинга откройте редактор, в котором будете писать.
• Положите рядом лист бумаги: на нём удобно рисовать схему таблиц и считать на ходу.
• Перечитайте вакансию и свои заметки о компании: продукт, модель денег, что могли бы измерять.
• Вслух проговорите рассказ о себе один раз — не больше, чтобы он не звучал заученным.
• Выпишите три вопроса команде, которые действительно влияют на ваше решение.
• На SQL-секции: переспросить условие, назвать зерно таблиц, план до кода, проверка числа строк и суммы.
• На кейсе: сначала решение, которое примет команда, потом метрика и знаменатель, потом данные.
• Если не знаете ответ — скажите, как бы его нашли. Это лучше уверенной выдумки.
• После встречи сразу запишите вопросы, на которых споткнулись: это сырьё для следующей подготовки.

Типичные провалы и как их избежать

Большинство отказов на технических этапах связаны не с незнанием синтаксиса, а с поведением. Ниже — частые сценарии и то, что их предотвращает. Все они тренируются на обычных задачах, если с первого дня делать проверку результата обязательной частью решения.

Что делать после отказа

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

Попросите обратную связь у рекрутера: коротко и без спора, например «Подскажите, пожалуйста, на каком этапе и в какой области мне стоит подтянуться». Отвечают не все, и это не повод настаивать. Если ответ пришёл, сопоставьте его со своими записями: обычно совпадает одна-две темы.

Дальше — короткий цикл на неделю: две-три самые слабые темы, задачи именно по ним и одно пробное интервью. Если проблема в SQL-основе, полезнее пройти маршрут изучения SQL с нуля и порешать задачи аналитика данных на реальных вопросах, чем гонять подборки «топ-50 вопросов». Если вы меняете профессию и отказы идут на скрининге, перечитайте как стать аналитиком данных с нуля и проверьте, совпадают ли роль в резюме и роль в отклике.

Повторно откликаться в ту же компанию обычно можно через несколько месяцев; точный срок спросите у рекрутера, правила у компаний разные.

Частые вопросы

Если какой-то этап кажется непонятным, начните с подробного разбора по нему — ссылки стоят в таблице этапов выше — и с ежедневных задач SQL с проверкой результата.