Собеседование в Яндекс на аналитика: этапы и подготовка

Коротко: как готовиться к собеседованию в Яндекс

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

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

Какой процесс официально описан и чего страница не обещает

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

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

Рекрутер: что сказать об опыте и что узнать в ответ

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

Спросите, к какой роли в объявлении относится описание «аналитик-разработчик», как соотносятся программирование, аналитика и доменный блок. Уточните, будет ли письменное задание и разрешён ли выбор домена «статистика или ML». Если ответ пока неизвестен, запишите его как открытый вопрос, а не достройте процесс по отзывам. Важна и обратная сторона: какие задачи команда отдаёт аналитику в первые месяцы и кто проверяет качество данных.

Первое техническое интервью: Python, SQL и краевые случаи

Официальная страница говорит о Python, алгоритмах и структурах данных, SQL с краевыми случаями и тест-кейсах; код пишут в онлайн-редакторе. Это не повод тренировать только скорость синтаксиса. Для каждого SQL-запроса объясните зерно таблиц, пустой результат, NULL, возможный дубль после JOIN и порядок строк, если вывод ограничен. Устный комментарий важен, потому что работа аналитика заканчивается не на успешном запуске.

Например, задача «сколько пользователей создали рабочую область» кажется простой. Таблица events хранит действия, а не пользователей: COUNT(*) отвечает на другой вопрос, если действие может повториться. Сначала определите событие и период, затем COUNT(DISTINCT user_id). Если метрика нужна для когорты регистраций, отдельно решите, включать ли события до или после регистрации и сколько дней даёте пользователю. Показанный ниже учебный ответ не следует переносить на реальный продукт.

Дополнительная репетиция для Python: напишите функцию, которая принимает записи с user_id и временем события, оставляет последнюю запись пользователя и возвращает список в стабильном порядке. До кода уточните, что делать с одинаковым временем, пустым входом, отсутствующим user_id и повреждённым временем. Для небольшого входа хватит словаря и явного правила сравнения; для объёма, который не помещается в память, архитектура будет иной. На интервью оценят не только работающий happy path, но и то, что вы замечаете условия, без которых ответ неоднозначен.

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

Второе техническое интервью: аналитический разговор и домен

В официальном описании этот этап имеет две части: аналитика и область «математическая статистика или ML» в зависимости от опыта и предпочтений. Аналитическая часть — диалог о рабочей ситуации без написания кода. Могут попросить помочь бизнесу с решением или обсудить продуктовые метрики. На такой вопрос полезен маршрут: решение → определение показателя → разрезы и альтернативы → цена ошибки → предложение о проверке.

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

Разберите авторский продуктовый пример: после изменения поиска число открытий карточек выросло, а оплата не изменилась. Слабый вывод — «новый поиск ухудшил качество трафика». Возможны и другие объяснения: поменялся состав пользователей, возникли повторные открытия, задержалась загрузка платежей, карточки стали смотреть раньше в пути. Сначала определите, что является единицей метрики, затем разложите путь по когортам и устройствам и проверьте полноту событий. Только после этого выбирайте эксперимент или наблюдательный анализ для причинного вывода.

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

Финал с командой: доказательство выбора, а не повтор теории

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

Расспросите о владельце метрики, источниках событий, сроке обновления витрин, границе ответственности между аналитиком и инженером. Если команда говорит «строим эксперименты», уточните, кто задаёт primary metric и кто проверяет корректность разбиения. Финал помогает вам проверить содержание работы: совпадает ли она с тем, ради чего вы готовили SQL и аналитические кейсы.

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

Стажировка по аналитике — отдельный маршрут

Страница стажировки Яндекса действительно описывает тестовое задание в Яндекс Контесте и дальнейшие этапы. Этот процесс относится к стажировке, не к каждой штатной вакансии. На странице также есть учебные материалы для подготовки; их наличие не означает, что вы встретите те же задачи в другом потоке или команде. Ориентируйтесь на текущую страницу своей программы и письмо рекрутера.

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

Двенадцать тренировочных вопросов: что проверяют ответы

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

Пять учебных проверок на Northstar: результат и смысл

Эти упражнения выполняются на локальном seedSql из packages/content/sql/workspace.json. Они тренируют разные ошибки: неверное зерно события, неполный день, когортное окно и размножение платежей. Итоги воспроизводятся скриптом apps/site/research/interviews-wave-3/verify.mts; ни одна задача не взята из банка вопросов компании.

Проверьте себя до чтения ответов: (1) сколько зарегистрированных пользователей; (2) сколько разных пользователей открыли приложение 3 июня 2026 по московскому времени; (3) сколько разных пользователей создали рабочую область за весь учебный период; (4) у сколько из зарегистрированных 1 июня был app_open 2 июня; (5) сколько строк платежей и сколько разных плательщиков. Ответы: 18; 6; 10; 2 из 3; 9 строк и 8 плательщиков. Последняя разница появляется потому, что один пользователь платил более одного раза.

Код ниже показывает когорту D1. Сначала фиксируется дата регистрации, затем через EXISTS проверяется именно следующий календарный день. Так мы не размножаем строки при нескольких открытиях. Часы в учебной базе записаны как UTC+3; интервал полуоткрытый, поэтому событие ровно в начале 3 июня не относится ко 2 июня.

SELECT COUNT(*) AS cohort_users,
       COUNT(*) FILTER (WHERE EXISTS (
         SELECT 1 FROM events e
         WHERE e.user_id = u.user_id AND e.event_name = 'app_open'
           AND e.event_time >= TIMESTAMP '2026-06-02 00:00:00'
           AND e.event_time < TIMESTAMP '2026-06-03 00:00:00'
       )) AS d1_users
FROM users u
WHERE signup_date = DATE '2026-06-01';

Как разбирать неизвестный кейс вслух

Допустим, интервьюер говорит: «Активных стало больше, но доля создавших рабочую область упала». Не угадывайте причину. Спросите, что сравниваем: новые регистрации или всех вошедших? Что является моментом активации и сколько времени пользователь мог до неё дойти? Затем разложите долю по каналам, странам и датам; проверьте, не расширился ли знаменатель за счёт свежих пользователей, у которых окно ещё не закрылось.

Назовите две версии, которые дадут разные наблюдения: изменение состава каналов и реальный спад внутри канала после релиза. Для первой достаточно сопоставимых когорт и долей по каналам; для второй нужен журнал релизов, проверка события и сегментные ряды. До проверки вы можете посоветовать сохранить решение под наблюдением и не объявлять рост регистраций успехом. Это авторский учебный кейс, не описание задания Яндекса.

Остальные решения Northstar: четыре коротких запроса

Каждый запрос запускается отдельно после загрузки учебного seedSql. Первый считает зарегистрированных, второй — разных активных за день, третий — пользователей с созданным workspace, четвёртый сравнивает строки платежей и людей. D1-запрос приведён выше. Все пять результатов сверены проверочным скриптом. Для событий COUNT(DISTINCT user_id) отвечает на вопрос о людях, а COUNT(*) — о действиях; иногда числа совпадут случайно, но смысл от этого не станет одинаковым.

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

SELECT count(*) AS users FROM users;

SELECT count(DISTINCT user_id) AS active_users
FROM events
WHERE event_name = 'app_open'
  AND event_time >= TIMESTAMP '2026-06-03 00:00:00'
  AND event_time < TIMESTAMP '2026-06-04 00:00:00';

SELECT count(DISTINCT user_id) AS creators
FROM events
WHERE event_name = 'workspace_created';

SELECT count(*) AS payment_rows,
       count(DISTINCT user_id) AS payers
FROM payments;

Двухнедельный план подготовки по секциям

Дни 1–2: откройте вакансию и официальную страницу трека, спросите рекрутера о составе секций. Дни 3–4: повторите SQL с JOIN, агрегатами, окнами и краевыми случаями; решите новые задачи без подсказки. Дни 5–6: Python и структуры данных, проговорите оценку сложности и тесты. День 7: разберите свой проект и запишите два проверяемых итога.

Дни 8–9: один продуктовый кейс с изменением состава и один бизнесовый с неполным условием. День 10: статистика или ML по согласованному домену. День 11: проговорите ошибку, спорное решение и личный вклад. День 12: репетиция с вопросами собеседника. День 13: вопросы команде и проверка оборудования. День 14: короткое повторение, сон и неизменяемые факты проекта. План распределяет тренировку, а не обещает прохождение отбора.

Ошибки, которые портят даже сильный технический ответ

Первая — смешать программу стажировки со штатной позицией и готовиться к контесту вместо нужной секции. Вторая — знать синтаксис SQL, но не назвать зерно и получить ложную метрику. Третья — приписать тренируемую статистику всем командам, хотя официальный источник разделяет домены. Четвёртая — угадывать причину продуктового изменения по одному графику. Пятая — рассказывать только о коллективном результате и не показывать свой вклад. Шестая — придумывать вопросы Яндекса по чужим пересказам и спорить с интервьюером из-за несоответствия репетиции.

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

Частые вопросы и следующий шаг

Есть ли единый процесс для всех аналитиков Яндекса? Официальная страница подробно описывает трек аналитиков-разработчиков; для другой роли уточните секции у рекрутера. Есть ли контест на штатную позицию? Нельзя выводить это из страницы стажировки. Нужно ли учить весь ML? В описанном треке домен второй встречи зависит от опыта и предпочтений. Какие задачи будут на SQL? Компания перечисляет темы, но не публикует обязательный список задач для каждого кандидата.

Возьмите свою вакансию, составьте таблицу «подтверждено источником / уточнить у рекрутера / потренировать независимо от процесса». Затем решите одну новую SQL-задачу и объясните, почему результат не меняется от повторного события. Такая подготовка оставляет вам рабочий ответ, даже если порядок секций отличается от прочитанной страницы.