Раз вы такие набрали столько много реакций, выкладываю пост про продуктового аналитика / аналитика данных в 2025.

Пост вышел объемный, поэтому дополнительно выпущу пост про основные ошибки в резюме у кандидатов.

📸 Скрининг

< Здесь будет отдельный пост, который поможет его пройти >

📞 Созвон с HR

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

1. Кинули монету 10 раз, какая вероятность, что 5 раз выпал орел
2. Условная вероятность, формула Байеса
3. Про доверительные интервалы, формулу MDE, критерии и так далее
4. Что такое параметрические / непараметрические тесты?
5. Что такое p-value? 
6. Какие есть ограничения у хи-квадрата, t-теста, z-теста?
7. Что проверяет критерий Манна-Уитни?
8. Что такое A/A тест? A/B тест?

Эти вопросы могут всплыть и на технических секциях, поэтому будьте готовы: если их не задали в начале, это не значит, что их не будет дальше

🔗 Пост про MDE
🔗 Пост про p-value
🔗 Формула Байеса и условная вероятность (очень топовый ресурс, раньше на нем сидел очень часто в вузе для подготовки к важным работам).
🔗 Доверительные интервалы (с ресурса выше)
🔗 Сборник задач про вероятности

* Этот этап необязательный, могут сразу назначить следующие секции

🔥 Техническая секция

Тут может быть все, что угодно, но попробую стандартизировать.

🗯 Тренируем задачи с помощью GPT + материалов, которые я скинул.

❤️ В Яндексе была алгосекция (она не во все команды) + бизнес-секция, где будете решать код и раскручивать абстрактный кейс, 90% на A/B тесты. В свое время я плотно сидел на литкоде + тренировкам по алгоритмам от Яндекса, в некоторые компании также спрашивают алгоритмы. Уровень easy / medium на литкоде.

🌏 В Авито две секции определяют твой грейд (задачи на теорию вероятностей + матрица компетенций), был удивлен, что не было кода. Спросили про опыт в ML.

В других компаниях будут гонять по SQL (шпаргалка тут, поможет), Python (pandas, классический на базовый функционал), вопросы про A/B тесты (кто-то может спрашивать глубже, кто-то нет). Базово вопросы про ограничение критериев, оценки тестов, снижения дисперсии, дизайн эксперимента.

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

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

🔗 Про дизайн эксперимента
🔗 CUPED, постстратификация, VWE, про классическое снижение дисперсии
🔗 Продуктовые кейсы
🔗 Сборник материалов с продуктовыми кейсами

😱 Финальная секция

Абсолютно рандомная секция, в различных командах разные вопросы. Кто-то может попросить написать код, а кто-то может за жизнь поспрашивать, кто-то может спросить за техническую составляющую.

🙊 По своим собесам скажу, что у меня были бизнес-кейсы + технические финалы. Тут зачастую сидит CPO / Product Lead + Analytics Lead / Analytics Head. Можно зачастую поговорить на абстрактные темы: какие ожидания (но конечно это лучше выяснять в начале), сколько человек в команде, какие проекты, какие вызовы. Это все очень интересно, так как по факту придется с этим работать. Можно уточнить какие есть минусы, что можно улучшить. Здесь диалог)

⚠️ Перед каждым собесом я практиковался следующим образом: просил GPT сформировать задания, которые подходят под то, какая команда собеседует. Обычно это я выясняю у HR, так как хочется понять, к чему готовиться. У кого-то есть уже припасенный лендинг под это, у кого-то нет)

P.S: Вся информация сформирована из моих личных собеседований и может отличаться от того, что у вас было.

А вы собесились недавно? Ставьте 🐳, если пост зашел! Пишите в комментариях, что спрашивали!

Как повысить шансы пройти скрининг по резюме

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

Сугубо мое мнение

Я собрал несколько моментов, которые повысят вероятность пройти этот этап.

🍪🍪 Курсы и проекты: что считается за опыт

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

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

🏆 Обязанности и достижения

Одна из главных ошибок в резюме - это описание работы в формате списка ТОЛЬКО обязанностей: например, я делал выгрузки, создал отчет по трекингу основных метрик, настроил алерты и т.д. Это звучит слишком сухо и не даёт понимания, что именно изменилось в бизнесе благодаря вашей работе. Важно писать и обязанности, и достижения.

Намного сильнее работает описание через результат.

🟢 Построил дашборд для команды продаж, который улучшил метрику X на p%.

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

👩‍💻 Технический стек должен быть в опыте

Часто вижу такую картину: внизу резюме есть раздел Навыки (особенно в шаблоне hh), где написаны SQL, Python, SuperSet и ещё десяток инструментов. Но в описании работы о них ни слова. Проблема в том, что рекрутер тратит на просмотр резюме очень мало времени, и до этого раздела он может просто не дойти (как правило, 6 секунд). Поэтому лучше в каждом месте работы отдельно указать, с чем именно работали. Так увеличивается шанс попасть в поиск по ключевым словам.

🤟 Нерелевантный опыт и должности

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

Тоже касается должностей, видел и таких ребят, кто указывает все подряд, и жнец, и швец, и на дуде игрец. Аналитик данных / Разработчик / Архитектор в одной строчке выглядит размыто. Лучше выбрать одно направление: например, Продуктовый аналитик или Аналитик Данных.

💳 Зарплатные ожидания

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

🏃‍♀️ Откликаемся на все варианты, которые представлены на рынке по вашему профилю

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

Не ограничивайтесь только hh или getmatch. У многих компаний вакансии раньше появляются на своих сайтах.

Все эти приёмы в сумме не дают 100% гарантии, но заметно повышают шансы пройти скрининг

У меня сейчас было 10+ реджектов от одной компании и это нормально, куда-то пройдете, 100%

Если понравился пост, ставьте 🐳, пишите комментарии. А какие у вас есть советы? Делитесь.

Симуляция A/A тестов и зачем это нужно

A/A тест — это эксперимент, где обе группы одинаковы. Он нужен, чтобы проверить: работает ли наша система экспериментов честно и не выдумывает эффекты там, где их нет.

Самое главное, для чего мы проводим синтетический A/A тест (на большом количестве итераций) — это контроль ошибки первого рода. Ошибка первого рода (False Positive Rate) — это вероятность найти изменения там, где их нет. То есть мы заранее знаем, какой процент экспериментов ложно прокрасится (обычно, это очень маленькие вероятности в районе 0.01, 0.05, иногда 0.1, но достаточно редко).

Зачастую это нужно для проверки сплитовалке на определенном срезе пользователей / с кастомными метриками (которые будут участвовать в эксперименте).

В некоторых компаниях есть команда A/B платформы, которая занимается валидацией метрик, применением критериев к различным выборкам / метрикам.

В компании важно уметь пересчитывать ошибки I и II рода на разных срезах. Без этого мы не можем быть уверены, что группы изначально одинаковые. Если этого не будет, то утверждать о том, что изначально выборки были одинаковые (предположение для A/B теста) сказать нельзя. Метрики на предпериоде до эксперимента могут разъезжаться.

В каких случаях стоит запускать проверки?

1. Когда в компании уже есть процесс пересчёта метрик и нужно убедиться, что он работает корректно.
2. Когда появляется новая поверхность или метрика. Важно проверить, что группы не расходятся случайно.
3. Когда есть риск выбросов: несколько объектов могут сильно влиять на результат и завышать вероятность ложных срабатываний.

Я видел историю, когда был запущен эксперимент одним аналитиком, но при подведении итогов на определенном срезе покупателей (кто фактически видел эту фичу), получили ошибку первого рода 0.15 на целевой метрике (по которой мы принимаем решением), хотя ожидалось 0.05, то есть ошибку первого рода мы не контролируем => эксперимент невалиден. Затем я посмотрел, что происходило с группами на предпериоде, целевая метрика по группам разъехалась очень сильно, а это нарушает ключевое предположение A/B теста.

Как запустить синтетическую проверку?

Давайте запустим симуляцию: 10 000 A/A тестов на случайных группах и посмотрим, как ведут себя p-value

import numpy as np
import matplotlib.pyplot as plt
from scipy import stats

data = np.random.normal(loc=100, scale=10, size=10_000)
alpha = 0.05

p_values = []

for _ in range(10_000):

    idx = np.random.permutation(len(data))
    
    a_idx, b_idx = np.array_split(idx, 2)
    a, b = data[a_idx], data[b_idx]
    
    _, p = stats.ttest_ind(a, b)
    p_values.append(p)

print('Ошибка первого рода:', np.mean(np.array(p_values) < alpha)) # в идеале здесь будет значение в районе 0.05
plt.hist(p_values, bins=50, edgecolor="black")
plt.xlabel("p-value")
plt.title("Распределение p-value в A/A тесте (10000 симуляций)")
plt.show()

Что мы ожидаем увидеть в ходе синтетического A/A теста?

Равномерное распределение p-value, которое говорит нам о том, что все хорошо, нет проблем. Это значит, что система работает корректно: ложные срабатывания происходят ровно с той частотой, которую мы задали. Можно думать про это как про честную монетку (предположим, что мы подкидываем ее 100 раз, а затем проводим 10 000 симуляций): иногда выпадет значимо, но ровно с той частотой, которую мы сами задали (например, 5% при alpha=0.05).

A/A тесты — это краш-тест для платформы экспериментов. Если они честные, бизнес может доверять результатам A/B.

Понравился пост? Ставьте 🐳, пишите комментарии, что думаете по поводу A/A тестов.

Управление ожиданиями

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

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

❓ Что это значит на практике

1. Заказчик хочет ответ завтра, а тебе нужна неделя.
2. Продукт ждёт +20% к метрике, а по факту выходит +5%.
3. Руководитель думает, что посчитать за час, но есть бизнес-логика, сложная обработка данных и нужен контекст.

🥳 Если это знакомо, то пост для вас 🥳

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

🙊 Говорите прямо, если есть проблемы в процессах. В таких условиях срок может затянуться. Если прилетела срочная задача, честно оцените, сколько времени нужно именно вам, и добавьте себе несколько дней запаса. Сделайте себе несколько кружек кофе ☕️
Если влёты регулярны, обсудите с лидом процесс постановки задач на аналитику.

Честные сроки, постепенные результаты и регулярный апдейт = доверие команды и стейкхолдеров.

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

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

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

Аналитик отвечает не только за цифры, но и за то, чтобы команда видела ценность даже в негативном результате.

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

Ставьте 🐳, если пост был полезен!
Я уверен, у каждого был случай, когда всё пошло не так, как ожидали. Будет интересно почитать ваши истории.

@zasql_python

Рефакторинг дашбордов

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

Почему так происходит?

❓ Меняется логика в источниках. Источник, на который завязан дашборд, может стать неподдерживаемым. Автоматизация может падать, события меняются, а узнаём мы об этом только спустя дни, когда метрики уже просели. Обычно это происходит так, что продукт сам находит проблему и приходит к аналитику.

💻 Неоптимальные запросы. Скрипт, формирующий таблицу, становится медленным. Чарты грузятся по миллион лет, появляются ошибки при построении графиков, таймауты, ошибка в источнике данных и тд.

📕 Падает читаемость. Кор-дашборд должен закрывать 80% потребностей парой метрик и фильтрами. Но как только бизнес начинает добавлять всё подряд, дашборд превращается в мусорку. Читаемость и смысл теряются, а основной вопрос, на который хотел ответить бизнес отчетностью размывается.

🤗🤗🤗 Нет поддержки. Часто аналитики забивают на отчётность, вспоминают о ней только при баге или новой хотелке бизнеса. Хотелка бизнеса: а что, если нам посмотреть на срез тех людей, кто кушал пиццу вчера утром?

😝 Что делать?

🍪🍪 Оптимизировать скрипты заранее. Использовать планы запросов в БД, избегать лишних джойнов. Если работаете со вьюхами, подумайте о том, чтобы перекладывать данные в материализованную таблицу. Это позволит ускорить построение.

⚠ Ставить алерты и сенсоры. Если данные не доехали, доверие к отчётности подрывается. Решение простое: алерты + сенсоры.

🔽 Пример сенсора в Airflow:

 python
from airflow import DAG
from airflow.providers.postgres.sensors.postgres import PostgresSensor
from airflow.utils.dates import days_ago

with DAG(
    dag_id="example_postgres_sensor",
    start_date=days_ago(1),
    schedule_interval="@daily",
    catchup=False,
) as dag:

    wait_for_data = PostgresSensor(
        task_id="wait_for_data",
        postgres_conn_id="zasql_python",
        sql="""
            SELECT 1
            FROM my_schema.my_table
            WHERE date = '{{ ds }}'
            LIMIT 1;
        """,
        poke_interval=60,  # проверка раз в минуту
        timeout=60 * 60,   # максимум час
        soft_fail=False,   # если True — скипнет таску, а не упадёт
    )

Плюс: в Superset (и других BI-системах) есть логи просмотров. Если графики никто не открывает, их стоит убрать, чтобы не перегружать дашборд. В Superset есть еще можно настроить правило: Если данных за сегодня по условию нет, то высылаем алерт на почту. Не реклама, честно.

🙊 Договариваться с бизнесом про цель дашборда. Аналитик не должен тратить недели на отчётность, которая решается цепочкой задач. Сначала фиксируем цель: что именно нужно отслеживать и зачем. Всё остальное — вторично. Кроме того, не нужно перегружать дашборд лишней информацией. Определяем четко смысл. Что связано с графиком может отдельно выноситься ссылкой.

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

В этом посте я собрал то, с чем сталкивался, надеюсь я не один такой 😏

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

Ну а чтобы закрывать потребности бизнеса в специфичных срезах, обычно создается бот с выгрузкой Excel (в MatterMost, Telegram). Про это думаю написать дальше

Ставьте 🐳, если пост был полезен, и делитесь своим опытом в комментариях.

@zasql_python

Дорогие подписчики, хочу спросить у вас пару вещей ✨

❓ Что бы вам хотелось видеть в канале? Это могут быть софты, харды, прикладные разборы или даже что-то не совсем про аналитику — пишите, что было бы интересно читать.

😮 Чего вы ждёте от канала? Может быть, приходите за новыми знаниями, а может просто отвлечься и отдохнуть. Что для вас этот канал?

🤣 Любые мысли, идеи, пожелания — тоже сюда.

Пример болей:

— Я аналитик, но не знаю, куда двигаться дальше: развиваться в продукт, в Data Science, в менеджмент или экспертизу?
— Я упёрся в потолок: уже знаю инструменты, но дальше только таски по расчётам, и непонятно, как расти.
— Я только вкатываюсь и не понимаю, что учить в первую очередь — SQL, Python или строить метрики? Что бы вы сами посоветовали новичкам?
— Или, может быть, вам хочется прочитать про что-то конкретное: A/B тесты, карьерные треки, устройство работы аналитиков в компаниях?
— Кажется, что другие аналитики умнее, а я застрял на месте и двигаюсь слишком медленно.

Или по контенту:

— Хочется больше практики, ноутбучков, ресерчей видеть.
— Можно без лонгридов, хочу меньший объем постов.
— Давай сделаем обзор рынка труда, твое видение
— Сделай фокус на собесах, как готовился и так далее...

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

⌨️ В это вы мне можете помочь, написав комментарии!

Хочу сделать контент более полезным и живым, поэтому любая обратная связь очень поможет 🙌

Забустить канал ⬆️

@zasql_python

Как я сходил вчера на конференцию для аналитиков от Яндекса

(это не реклама, я сходил в оффлайне)

🙊 Самое главное, что нравится в этом — это нетворкинг с ребятами из разных компаний и разных сфер (аналитика, DS, DE). Можно поговорить про жизнь, карьеру и отстраненные темы.

Я периодически посматривал на бейджи, которые нам выдавали при регистрации. Было прям очень много компаний (в том числе WB, Яндекс, Авито, Т-Банк, VK, Сбер, Ozon и др.).

👀 Что касается докладов (я ходил по треку Data to insights)

💜 Про замеры качества Алисы доклад, в котором говорится, про то, что они перешли от разметки при помощи обученных асессоров к гибридной разметке (LLM + асессор, что обеспечивает стабильное качество разметки) + научились оценивать диалог с точки зрения пользовательской задачи.

🗺 Про то, как Карты перешли к единой метрике для оценки качества и эффективности. Про различные проблемы интерпретации разных метрик топам, про онлайн и оффлайн метрики, самое интересное, как вывели метрику (на основе произведения условных вероятностей), по которой можно быстро принимать решения.

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

Как понятно из докладов, самая главная боль — это метрики качества подобных продуктов, так как просто нельзя оценить

👍 На воркшоп я не успел сходить, но попросил скинуть мне ноутбучек (там про создание агента с RAG и MCP.

🍴 Затем было афтерпати, где я пообщался с интересными ребятами, поел, да и поехал я домой.

Ну и выдали мерч, куда же без него

Трансляции сохранились, кому интересно, можете глянуть

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

Понравился пост? Ставь 🐳, пиши комментарии, а я выложу, что за мерч подарили 🥳

Перфекционизм убивает скорость

🥰 В аналитике (да и не только в ней на самом деле) легко попасть в ловушку: хочется, чтобы запрос выглядел идеально, дашборд был вылизанным, а исследование должно быть нереально красивым. Но проблема в том, что бизнесу чаще всего нужно не идеально, а своевременно. Заказчики могут приходить с конкретной болью, которую хочется решить прямо сейчас. Хороший сторителлинг может быть лучше нескольких часов, потраченных на наведение красоты.

⌚️ Ты можешь неделями оттачивать расчёт, делать супер-красивые графики, перепроверять каждый шаг. А в это время продукт ждёт ответ, чтобы принять решение и запустить новую фичу (здесь еще можно обратиться к моему посту про управление ожиданиями). В итоге идеальная работа теряет ценность, потому что пришла слишком поздно. А еще хуже всего, когда нужно изменить подходы, так как заказчикам хочется видеть картину под другим углом)

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

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

😮 Хорошая стратегия — работать итерациями. Сначала собрать черновой результат, отдать на проверку, показать направлению и собрать обратную связь. Про то как ее запрашивать напишу отдельный пост, если соберется 100 реакций. Пусть он будет грубым, но уже полезным. После можно улучшать, дорабатывать, углубляться. Так и команда в курсе, и продукт двигается вперед, и ты не проваливаешься в бесконечное наведение красоты того, что потенциально с вероятностью 90% может корректироваться.

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

А что вы думаете по этому поводу?

🐳 — Делаем быстро, держим в курсе всех.
🥰 — Доводим до красоты и показываем результаты.

Пишите в комментариях свое мнение, ставьте реакции, если пост зашел!

🔛 Не бойся задавать вопросы

База, которую нужно помнить всегда.

Работаешь над новым проектом и не знаешь, куда идти — задай вопрос.
Не знаешь в какую БД нужно сходить за данным, так как только пришел — задай вопрос.
Хочешь узнать новое у коллег — задай вопрос.
Прослушал суть задачи, но хочешь понять, как ее делать — задай вопрос.
Сидишь на встрече с бизнесом и не понял зачем мы реализуем определенный проект — задай вопрос.

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

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

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

📕 Но если документации нет (а такое тоже случается), стоит самому фиксировать ответы коллег. Это поможет не возвращаться к одним и тем же вопросам по несколько раз. Записывай примеры запросов, названия сущностей и строй для себя определенный алгоритм:

1. Если нужно сделать задачу А — идём в систему Х (уже спросили у коллег, зафиксировали)
2. Проверяем данные через сервис Y,
3. На выходе ожидаем такой-то результат.

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

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

Любой адекватный человек не отреагирует негативно на твой вопрос, поэтому не стоит бояться того, что о тебе могут подумать как-то не так.

Тебе платят за то, чтобы ты делал работу эффективно — и вопросы тут твой инструмент 🤑

Иногда один правильно заданный вопрос экономит часы или даже дни работы ☕️

Ставьте 🐳, если пост был полезен, делитесь своими кейсами, а в следующих постах я напишу про мое обучение в магистратуре ✨

🐸 @zasql_python

это единственная правильная стратегия 😳

@ds_memes

💻 Написал статью про Наивный байесовский классификатор.

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

1. Ссылка на статью.
2. Датасет, с которым работал.
3. Код в Google Colab.

Первый раз писал тут, делюсь болью:

1. Столкнулся с тем, что при написании текста, страничка залагала, а при обновлении не сохранился кеш + нет автосохранения. После каждого написания текста советую нажимать "сохранить".
2. Нет конвертации в LaTeX. Поэтому пришлось писать формулы, конвертировать их в .svg, заливать в GitHub и по ссылке прикреплять в текст, вот такой замечательный пайплайн.
3. Периодически картинки не отображаются (хотя ведет на доступные ссылки) в моем GitHub.

Всем приятного чтива, а я пошел писать следующий пост!

😌😌😌🐸
😌😌😌😌
😌☺😌😌

⬆ Это я жду ваших комментов и реакций! Ставьте 🐳, делитесь и сохраняйте к себе!

Следующие посты будем разбирать математику, которая есть в A/B тестах или в ML. На примете разбор логистической регрессии.

@zasql_python

🐸 Python для аналитика

90% задач аналитик решает в SQL. Но остаются те самые 10%, где без Python никак 👩‍💻

Я собрал Google Colab, где в одном месте покрыта большая часть методов (практические все), которые реально нужны аналитику: от базовых конструкций (строки, списки, словари) до pandas/numpy, работы с API, визуализации, Spark и Airflow и др.

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

👉 Colab дублирую еще тут

Ставьте 🐳, если хотите поскорее получить такую базу знаний. И пишите, что ещё добавить в шпаргалку!

🌀 Умение просто объяснять сложное

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

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

🍪🍪 У всего есть своя аудитория.
Я знаю, что в канале собрались ребята очень разного уровня: кто-то уже работает в индустрии и глубоко копает в ресёрчи или A/B-тесты, кто-то только начинает свой путь в аналитике, а кто-то вообще пока просто наблюдает со стороны. И это классно, так как разные перспективы помогают смотреть на одни и те же вещи под разными углами. Поэтому я стараюсь чередовать форматы: где-то глубже, где-то проще, чтобы каждому было комфортно и интересно.

👀 И да, интересное наблюдение. Иногда вижу подпись: «Простыми словами о сложном».

Сразу вопрос: а что это вообще значит? Упростить НЕ РАВНО донести мысль 🧠

На самом деле этот навык про понимание своей аудитории и способности говорить на её языке.

🥳 Умение аналитика не только в том, чтобы посчитать метрику или построить модель. Главное, что ожидается, это упаковать результат так, чтобы он легко ложился в голову любого человека. Где-то объяснить на пальцах, где-то достать формулы, но всегда через призму главного вопроса: зачем это нужно?

Работаем переводчиками, а чо, плотити еще сверху, так как мы считаем эскуельки и рисуем графички 💰

😮 Очень сильно помогает совет: объясняй так, будто разговариваешь с человеком, который вообще не разбирается в домене, сложных методах и так далее (например, человек из бизнеса, который отвечает за коммерческий департамент). Представь, что перед тобой первый попавшийся прохожий. Если он поймёт, значит, ты действительно донёс мысль. В его голове могут появляться самые разные вопросы, и твоя задача будет заключаться в том, чтобы выстроить понятное повествование. Иначе весь смысл разговора теряется.

А вы что думаете? Ставьте 🐳, пишите комментарии! А я пойду я готовить следующий пост 🤟

А вы знали, что аналитики пишут на R?

Я то знаю...

Хочу порекомендовать вам канал @stats_for_science

Автор канала: Лена, продуктовый аналитик Литрес 📚, ранее работала в X5 Tech 💚 , ранее занималась наукой. В своих постах она сравнивает научные и бизнесовые подходы.

😎 Выделил для себя несколько, которые мне откликаются

🟢 Про поправки на множественное тестирование. Лена написала большой лонгрид на эту тему. Актуально при проверке нескольких гипотез (например, когда принимаем решение по нескольким целевым метрикам / по > 2 группам).

🟢 Что самое сложное в работе продуктовым аналитиком. Здесь говорится о работе с метриками и общие размышления автора + в комментах написал свое мнение по поводу этого поста.

🟢 Виды пределов погрешностей. В мире мы работаем со случайными величинами, зачастую мы работаем с интервальными оценками. В этом посте как раз про это. От боксплотов до доверительных интервалов, годное чтиво!

+ Я очень люблю мемы про статистику (скажите мне, пожалуйста, что это не профдеформация).

🔵 про p-value в ящике
🔵 слишком большие запросы

Да начнется холивар по поводу R, не Python единым! 🖥🐍

P.S: Идеи, которые предлагаются в канале можно переложить на Python, так как главное — это понимать идею, а языки между собой очень сильно похожи в плане синтаксиса. Питонистам актуально!

Подписывайтесь на @stats_for_science, чтобы разбираться в статистике еще лучше!

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

DROP TABLE IF EXISTS zasql_python_table;

create table zasql_python_table (
value1 CHAR(5),
value2 VARCHAR(5)
);

INSERT INTO zasql_python_table VALUES ('abcd', 'abcd');

SELECT CONCAT(value1, value2) as result_1_2, CONCAT(value2, value1) as result_2_1
from zasql_python_table;

🗣 Результат будет следующий 🙃

| result_1_2 | result_2_1 |
|-------------|-----------|
| abcd abcd   | abcdabcd  |

Видите пробел между abcd и abcd? Это как раз CHAR, который дополнил строку до фиксированной длины.

Ну или после этого сообщения начнуть кошмарить на собесах по SQL... 👩‍💻

Вроде бы БАЗА, о которой говорят в самом начале любого курса, но внимания на этом акцентируется мало (мной или курсом). Вот, у вас есть типы данных, один делает то, другой это.

🐸 Если очень грубо:

🥳 CHAR(n) используется для хранения строк фиксированной длины.
Если строка короче, чем n, она автоматически дополняется пробелами до нужной длины. При выводе эти пробелы обычно сохраняются (зависит от СУБД). Подходит, когда все значения примерно одинаковой длины (например, коды, индексы).

🥳 VARCHAR(n) хранит строки переменной длины.
Если строка короче n, то пустоты не добавляются, сохраняются только фактические символы. Если строка длиннее n, она будет обрезана до заданного размера. Подходит, когда длина строк сильно варьируется.

Например, в одной статье говорится следующее:

For instance, CHAR often outperforms VARCHAR in scenarios with consistently sized data due to its fixed length, resulting in faster index lookups—up to 20% quicker on average. Conversely, VARCHAR excels in space efficiency for variable-length data, making it an ideal choice for dynamic datasets. The decision between CHAR vs VARCHAR is not just about storage but also about optimizing your database’s speed and efficiency.

⬆️ CHAR часто превосходит VARCHAR в сценариях с данными одинакового размера благодаря фиксированной длине, что приводит к ускорению поиска по индексу — в среднем на 20 %.

Или в другой:

The amount of work the database engine has to perform to store and retrieve VARCHAR columns is more than it takes for a CHAR column. Every time a VARCHAR column is retrieved, the Database engine has to use the length information stored with the data to retrieve a VARCHAR column value. Using this length information takes extra CPU cycles. Whereas a CHAR column and its fixed length allow SQL Server to more easily chunk through CHAR column based on their fixed-length column definitions.

⬆️ Для хранения и извлечения VARCHAR столбцов ядру базы данных требуется больше ресурсов, чем для CHAR столбцов. При каждом извлечении VARCHAR столбца ядру базы данных приходится использовать информацию о длине, хранящуюся вместе с данными, чтобы извлечь значение столбца VARCHAR. Использование этой информации о длине требует дополнительных вычислительных ресурсов.

Авторы предлагают использовать CHAR для фиксированной длины и в этом случае скорость будет выше, но я опять скажу, что пока что ни разу не видел такие витрины, где бы использовался этот тип данных. Может вы сможете привести РЕАЛЬНЫЙ кейс, где бы это использовали.

Понравился пост? Ставьте 🐳, если понравился пост, пишите комментарии! Может вы использовали CHAR и это помогло? Нужны кейсы!

@zasql_python

Работаете с данными, но чувствуете, что не хватает структуры?

Интересное наблюдение: профессия аналитика в последние годы показывает стабильно высокий спрос — по данным Habr карьеры, доля вакансий аналитика в прошлом годы выросла до 12%. При этом в профессию активно переходят люди из смежных областей — кто-то из маркетинга, кто-то из финансов, кто-то вообще с нуля. И у большинства одна и та же проблема.

Навыки есть — SQL подучили, Python освоили, дашборды строят. Но когда дело доходит до реальных задач, понимаешь: не хватает структуры. Данные собрать можете, а вот превратить их в понятные бизнесу решения — сложно. Защитить гипотезу перед руководством — еще сложнее. И в итоге чувствуешь себя «техническим исполнителем», а не тем, кто влияет на решения компании.

Знакомо?

Недавно изучал программу "Аналитик PRO" от Changellenge >> Education — и вот что зацепило: ребята строят обучение не вокруг инструментов (хотя и их дают полностью), а вокруг того, как аналитики реально работают в топовых компаниях. Вы учитесь не просто запросы писать, а решать бизнес-задачи от брифа до защиты решения — как это происходит в Яндексе, VK, Booking или консалтинге.
Давайте разберу подробнее, что там внутри и почему это может закрыть те самые пробелы.

Что делает этот курс особенным?

🎯 Школа проектного обучения
Здесь вы не будете решать абстрактные задачки из учебников. Вы погрузитесь в реальные кейсы от топовых российских компаний — работаете с настоящими данными от партнеров, защищаете решения перед экспертами и прокачиваете soft-analytics.

15 кейсов + 6 консалтинговых проектов — это не "учебная песочница", а задачи, которые решают аналитики в крупных компаниях. По сути, вы получаете опыт работы еще до того, как устроитесь на новую позицию.

📚 Программа собрана под требования работодателей
Никакой воды и теории ради теории. Программа построена на базе экспертизы Changellenge >> и того, что реально требуют на собеседованиях

Это не просто набор инструментов — вас учат "языку бизнеса": как превращать данные в управленческие решения, защищать свои гипотезы и доносить идеи до топ-менеджмента.

🤝 Коммьюнити и нетворк
После выпуска вы становитесь частью закрытого клуба всех выпускников проекта с 2015 года. Это топ-менеджеры ведущих компаний, предприниматели и крутые специалисты.

Changellenge >> Education уже видели сотни трудоустройств через друзей, десятки совместных стартапов и даже свадьбы 😄 83% выпускников находят работу в течение 3 месяцев после обучения — и это не просто статистика, а результат сильного нетворка и реальных рекомендаций.

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

От меня держите промокод 25PYTHON, он дает скидку 25 000р на новый поток, который стартует 8 октября. Регайтесь на программу АПРО, прокачивайте ваши навыки и карьерные возможности.

Где я в итоге учусь в магистратуре и как мне?

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

💻 Поступил я в итоге на ML-инженера в МИФИ. На выбор у меня было поступление в разные магистратуры, но здесь я напишу, что вообще происходит в моей. По программе все зашло на момент сдачи вступительных испытаний.

💻 После работы или на выходных я выделяю себе время на просмотр лекций, семинаров (благо есть записи). Трачу час-два каждый день, чтобы посмотреть материалы, решить дз, закрыть проекты, чтобы потом не быть с горящей жопой, закрывая предметы. Первый семестр достаточно простой, дают очень много всего. Если смотрели вот этот пост, это просто 1/100 того, что было в материалах, а в дальнейшем я эту историю раскрутил.

😢 К сожалению, нельзя закрыть предметы, если ты применяешь методы на работе, хотя я слышал, что в каких-то местах можно. Приведу пример: я пишу много SQL-скриптов с различной сложной логикой, но при этом должен закрывать предмет, где учат делать SELECT, вставки в таблицы и их создание. Как мне кажется, предмет можно закрыть, но тут кому виднее. Многие могут написать, что-то из разряда: "так если так легко, сдай сам", будете правы.

Задания, в том числе проекты реализованы на платформе, есть мягкие и жесткие дедлайны по сдаче дз / проектов. Необязательное посещение лекций и семинаров + преподаватели открыты к обратной связи и вопросам. Например, для задачи по наивному Байесу я с преподавателем очень долго дискутировал по применению метода в определенной задаче, про это я кстати планирую написать, мне показалось, что тема весьма интересна 🍪🍪

👦 На лендинге магистратуры видел, что магистратура для начинающих специалистов (я, кек). Но мне показалось, что очень много материалов и человеку без опыта будет сложно (несмотря на то, что курсы сделаны последовательно). От 25 часов в неделю, учеба в удобное время, как указывается на сайте. Но это еще норм, так как в ВШЭ на одну из программ, куда я поступал было от 40 часов в неделю (рабочая неделя) + говорили, что понадобится еще больше времени на обучение (ШАД?) 💥

Местами я наблюдал, что материал подан без конкретной структуры, несмотря на явное разделение по модулям. То есть могла быть одна тема, которая ссылалась на тему, которую не проходили по курсу. Возможно, подразумевается, что студенты будут сами искать то, что им нужно в интернете или GPT, а затем приступать к изучению. Если так и задумывалось, то, наверное, супер гуд. Хотя я склоняюсь к тому, что нет, так как в процессе обучения курс дорабатывается. Я купил себе подписку в бета-тестеры магистратуры 👀

Из интересного, что есть — это теория вероятностей + ожидается статистика с A/B тестированием в этом семестре. По Python много всего показывают: декораторы, ООП (великий и ужасный, который обходят стороной аналитики, хотя знаю, что некоторые используют, в том числе для методов 🆎, если хотите, чтобы я подробней про это рассказал, ставьте 🐳, для ML инженера очень часто видел использование классов и это БАЗА). Но указан именно базовый Python без библиотек для анализа данных, возможно я это увижу в следующих семестрах.

Имхо, пока норм, есть косяки, но что-то новое местами для себя подчерпываю. Например, итоговый проект по Python нужно было реализовать с помощью poetry, makefile и различных зависимостей между файлами. Что-то новое для себя подчерпываю и систематизирую.

Кстати, интересный факт по поступлению в ИТМО (так как меня многие спрашивали, почему я не пошел туда): когда объявляли результаты конкурса в AI Talent Hub, удивился, что не нашел себя в списке победителей по конкурсу портфолио. Оказывается, что подал документы не на ту программу и там выиграл, но формат очный 😂, а в AITH дистанционный.

Как вам пост? Ставьте 🐳, подписывайтесь на канал, пишите комментарии!

@zasql_python

🐸 Вы когда-нибудь думали, что знаете всё, а потом жизнь показала обратное?

Эффект Даннинга-Крюгера

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

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

👀 У меня было такое, когда я рассказывал одному из своих знакомых (3 года назад), что я все знаю в аналитике, нахожусь в своем прайме и вообще я очень крутой специалист. На тот момент я участвовал в хакатоне без релевантного опыта аналитики. Но был убежден, что, покрутив таблички в pandas, почитав документацию, я стал боссом всей аналитики. Нанимайте меня на пост директора по аналитике, пожалуйста, ведь я крутой 🥳

В эксперименте Даннинга и Крюгера студентов просили пройти тест по грамматике, логике и чувству юмора, а потом — оценить себя. Результат показал: слабые участники переоценивали себя, сильные — недооценивали.

👉 Вот здесь можно почитать более подробно

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

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

Что можно с этим сделать?

1. Получать обратную связь от тех, кому ты доверяешь в знании предметной области. Это может быть знакомый разработчик, аналитик, продакт. Важно искать потенциальные точки роста в этом.
2. Почаще рефлексировать. Можно вести конспекты по предмету, в котором ты хочешь разбираться, стараться самостоятельно решать определенные задачи и челенджить себя.
3. Ставить реалистичные цели. Решение задач позволяет повысить самооценку и выбрать из ямы страданий.

Вот тут кстати интересная статья по разоблачению этого эффекта, интересно было почитать комменты

А что вы думаете по этому поводу? Ставьте 🐳, пишите комментарии!

@zasql_python