Стажировка аналитика данных: отбор, задачи и подготовка

Коротко: как готовиться к стажировке

Уточните условия актуальной программы на официальной странице: кому она доступна, формат, сроки, оплачиваемость и этапы. Для технической части повторите SQL до JOIN и группировок, базовую статистику, таблицы и объяснение метрики. Подготовьте один учебный проект: вопрос, источник, запрос, контроль результата, ограничение и то, что вы исправили после замечания. На интервью объясняйте ход мысли, а не только правильную цифру.

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

Стажировка и junior: что сравнивать

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

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

Какие этапы отбора возможны

Анкета и резюме помогают понять интерес к роли и базу. Онлайн-тест может включать арифметику, логику, SQL или чтение таблицы. Техническая встреча даёт задачу с уточнениями и проверкой результата; бизнесовая — разговор о цели анализа и выводе. Финальная встреча с командой может показать рабочий процесс. Порядок, наличие и сложность не универсальны.

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

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

SQL: что показать без сложного синтаксиса

Перед запросом назовите единицу результата: пользователь, заказ, рейс или событие. Если один пользователь имеет несколько событий, COUNT(*) после JOIN не считает пользователей. Сначала определите период и целевое действие, затем соберите таблицы и проверьте итог альтернативным подсчётом. Во время разговора можно честно забыть название функции и описать логику словами; хуже уверенно написать запрос с неверным знаменателем.

Тренировочное условие на учебной базе Northstar: «Сколько пользователей зарегистрировалось по каждому каналу и сколько из них создали workspace?». Один пользователь может создавать события многократно, поэтому сначала сверните события до множества user_id, затем соедините с users. Проверенный запрос и итог приведены ниже в отдельном блоке. Это упражнение создано для статьи, а не взято из отбора компании.

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

Учебная SQL-задача: решение и контроль

В маленькой учебной копии Northstar одна строка users — зарегистрированный человек, одна строка events — действие. За первую неделю июня 2026 года в users 18 строк. Запрос считает число регистраций и пользователей с workspace_created по каналу, не число событий. Получается organic 6/5, paid_search 6/2, referral 3/2, partner 3/1. Всего 18 зарегистрированных и 10 с полезным действием; суммы по каналам должны совпасть с отдельным COUNT(DISTINCT user_id) по целевым событиям.

Слабый кандидат посчитает COUNT(*) после JOIN и может получить больше регистраций в канале с повторными событиями. Сильный перед запросом скажет, что канал лежит у пользователя, действие — у события, а число людей требует уникального user_id. Следующий вопрос — когда событие должно произойти относительно регистрации и какое окно активации нужно бизнесу. В текущем упражнении считаем событие в доступном учебном срезе, не объявляем это универсальной активацией.

Сверка суммы по каналам — часть решения, а не красивое дополнение. Шесть organic, шесть paid_search, три partner и три referral дают 18 зарегистрированных. Пользователи с workspace_created: пять, два, один и два — всего 10. Если расчёт по событиям даст иное число, сначала проверьте, не посчитали ли повторное событие одного человека дважды. Если в реальном продукте человек может сменить канал, нужно договориться, какой канал приписан регистрации; в этой учебной базе канал хранится в users.

WITH activated AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_name = 'workspace_created'
)
SELECT u.channel, COUNT(*) AS signups,
       COUNT(a.user_id) AS with_workspace
FROM users u
LEFT JOIN activated a ON a.user_id = u.user_id
GROUP BY u.channel
ORDER BY u.channel;

Арифметика, статистика и продуктовый вопрос

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

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

Python и таблицы: маленькое воспроизводимое задание

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

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

Учебный проект на собеседовании: что рассказывать

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

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

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

Десять вопросов на собеседовании стажёра

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

После ответа на каждый вопрос полезно добавить одну проверку. Например, на вопрос о LEFT JOIN можно сказать: «Он сохраняет пользователей без события; после запроса я сверю число строк и пользователей с отдельным подсчётом». На вопрос о графике — «Сначала проверю ось и фильтры, потом посмотрю исходные числа». Для стажировки не требуется знать все редкие приёмы; требуется не принять правдоподобную ошибку за правильный результат. Эта привычка видна даже в короткой задаче.

Как задавать вопросы о программе

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

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

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

Ошибки кандидата и их последствия

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

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

План подготовки на две недели

Дни 1–3: повторите SELECT, WHERE, GROUP BY и ключи, решите по одной новой задаче с контролем. Дни 4–6: JOIN и оконные даты, потренируйте объяснение зерна вслух. Дни 7–8: один проект, README и короткая записка. Дни 9–10: доли, медиана, базовая статистическая осторожность. Дни 11–12: пробный кейс с уточнением цели и ограничения. День 13: рассказ об ошибке и своём действии. День 14: проверьте текущие условия программы, ссылки и вопросы команде.

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

Если программа нацелена на продуктовые метрики, замените часть упражнений по Python на определения событий и когорт. Если это BI-отчётность, уделите больше времени сверке источника и формул в таблице. Общий список тем нельзя механически выполнить одинаково для всех стажировок. В последний день полезно решить одну незнакомую задачу вместе с человеком, который будет прерывать вас уточнениями. Это ближе к интервью, чем ещё один проход по конспекту.

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

Можно ли попасть на стажировку без опыта? Условия зависят от программы; учебные проекты помогают показать базу, но не гарантируют приглашение. Что спрашивают на собеседовании стажёра аналитика? Часто проверяют ход SQL-решения, арифметику, метрику и способность объяснить проект; точный набор уточняйте у компании. Сколько длится стажировка? Единого срока нет, смотрите актуальную страницу программы. Нужно ли знать Python? Это зависит от задач; SQL и умение проверить число пригодятся во многих аналитических ролях.

Возьмите учебный SQL-запрос из этой статьи и выполните его сами на доступной базе Northstar. Затем объясните, почему COUNT(*) после сырого JOIN был бы неверен. Для следующего шага подготовьте один честный проект и рассказ о нём на минуту; это пригодится независимо от формата отбора.

После тренировки попробуйте объяснить запрос человеку, который не знает SQL. Скажите, кто попал в выборку, что значит «создал workspace», какой период покрыт и чего итог не доказывает. Если без кода объяснение не получается, вернитесь к формулировке вопроса. На стажировке аналитика часто ценят именно эту связку: корректный расчёт и понятная передача результата тому, кто принимает решение.