Главные курсы, с которых стоит начать изучение аналитики — часть 2

Получается после первого поста уже и не один главный...

В прошлый раз говорили про базу работы с данными - SQL.
Сегодня поговорим про автоматизацию, обработку и визуализацию (Python и BI).

🐍 Python — ваш инструмент автоматизации

Если SQL помогает достать данные, то Python нужен, чтобы по сто раз не дергать одни и те же запросы, а легко их автоматизировать/обработать и тд. Это супер универсальный инструмент, на котором делают все — от A/B-тестов, дашбордов, ML-моделей и ETL-скриптов.

*️⃣Рекомендую начать с курса “Поколение Python”

Если коротко - все объясняется супер понятно и есть много практики.

Когда базу освоите - я бы посоветовал отдельно изучить библиотеку для анализа данных - а именно с pandas. Я начинал с курса, который тогда назывался демо-курс «Аналитик данных» от Карпова. Сейчас его уже нет на платформе (или я не нашел), но материалы сохранились в виде плейлиста на ютубе.

*️⃣Демо-курс «Аналитик данных»

Там базово вся суть работы с pandas — группировки, фильтрации, merge’ы, визуализация (+ numpy и seaborn).

📊 Визуализация и BI

Я сам учился этому уже на работе, но для старта может помочь вот этот супер короткий плейлист на ютубе:

*️⃣Power BI для начинающих

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

Но сейчас в бигтехах все чаще работают с Яндексовским DataLens или опенсорсными Superset или Metabase - но логика у всех BI-инструментов примерно одна и та же, так что, освоив Power BI, вы без проблем пересядете на любой другой.

P.S. Еще советовали по Power BI данный курс - стоит в пределах 1.5к, что в целом не так дорого, но решать вам.

💡 Итог по этим курсам:

1️⃣ Освойте Python (база + pandas).
2️⃣ Разберитесь с BI-инструментом.
3️⃣ Соедините это с SQL из первой части — и вы уже готовы идти на собесы...

А вы с чего начинали учить Python или BI? 👇

@data_driven_bogdan

Как оформить опыт в резюме (Ч. 1)

Планирую серию постов про оформление резюме — начнем с одного из самых важных блоков: опыт работы.

*️⃣Главная ошибка большинства - просто перечислить обязанности:

Составлял отчеты в Power BI / писал самописные DQ-проверки / подготавливал adhoc выгрузки для бизнеса.

Так не делаем — это не продает тебя как специалиста.

✅ Как нужно делать

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

Формула простая:
X — что сделал, Y — каким способом, Z — какой результат.

➖Плохо

*️⃣Собирал витрины для adhoc выгрузок
*️⃣Составлял SQL-запросы для дэша
*️⃣Настраивал инкрементальную загрузку данных в витрину

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

➕Хорошо

*️⃣Оптимизировал SQL-скрипты при подготовке витрин(X), внедрив инкрементальную загрузку (Y) — ускорил сборку отчетов на Power BI на 30%(Z1) и снизил нагрузку на кластер на 50% (Z2).
*️⃣ Автоматизировал построение витрин для дэшей (X) через DAG в Airflow (Y), сократив время подготовки отчётов на 40% (Z).

📌 Совет:
Если не хватает количественной метрики (в процентах, минутах, часах) — можно писать через качественный результат:

...что позволило бизнесу отслеживать продажи в реальном времени / снизить количество ошибок / сократить ручной труд.

Но все-таки лучше подумать над количественной метрикой — с примерами выше можно использовать Time to Value, %, FTE соответственно.

🧩 Почему XYZ

Есть и другой формат — STAR (Situation – Task – Action – Result).
Он тоже хороший, но кмк удобнее для ответов на собеседовании, когда нужно развернуто рассказать про опыт или конкретный кейс.

Для резюме же важно коротко и четко показать ценность твоих действий чтобы зацепить hr.

❓ Что делать если хз что указывать в опыте

Всего пару шагов:

1. Открой несколько аналогичных вакансий на hh;
2. Сними оттуда формулировки требований
3. Адаптируй требования и достижения под себя через XYZ.

🛠 Стек

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

➕Пример:

Стек: Airflow, Kafka, Python (pandas, polars, requests, psycopg2), SQL, Docker, dbt, Greenplum, Debezium, Data Vault, Clickhouse, S3, Jira, Confluence, Trino

📆 По структуре опыта

*️⃣Последнее место работы — должно быть хорошо расписанным (+- 7 буллетпоинтов по XYZ) и минимум 1/1.5 года.
*️⃣Старые места можно сокращать до 5 буллетов

Базовый минимум🤩 — 1 год в каждой компании. Если меньше — это флажок для HR чтобы скипнуть и заклеймить тебя в локальной базе "скакуном". Такие моменты не допускаем.

💰 Про зарплату

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

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

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


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

Можем попробовать разобрать чье-то резюме отдельным постом
+ у меня можно заказать составление/разбор резюме под DA/DE

@data_driven_bogdan

🧠 MPP vs SMP — в чём разница и почему это важно знать❓ (ч. 1)

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

⚙️ Что такое SMP❓

SMP (Symmetric MultiProcessing) — это архитектура, где все процессоры используют одну общую память. Т.е у нас есть несколько CPU, но они работают как одна команда, обращаясь к единой памяти и деля между собой ресурсы. Такие системы чаще всего управляются одной OC, которая сама распределяет задачи между процессорами.

Примеры SMP БД:
*️⃣PostgreSQL,
*️⃣Oracle Database,
*️⃣MS SQL Server и др.

➕ Какие плюсы у SMP:
*️⃣Простота — одна ОС, общая память, легко развернуть.
*️⃣Быстрый обмен между процессами.
*️⃣Дешевле и легче в обслуживании.

➖ Какие минусы у SMP:
*️⃣Плохо масштабируется — все процессоры делят одну память.
*️⃣Подходит только для “вертикального” роста (добавить ядра/ RAM/ расширить диск).

🧩 Пример SMP: PostgreSQL

PostgreSQL — классическая SMP-система.
Вся работа происходит на одном сервере, где несколько CPU используют общую память и диск.

1. Архитектура:
*️⃣несколько ядер процессора;
*️⃣общая оперативная память;
*️⃣единая файловая система;
*️⃣каждый клиент — отдельный backend-процесс.

2. Как это работает:
Когда клиент отправляет SELECT запрос, создаётся процесс, который читает данные из кеша или с диска. Все процессы работают параллельно, но используют одни и те же ресурсы — CPU, RAM и I/O.

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

@data_driven_bogdan

🧠 MPP vs SMP — в чём разница и почему это важно знать❓ (ч. 2)

⚙️ Что такое MPP❓

MPP (Massively Parallel Processing) — это архитектура, где каждый узел системы имеет свою память, процессор и кусок данных. То есть это уже не один сервер, а кластер из нескольких машин, которые работают как единая система.

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

Примеры MPP БД:
*️⃣Greenplum,
*️⃣Snowflake,
*️⃣Teradata,
*️⃣ClickHouse (в кластерной конфигурации) и др.

➕ Плюсы MPP:
*️⃣Отлично масштабируется — добавляешь узлы → растёт производительность.
*️⃣Каждый узел работает независимо → меньше конкуренции за ресурсы.
*️⃣Идеально подходит для аналитических задач и больших данных.

➖ Минусы MPP:
*️⃣Сложнее администрировать и проектировать.
*️⃣Обмен между узлами идёт через сеть — возможны потери по скорости.
*️⃣Важно грамотно выбрать ключ распределения (distribution key), иначе система начнёт перетаскивать данные между сегментами.

🧩 Пример MPP: Greenplum
Greenplum построен на базе PostgreSQL, но работает по другой логике — распределённо.

1. Архитектура:
*️⃣Master node — принимает SQL-запрос и строит план выполнения;
*️⃣Segment nodes — независимые узлы (по сути, отдельные PostgreSQL-инстансы) со своей памятью и данными;
*️⃣Interconnect network — сеть, через которую сегменты обмениваются результатами.

2. Как это работает:
1. Ты пишешь SELECT SUM(revenue) FROM table.
2. Master разбивает запрос и рассылает его сегментам (согласно заданной в запросе логики дистрибуцирования).
3. Каждый сегмент считает сумму по своей части таблицы.
4. Master собирает результаты и возвращает финальный итог тебе.

3. Ограничения:
*️⃣Ошибочный выбор ключа распределения может привести к data shuffle — передаче данных между сегментами, что снижает производительность.
*️⃣Требует понимания внутренней логики распределённых систем.

💡 Почему это важно знать аналитикам

Разница между SMP и MPP — это не просто “архитектура”, а объяснение того, почему один запрос летает, а другой падает. Понимание архитектуры помогает писать эффективные SQL-запросы, оптимально строить витрины и разговаривать с инженерами на одном языке.

На что влияет:
*️⃣Скорость. В SMP все процессы делят одну память → конкуренция за ресурсы. В MPP — нагрузка распределяется по узлам, и запросы считаются параллельно.
*️⃣Проектирование витрин. В MPP важно понимать, как распределены данные, чтобы не было data shuffle и потерь по производительности.
*️⃣Масштабирование. SMP растёт только “вверх” — добавляй ядра и память. MPP — “вширь”, добавляй узлы и не бойся объёма данных.

И чем раньше ты понимаешь, где и как исполняется твой SQL запрос, тем быстрее начнешь управлять скоростью -> научишься оптимизировать его, а не просто “писать SELECT”ы.

Доп. материалы к контенту:
1. Статья какие еще бывают архитектуры и зачем они нужны
2. Разбор MPP архитектуры Greenplum
3. Хороший бесплатный курс от Яндекса по Greenplum

Пишите в комментариях вопросы/замечания👇

@data_driven_bogdan

Greenplum: от архитектуры к правильному проектированию таблиц (ч. 1)

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

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

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

*️⃣Дистрибуции — распределения данных по сегментам
*️⃣Партиционирование — деления данных внутри сегмента,
*️⃣Оптимальных типов таблицы и параметров хранения/сжатия.

⚙️ Дистрибуция

Дистрибуция — это метод, по которому данные распределяются между сегментами в GP.
Цель — чтобы объём данных на каждом сегменте был примерно одинаковым.

Если распределение неравномерное (data skew), один сегмент будет обрабатывать больше строк и замедлит выполнение всего запроса.

Основные типы:

HASH (DISTRIBUTED BY ()) — равномерно распределяет данные по ключу (например, client_id) или связке ключей. Это наиболее предпочтительный и при этом автоматический способ дистрибуции: если явно не задать ключ распределения при создании таблицы, Greenplum по умолчанию использует первый столбец таблицы в качестве ключа дистрибуции.

Хэш-дистрибуция позволяет:

*️⃣получить максимальную выгоду при JOIN таблиц без избыточного хранения данных;
*️⃣обеспечить равномерное распределение строк между сегментами;
*️⃣минимизировать перераспределение при запросах.

Используется чаще всего для таблиц фактов и больших объёмов данных.

RANDOMLY (DISTRIBUTED RANDOMLY) — тип распределения, при котором Greenplum сам распределяет строки по сегментам.
Подходит для небольших таблиц или временных данных, когда ключ дистрибуции неочевиден.

Особенности:
*️⃣равномерное распределение по сегментам;
*️⃣теряется выгода при соединениях (JOIN) — система выполняет Redistribute/Broadcast Motion;
*️⃣исключает перекосы данных.

REPLICATED (DISTRIBUTED REPLICATED) — копия таблицы на каждом сегменте.
Отлично подходит для маленьких справочников, но дублирует объём данных.

Особенности:

*️⃣JOIN выполняются максимально быстро, без движения строк между сегментами;
*️⃣удобно для маленьких справочников (dimensions).
*️⃣ главный недостаток - дублирование данных на всех сегментах

💡 Рекомендации по дистрибуции:

1. Явно задавай DISTRIBUTED BY — даже для временных таблиц.
Иначе по умолчанию система возьмёт первый столбец, который вероятно приведет к skew

2. Если нет хорошего ключа — выбирай RANDOMLY.
Также выбирай рандом для финальной таблицы, которая не будет участвовать в join в дальнейшем

3. Не используй для дистрибуции поле часто встречающееся в WHERE.
Иначе при запросах данные будут перераспределяться по сегментам → падение производительности.

4. Избегай типов date и datetime + выбирай integer вместо string для дистрибуции.
Для первых хэш вычисляется долго + для str аналогично

5. Лучший ключ дистрибуции — тот, что участвует в JOIN ON.
Это минимизирует motion и делает запросы стабильнее.

@data_driven_bogdan

Greenplum: от архитектуры к правильному проектированию таблиц (ч. 2)

🧱 Партиционирование

Партиционирование — это разделение таблицы на логические части (партиции) внутри каждого сегмента по определённому признаку (чаще всего — по дате). Такое деление позволяет ускорить запросы, снизить нагрузку на диск и упростить администрирование данных.

Зачем нужно партиционирование

*️⃣Ускоряет аналитику — при фильтрации по WHERE Greenplum читает только нужные партиции, а не всю таблицу.
*️⃣Снижает нагрузку на сегменты — не происходит полного сканирования таблицы, читаются только нужные диапазоны.
*️⃣Упрощает сопровождение — можно быстро удалить или архивировать старые данные, не трогая актуальные.
*️⃣Изолирует данные по периодам — удобно для построения витрин с логикой «по месяцам» или «по кварталам».

Принцип и пример:

При указании фильтра WHERE Greenplum читает только нужные партиции, а не всю таблицу.

SELECT *
FROM dm.xyz
WHERE datetime BETWEEN '2025-04-01' AND '2025-06-30';

Если таблица партиционирована по datetime, будет прочитан только 2 квартал, а не весь объём.
Это значительно снижает время выполнения запроса, особенно при миллионах строк данных.

🧩 Как пользоваться партициями:

Узнать ключи партиционирования:

SELECT *
FROM pg_catalog.pg_partition_columns
WHERE schemaname = 'dm'
AND tablename = 'xyz';

Проверить, что запрос использует нужную партицию - через EXPLAIN перед запросом:

EXPLAIN
SELECT *
FROM dm.xyz
WHERE datetime BETWEEN '2025-04-01' AND '2025-06-30';

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

Добавить или удалить партицию:

ALTER TABLE dm.xyz ADD PARTITION p202507 START ('2025-07-01') END ('2025-08-01');
ALTER TABLE dm.xyz DROP PARTITION p202301;

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

💡 Советы по проектированию партиций:

1. Партиционируй таблицы фактов — это основной кандидат для деления по дате.

2. Не делай слишком мелкие партиции (например, по дням) — это создаёт избыточные метаданные и замедляет DDL-операции.

3. Оптимальный уровень — по месяцам или кварталам.

4. Используй фильтры в WHERE по ключу партиционирования — иначе Greenplum не сможет исключить ненужные партиции.

5. Для небольших справочников (dictionary tables) партиционирование избыточно — оно не ускорит запросы, но усложнит структуру.

@data_driven_bogdan

Greenplum: от архитектуры к правильному проектированию таблиц (ч. 3)

🧩 Типы таблиц в Greenplum

1. Heap (row storage)
Это классический тип таблиц, унаследованный от PostgreSQL.
Данные хранятся построчно — каждая запись (row) хранится целиком, что делает работу с отдельными строками быстрой, но аналитические запросы медленнее.

Используется для:

*️⃣небольших таблиц (до ~300 тыс. строк или до ~100 MB);
*️⃣таблиц, где часто происходят операции UPDATE, DELETE, INSERT;
*️⃣задач с OLTP-нагрузкой (операционные системы, логирование, промежуточные буферы).

2. Append-Optimized (AO)
AO — это оптимизированный под аналитику формат хранения, доступный только в Greenplum.
Такие таблицы предназначены для OLAP-нагрузки, где данные в основном читаются, а не обновляются.

AO-таблицы позволяют:
*️⃣экономить место за счёт сжатия (compresstype и compresslevel);
*️⃣ускорять аналитические запросы, т.к. считываются только нужные колонки (orientation = column);
*️⃣эффективно работать с батчевыми вставками (INSERT пакетами).

Пример создания оптимальной таблицы:

CREATE TABLE schema.table_name
WITH (
appendonly = true, -- таблица только для добавления (без UPDATE/DELETE)
orientation = column, -- колоночное хранение (эффективно для аналитики)
compresstype = zstd, -- алгоритм сжатия Zstandard
compresslevel = 4, -- уровень сжатия (оптимальный баланс скорость/размер)
blocksize = 32768 -- размер блока в байтах (кратно 8192)
)
DISTRIBUTED BY (client_id); -- ключ дистрибуции по клиенту

💡 Best Practices для таблиц в Greenplum

1. Сжимай данные.
Компрессия (zstd, compresslevel=4) сокращает занимаемое место в хранилище при минимальном влиянии на производительность.

2. Используй колоночное хранение для аналитики.
Greenplum — OLAP-система, и колоночные таблицы значительно ускоряют агрегации и фильтрацию.

3. Heap — только для частых обновлений.
Для оперативных таблиц с частыми UPDATE/DELETE используйте Heap. Для аналитических витрин — AO.

4. Не смешивай типы хранения в одной цепочке.
Факт-таблицы делай AO, справочники — Heap или AO column (если редко обновляются).

5. Обновляй статистику (ANALYZE) после загрузки данных.
Это поможет оптимизатору правильно оценивать стоимость запросов.

Итого

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

Пишите в комментариях вопросы/замечания/что понятно, а что нет👇

@data_driven_bogdan

Топ-10 SQL вопросов, которые точно спросят на собесе (уровень junior)

Без практики не обойтись, но теорию не забываем

1️⃣Порядок выполнения SQL-запроса

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT

💡 Поэтому WHERE не видит алиасы из SELECT.

2️⃣ WHERE vs HAVING

*️⃣WHERE — фильтрует строки до группировки
*️⃣HAVING — фильтрует после GROUP BY

Пример:


SELECT city, COUNT(*)
FROM users
WHERE age > 18
GROUP BY city
HAVING COUNT(*) > 10;

3️⃣ Виды JOIN-ов (логические)

JOIN — это оператор, который объединяет строки из двух таблиц по общему полю (ключу), чтобы получить связанные данные в одном наборе.

*️⃣INNER — только совпавшие
*️⃣LEFT — все из левой
*️⃣RIGHT — все из правой
*️⃣FULL — всё подряд

Таблицы склеиваются в "ширину"

4️⃣ UNION vs UNION ALL

UNION (/ALL) — это оператор, который склеивает таблицы вертикально, то есть добавляет строки из одной таблицы под строки другой. Главное — структура (кол-во и типы столбцов) должна совпадать.

UNION — объединяет вертикально и убирает дубли
UNION ALL — объединяет вертикально и оставляет все записи

💡 UNION ALL быстрее, UNION безопаснее, когда хочешь избавиться от повторов.

5️⃣ Как убрать дубликаты?

DISTINCT vs GROUP BY vs ROW_NUMBER() = 1

✅ DISTINCT — просто убрать дубли на уровне строк

SELECT DISTINCT user_id FROM orders;

✅ GROUP BY — группировать по колонке, где требуется оставить уникальные значения


SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;

✅ ROW_NUMBER() — когда дубли одинаковы не по всем полям и нужно выбрать одну по выбранному признаку

SELECT *
FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn
FROM orders
) t
WHERE rn = 1;

.
6️⃣ DELETE vs TRUNCATE vs DROP

DELETE - Удаляет строки (можно с условием where), можно откатить
TRUNCATE - Удаляет все строки (быстро, без условий)
DROP - Удаляет таблицу целиком

7️⃣ Подзапрос vs CTE

Подзапрос — быстро и локально, когда нужно одно промежуточное значение:

SELECT user_id
FROM orders
WHERE order_date = (
SELECT MAX(order_date)
FROM orders o2
WHERE o2.user_id = orders.user_id
);

💡Минус — код тяжело читать и отлаживать, особенно если вложено несколько уровней.

CTE (WITH) — удобно для пошаговых расчётов и чистого кода:

WITH last_orders AS (
SELECT user_id, MAX(order_date) AS last_dt
FROM orders
GROUP BY user_id
)
SELECT u.user_name, l.last_dt
FROM users u
JOIN last_orders l USING(user_id);

💡 CTE проще дебажить, можно переиспользовать, выглядит как «story» запроса.

8️⃣ Оконные функции
Позволяют считать агрегаты без потери строк 👇


SELECT
user_id,
SUM(amount) OVER (PARTITION BY user_id) AS total_spent,
COUNT(*) OVER () AS total_rows
FROM payments;

💡 GROUP BY схлопывает строки, а OVER() просто добавляет новые расчётные поля.
Например, можно посчитать долю:


SUM(amount) OVER (PARTITION BY category) / SUM(amount) OVER () AS share

9️⃣RANK vs DENSE_RANK vs ROW_NUMBER

Оконные функции, которые:

ROW_NUMBER() - Просто нумерует строки
RANK() - Пропускает номера при одинаковых значениях
DENSE_RANK() - Без пропусков, ранги идут подряд

🧩 Пример:
Зарплаты — [100, 90, 90, 80]

ROW_NUMBER - 1,2,3,4
RANK - 1,2,2,4
DENSE_RANK - 1,2,2,3

1️⃣0️⃣ Работа с NULL в SQL

NULL — это не значение, а отсутствие данных.
Он не равен ничему, в том числе другому NULL.

Фильтровать можно только так:

WHERE col IS NULL
WHERE col IS NOT NULL

а не = NULL или != NULL.

💡 Важно помнить:

*️⃣COUNT(col) игнорирует NULL,
*️⃣COUNT(*) — считает всё,

Также в арифметике 5 + NULL = NULL, в таком случае для подстановки значения используйте функцию COALESCE() для подставки 0 или 'tbd'.

Добавил бы что-то в этот список базированных вопросов? Пиши в комменты

@data_driven_bogdan

Как оформить резюме (уже не только опыт) (Ч.2)

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

1. Релевантность опыта

*️⃣Не отходя от кассы с опытом отмечу важный поинт - релевантность опыта. Оформляем резюме конкретно под вакансию: собесимся на продуктового аналитика — делаем отдельное резюме под ПА, с уклоном в опыт с A/B-тестами; на ДЕ — акцент на архитектуру и ETL, и так далее.

*️⃣Опыт работы также должен соответствовать вакансии (никаких практикантов, менеджеров по планированию и т.д.).

*️⃣Нерелевантный опыт либо удаляем, либо переигрываем под нужную нам вакансию.

2. Контакты

*️⃣Для РФ указываем Москву — повышаем шанс найти вакансию, т.к. больше предложений.
Возраст не указываем — чтобы не натолкнуться на эйджизм.
С зарплатой и должностью уже разобрались в прошлых постах.

3. Блок «О себе»

*️⃣Коротко о себе в рамках вакансии — крутой ДЕшник, работал в X сферах, потрогал Y стек ищу команду/компанию, где можно развиваться в Z.

Пример:

Data Engineer с опытом построения ETL-пайплайнов и моделирования DWH в ритейле и финтехе.
Работал с Airflow, Kafka, Greenplum, ClickHouse, dbt, Docker.
Ищу команду, где можно развивать архитектурные решения и оптимизацию потоков данных

*️⃣Не забываем в данный блок добавлять контакт для связи — Telegram / номер телефона, дабы повысить конверсию.

telegram: @...
phone: +79....

*️⃣Также на hh есть отдельный блок «Контакты – комментарии», куда можно тоже написать tg, но часто HR долбятся в глаза, поэтому дублируем в блоке «О себе» тоже.

4. Навыки

*️⃣Указываем по максимуму хард-скиллы и стек — релевантные под вакансию и рынок (что писать, если не знаешь, обсуждали в посте выше). На hh максимум можно указать 30 навыков — используй это место по максимуму.

4. Курсы

*️⃣Тут много споров - я не пишу полотно курсов, только качественные и, если все таки есть желание их написать, то основную массу советую ставить в даты старта карьеры.

Резюме — это не просто документ, а инструмент продаж твоего опыта/тебя как специалиста.

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

А сколько версий резюме у тебя сейчас — одно универсальное или под каждую вакансию отдельное?

@data_driven_bogdan