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

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

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

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

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

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

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

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

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

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

🟢 Построил дашборд для команды продаж, который улучшил метрику 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 дублирую еще тут

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