6 вопросов на собеседовании джуна: что я реально спрашиваю и каких ответов жду

Привет, аналитики! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Когда мы говорим о собеседованиях, то очень важно понимать уровень позиции, на которую идет набор. В зависимости от этого необходимо корректировать ожидания. Я не жду от джуна идеального SQL на уровне сеньора и 5 лет опыта. Мне важно понять:

😶 Понимает ли человек базовые принципы;
😶 Умеет ли думать;
😶 Готов ли учиться и не боится ли данных.

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

1️⃣ «Расскажи о себе и почему ты хочешь стать аналитиком данных?»

Что я жду: человек объясняет, как он понял, чем аналитик отличается от разработчика/маркетолога/финансиста. Почему данные — это именно то, чем ему хочется заниматься. Приводит 1–2 примера из жизни/курса, например: «Когда я сделал дашборд по продажам на курсе и увидел, где компания теряет 30%, я понял, что хочу этим заниматься».

2️⃣ Базовый SQL-вопрос:

«Есть таблица orders (id, user_id, amount, order_date). Напиши запрос, который покажет топ-5 пользователей по сумме заказов за последний месяц».

Что я жду: понимание GROUP BY + ORDER BY + LIMIT и знание, как работать с датами (например, WHERE order_date >= date ’2026-03-01’). Не обязательно идеальный синтаксис, главное — логика.

3️⃣ «Как бы ты посчитал средний чек и медианный чек? В чём разница?»

Что я жду: чёткое объяснение: средний = SUM(amount) / COUNT(*), медианный — 50-й перцентиль, и почему медиана важнее при выбросах — один клиент на 500 тыс. руб. может сильно исказить средний чек.

4️⃣ «Представь: тебе дали таблицу с продажами за год. Там 15% пропущенных значений в колонке amount. Что будешь делать?»

Что я жду (один из вариантов):
➖ Сначала посмотрю, почему они пропущенные (возможно, техническая ошибка).
➖ Если техническая — заполню медианой или средним по сегменту.
➖ Если бизнес-логика — оставлю как NULL или создам отдельную категорию «неизвестно». Главное, чтобы человек не сказал просто «не буду учитывать пустые строки».

5️⃣ Мини-кейс (самый важный вопрос):

«Продажи в категории “кредиты” упали на 25 % за последний месяц. Что ты сделаешь первым делом?»

Что я жду (структура ответа):
🟠 Проверить данные — не ошибка ли в выгрузке;
🟠 Разложить по сегментам — найти группу клиентов, в которых произошло падение;
🟠 Посмотреть динамику предыдущих лет — возможно, сезонный фактор;
🟠 Сформулировать 2–3 гипотезы.
Кто начинает сразу с «запустим рекламу» — это сразу минус. Мне нужен аналитик, а не советчик.

6️⃣ Поведенческий вопрос:

«Были ли у тебя конфликты на прошлых местах работы. Как их урегулировал?»

Что я жду: честную историю. Важно услышать, как человек справился с ситуацией, кого обвинил в конфликте, как долго продолжался конфликт и повлиял ли на рабочий процесс?

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

🟠 Записаться на поток с моим участием: simulative.ru/data-analyst

📈 Симулейтив | ВК | YouTube

SQL-фишки и ошибки: RANK(), DENSE_RANK(), ROW_NUMBER() и BETWEEN

Всем привет! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

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

1️⃣ Разница между RANK(), DENSE_RANK() и ROW_NUMBER()

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

➖ ROW_NUMBER() присваивает уникальный номер каждой строке, даже если значения одинаковые. Игнорирует дубликаты, просто нумерует по порядку. Применяется, когда нужны уникальные ID для строк, например, для пагинации. Также часто применяется при дедупликации.

Например, нам нужно найти топ-5 продаж по сумме:

SELECT id, product, amount, ROW_NUMBER() OVER (ORDER BY amount DESC) AS rn FROM sales;

В результате, если два товара по 100 рублей, один получит 1, другой 2 и т. д. То есть будет 1, 2, 3. Комбинируйте с CTE или подзапросом для удаления дублей.

➖ RANK() присваивает ранг с учётом дубликатов — одинаковые значения получают один ранг, но следующий пропускается. Применяется, когда важна «ничья», как в спортивных рейтингах или топах с пропусками.

Например, нам нужно определить ранг продуктов по продажам в категории:

SELECT id, product, amount, RANK() OVER (PARTITION BY product ORDER BY amount DESC) AS rank FROM sales;

Результат: если у вас две строки с продажами по 100 рублей, то оба будут иметь ранг 1, а следующий 3. То есть будет 1, 1, 3.

➖ DENSE_RANK() — как RANK, но без пропусков. Дубли получают один ранг, а следующий идёт подряд.

Например, нам нужно определить ранг по датам продаж:

SELECT id, product, date, DENSE_RANK() OVER (ORDER BY date) AS dense_rank FROM sales;

Результат: если у вас 2 ранга выпали на одну дату, то оба будут равны 1, следующий 2 (не 3). То есть будет 1, 1, 2.

2️⃣ BETWEEN
Оператор BETWEEN проверяет, входит ли значение в диапазон. Он применяется для фильтрации дат, чисел, строк:

WHERE date BETWEEN '2023-01-01' AND '2023-12-31'

Например, нам нужно собрать продажи в диапазоне сумм:

SELECT * FROM sales
WHERE amount BETWEEN 50 AND 100;

Результат будет включать и 50, и 100, и все что между ними.

Частые ошибки:
➖ BETWEEN включает оба значения. Если вам не нужно включать оба из них или одно из них, то используйте > и/или <.
➖ Особенности работы с датами и временем. Если данные в витрине указаны с временем (‘2023-01-01 00:00:00’), может between ‘2023-01-01’ пропустить их. Используйте TRUNC(date) или >= AND <.

Надеюсь, что теперь вы знаете, чем отличаются эти функции и когда и как их применять. Ставьте 🔥, если было полезно!

📈 Симулейтив | ВК | YouTube

Мастер-класс по SQL уже через 1,5 часа

Вместе с Евгением Буториным, ментором курса «Аналитик данных», мы решим несколько задач по SQL и выполним полноценное ТЗ от клиента. Не пропустите вебинар в 19:00 МСК!

😶 Зарегистрироваться

📈 Симулейтив | ВК | YouTube

По многочисленным просьбам — повторяем мастер-класс по SQL

Мы получили огромное количество положительной обратной связи. Прикрепляем комментарии! Спасибо вам 🧡

Мы редко проводим такое, но в этот раз решили сделать повтор вебинара и дать шанс тем, кто очень хотел прийти, но не получилось. 

Напоминаем, что вас ждёт: 
— Разберём SQL как главный инструмент аналитика;
— Решаем задачи по SQL и реальные задачи бизнеса.

❗️ Встречаемся вновь сегодня 8 апреля в 13:00 и 19:00 МСК.

➡️ Прямая ссылка на комнату

📈 Симулейтив | ВК | YouTube

Как я убрал рутину из ежемесячных отчётов навсегда: Power Pivot + меры в DAX

Всем привет! С вами Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

За 5 лет в аналитике я устал от одной и той же боли: обновление отчётов руками. Да, данные в отчёт проливались через Power Query автоматически (через кнопку «Обновить всё»), но метрики были нестандартные.

Например, у нас есть показатель, когда на одну формулу накладываем другие. В итоге при добавлении нового месяца приходилось каждый раз протягивать формулы на новый месяц в 25 таблицах и обновлять графики. На это уходило около 30-40 минут рабочего времени.

Теперь обновление отчёта занимает 2 минуты: нажимаю «Обновить всё» — и всё готово. Для этого я загрузил данные из Power Query в модель данных и написал меры, которые позволяют «на лету» считать все нужные вычисления.

Вот как это работает:
➖ Загружаешь сырые данные в модель через Power Query или напрямую в модель Power Pivot;
➖ Пишешь меры на DAX (один раз и навсегда);
➖ Строишь график/сводную таблицу — и больше никогда её не трогаешь.

Пример реальной меры, которую я использую — дельта конверсий (в %):

Delta Conv MoM = 

VAR GKG = 
DIVIDE(CALCULATE(sum(query[sales]), ggroup = “ГКГ”), CALCULATE(sum(query[cnt_cl]), ggroup = “ГКГ”))

VAR CG =
DIVIDE(CALCULATE(sum(query[sales]), ggroup = “ЦГ”), CALCULATE(sum(query[cnt_cl]), ggroup = “ЦГ”))

RETURN

CG - GKG

После этого график «Дельта конверсий» живёт своей жизнью — самостоятельно обновляется и пересчитывается в зависимости от выбранных фильтров.

Конечно, это не единственная мера, но потратить на написание мер 30 минут однократно и сэкономить при этом часы на рутинной работе стоит каждой потраченной минуты.

🟠 Записаться на поток с моим менторством: simulative.ru/data-analyst

📈 Симулейтив | ВК | YouTube

Забирайте модуль по Excel при покупке курса!

Друзья, мы запустили акцию: покупаете любой курс-профессию → получаете наш полноценный модуль по Excel.

Вы научитесь работать с таблицами, сводными, формулами и визуализацией — с базой, без которой не обходится ни один аналитик. А если вы уже профи, повторите основы и закроете пробелы.

📌 Акция действует до 15 апреля включительно на платные курсы Симулейтив (кроме тренингов и магистратуры).

Ваш Excel-бонус уже скучает, успевайте забрать 😉

👉 Оставить заявку

📈 Симулейтив | ВК | YouTube

Одна строчка в SQL, которая экономит время при каждом обновлении отчёта

Привет, коллеги! С вами снова Евгений Буторин, ментор курса «Аналитик данных» 👋🏻

Раньше, когда нужно было обновить отчёт за последний месяц, я либо тянул ВЕСЬ период данных (гигантский объём), либо вручную правил даты в 20 разных местах запроса.

Оба варианта — боль 😥

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

Как это выглядит:

DECLARE @StartDate DATE = add_months(trunc(sysdate,’mm’),-2);
DECLARE @EndDate   DATE = last_day(trunc(sysdate));

DELETE FROM table WHERE Date BETWEEN @StartDate AND @EndDate;

COMMIT;

INSERT INTO table 

SELECT 
    Channel,
    COUNT(*) AS Leads,
    SUM(CASE WHEN Status = 'Купил' THEN 1 ELSE 0 END) AS Sales,
    SUM(CASE WHEN Status = 'Купил' THEN 1 ELSE 0 END) * 1.0 / COUNT(*) AS ConvRate
FROM MarketingLeads
WHERE Date BETWEEN @StartDate AND @EndDate
GROUP BY Channel;

COMMIT;

Всё. Хочу пересчитать апрель 2024 года — меняю переменные на две даты в начале процедуры и запускаю запрос заново. Никаких правок в 20 местах. При этом другие периоды не меняются, что исключает эффект «плавающих данных».

Возможно это выглядит сложно, но на деле мы не становимся сразу сеньорами (старшими аналитиками), мы учимся постоянно и дорабатываем свои скрипты.

➡️ Записаться на поток с моим менторством (стартуем сегодня!): simulative.ru/data-analyst

📈 Симулейтив | ВК | YouTube

😁😆😁 опубликовать анонс вебинара по дата сайенс, 13 апреля 19:00 МСК, спикер Мария Жарова. Вебинар про профессию дата-сайентиста с практикой.

Ссылка на регистрацию https://bothelp.cc/mini?domain=simulative&id=29&utm_source=telegram&utm_medium=social&utm_campaign=webinar&utm_content=10-04-2026-web-1304

👍👍👍👍

Вебинар: всё, что нужно знать о профессии дата-сайентиста

Data Scientist — одна из самых востребованных профессий в аналитике, но вокруг неё до сих пор много путаницы: чем она отличается от машинного и глубокого обучения? Когда одной аналитики недостаточно? И что реально нужно уметь, чтобы получить первую работу?

На вебинаре с Марией Жаровой разложим по полочкам профессию дата-сайентиста — разберёмся в терминах, поговорим о спросе на рынке, требованиях к джунам. И конечно, попрактикуемся — построим модели прогнозирования оттока на реальных данных.

На вебинаре расскажем:
➖ Кто такой дата-сайентист и как различать аббревиатуры DS, ML, DL и AI;
➖ Откуда спрос на эту профессию и какие задачи решают DS в бизнесе;
➖ Какие требования предъявляют к джуну;
➖ Построим модели прогнозирования оттока клиентов банка, сравним подходы по метрикам и интерпретируемости, разберём ключевые факторы оттока.

❗️ Встречаемся 13 апреля в 19:00 МСК

💬 Подключайтесь к эфиру, чтобы задать Марии вопросы про карьеру в Data Science, машинное обучение и практические кейсы.

➡️ Зарегистрироваться на вебинар

📈 Симулейтив | ВК | YouTube

Почему t-test — это всё, что вам нужно в A/B-тестах

Привет! На связи Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала про аналитику кусочек пиццы 👋🏻

В аналитическом сообществе есть негласная иерархия: чем сложнее метод, тем умнее выглядит аналитик. Bootstrap, тест Манна-Уитни, CUPED, байесовские подходы — всё это звучит внушительно на собеседованиях и в статьях на Хабре.

Но на практике в 80% случаев достаточно обычного t-теста.

Что такое t-test и как он работает

T-test проверяет одну простую гипотезу: отличаются ли средние значения метрики в двух группах или нет. Формально он считает t-статистику:

t = (x̄₁ - x̄₂) / √(s₁²/n₁ + s₂²/n₂),
где x̄ — среднее в группе, s² — дисперсия, n — размер выборки.

Дальше по этой статистике считается p-value — вероятность получить такой же или более экстремальный результат при условии, что никакого эффекта нет.

Если p-value < 0.05, эффект считается статистически значимым.

Почему часто всё усложняют

Главный аргумент против t-теста звучит так: «Данные не распределены нормально, значит t-test некорректен». Но на самом деле это не так.

T-test опирается не на нормальность исходных данных, а на нормальность распределения выборочного среднего.

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

На практике при выборке от 1000 наблюдений на группу это условие выполняется почти всегда. А в большинстве продуктовых A/B-тестов выборки именно такого размера или больше.

Однако не стоит пихать t-test во все возможные эксперименты. Иногда он может и не подойти.

Когда t-test действительно не подходит

T-test работает плохо в нескольких ситуациях:

➖ Очень маленькие выборки (до 30 наблюдений на группу). В этом случае ЦПТ ещё не работает в полную силу.

➖ Метрика с экстремальными выбросами — например, выручка, где один крупный платёж может сильно сдвинуть среднее. В таком случае имеет смысл либо сглаживать выбросы и перепроверять результаты тестом Манна-Уитни.

➖ Бинарные метрики с очень низкой конверсией — в этом случае лучше работает z-test для пропорций, хотя при больших выборках разница минимальна.

Во всех остальных случаях t-test справляется.

Зачем тогда все эти сложные методы?

Они решают конкретные задачи — и только их. CUPED снижает дисперсию и позволяет быстрее набрать нужную выборку. Bootstrap помогает строить доверительные интервалы для нестандартных метрик. Линеаризация помогает работать с Ratio-метриками.

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

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

➡️ Записаться на курс по A/B-тестам: simulative.ru/ab-test

📈 Симулейтив | ВК | YouTube

Только 12 и 13 апреля — космические -35% на аналитику! 🚀

В космонавтике без аналитиков никуда. Спутниковые данные, траектории полётов, телеметрия, прогнозы перегрузок — всё это огромные массивы информации, которые нужно обрабатывать, визуализировать и интерпретировать. Именно аналитики помогают принимать точные решения на Земле и за её пределами.

Хотите освоить профессию, востребованную как в аэрокосмической отрасли, так и в любом бизнесе? Время решаться!

📉 До -35% на все курсы Симулейтив (кроме тренингов и программ магистратуры).
⏳ Акция действует всего два дня: 12 и 13 апреля.

Успейте взять курс по аналитике, визуализации данных или data science с выгодой до 35% и не упустите шанс выйти на новую орбиту!

👉 Оставить заявку: simulative.ru/web-cosmos-offer-book

📈 Симулейтив | ВК | YouTube

Зачем нужны временные ряды?

Всем привет, я Павел Беляев, ведущий канала Тимлидское об аналитике и автор нового курса Симулейтив «Временные ряды» 👋🏻

Почему эта тема всегда актуальна для любого аналитика? Очевидно, потому что большая часть данных представляет собой упорядоченные во времени последовательности значений, то есть, собственно, временные ряды! И умение легко обращаться с их свойствами и методами их обработки — необходимый навык в нашем деле.

Вот лишь несколько типовых направлений использования временных рядов.

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

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

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

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

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

Этому и посвящён наш новый курс. Мы разберём всё: от базовой визуализации и проверки стационарности до прогнозирования на Prophet с густой насыщенной практикой в Python.

➡️ Записаться на курс: simulative.ru/time-series

📈 Симулейтив | ВК | YouTube

Через пару часов начинаем вебинар о data science

Напомним, что с Марией Жаровой разложим по полочкам профессию дата-сайентиста — разберёмся в терминах, поговорим о спросе на рынке, требованиях к джунам. И конечно, попрактикуемся — построим модели прогнозирования оттока на реальных данных.

🔔 Зарегистрироваться

📈 Симулейтив | ВК | YouTube

Привет! На связи Валерия Елпатьевская, инженер данных в Альфа Банке и ментор одноимённого курса Симулейтив 👋🏻

Мой путь начался не в IT: филология, преподавание, потом Data Science. Но быстро поняла, что без инженерной базы далеко не уедешь. Пошла разбираться в очередях, оркестрации и архитектуре… и как-то незаметно стала Data Engineer.

Пока вкатывалась в роль, думала, что ничего не понимаю. А через полгода уже объясняла коллегам, как всё работает. На этом пути усвоила 4 урока, которые точно помогут не сдаться:

Урок № 1. Никогда не будет всё понятно. Научитесь кайфовать от этого

Я уже несколько лет пишу код и знаю десятки инструментов, но каждый раз находится тема, которую приходится изучать с нуля. И каждый раз «ничего не понятно». Если сейчас чувствуете то же самое — добро пожаловать в IT!

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

Урок № 2. Не стыдно чего-то не знать

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

Урок № 3. Никто на самом деле ничего не знает

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

Урок № 4. Нейросеть архитектуру не придумает

Сейчас везде кричат, что LLM напишет код за вас. И правда напишет! Только вам же потом придётся его рефакторить и чинить в проде. Круто отдавать моделям рутину или устраивать брейншторм.

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

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

😶 А кому интересно почитать мою большую статью о «войти в айти», добро пожаловать на Хабр: https://habr.com/ru/companies/lanit/articles/842136

📈 Симулейтив | ВК | YouTube

Как одна «незначительная» фича сломала модель в бою

Привет! На связи Мария Жарова, ментор курсов «ML-инженер» и «Дата-сайентист» 👋🏻

Хочу поделиться кейсом, который хорошо показывает, как «безобидный» признак может неожиданно повлиять на модель.

Мы решали задачу предсказания оттока пользователей. Классическая история: табличные данные, градиентный бустинг, аккуратный пайплайн, валидация — всё как надо. На кросс-валидации модель давала стабильный прирост к бейзлайну, метрики выглядели уверенно.

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

Но через несколько дней после выкатки метрики в проде поползли вниз… Сначала думали на данные, потом на инфраструктуру, потом на сдвиг распределений — но оказалось, дело в одной фиче! Как раз «время последнего действия» в обучении считалось относительно фиксированной даты (условно, «срез данных на момент выгрузки»). А в проде — относительно текущего времени.

Звучит безобидно, но по факту:
➖ в обучении модель видела, что«“клиент давно не заходил» — это, например, 30 дней;
➖ в проде это же значение могло стать 60, 90 и т. д., потому что время идёт, а логика пересчёта не была синхронизирована.

В результате распределение признака в проде уплыло относительно train, и модель начала получать значения, которых «не видела» на обучении — поэтому предсказания поехали.

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

Поэтому всегда имейте в виду:
😶 Любая фича, завязанная на время — почти всегда источник проблем, если не продумана логика её расчёта в проде;
😶 Важно проверять не только код обучения, но и код генерации признаков для прода — они должны быть идентичны по смыслу;
😶 Полезно смотреть на распределения признаков: train vs prod, хотя бы на базовом уровне;
😶 Если фича становится топ-важной — к ней должно быть повышенное внимание, потому что именно она может «уронить» модель.

И да, чаще всего модель ломает не сложная математика, а такие вот мелочи, которые сначала кажутся очевидными.

Сохраняйте, чтобы не наступить на те же грабли!