✅ Поговорим про p-value

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

👍 Правильный вариант:

p-value — это вероятность получить наблюдаемое или более экстремальное значение статистики, если нулевая гипотеза верна (не отклонена).

👎 Неправильный вариант, интерпретаций встречается очень много:

p-value — это вероятность, что нулевая гипотеза верна
p-value = вероятность, что результаты случайны
Чем меньше p-value, тем больше вероятность, что гипотеза H₁

🥳 Окей, вроде бы понятно, а как это прочувствовать или почему мы вообще ссылаемся на p-value?

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

Самый простой вариант: это показать, что монетка нечестная (например, мы подбрасывали 10 раз монетку, 9 раз выпал орел).

H₀ (нулевая гипотеза) — Монета честная, то есть орёл и решка выпадают с равной вероятностью 50/50. p = 1/2
H₁ (альтернативная гипотеза для орлов), можно проверить одностороннюю гипотезу , тогда p > 1/2 или p != 1/2 (двустороннюю)

⚠ В данном примере мы будем проверять одностороннюю гипотезу.

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

👀 Например, 9 орлов из 10 могли выпасть в любом порядке: и в первых 10 подбрасываниях, и вперемешку с решками. Биномиальное распределение как раз учитывает все комбинации, при которых общее число орлов равно 9, независимо от последовательности их выпадения.

👨‍🔬 Общая формула биномиального распределения:

P(X = k) = Cn^k * p^k * (1-p)^(n-k)

Эта формула показывает вероятность того, что при n подбрасываниях монеты орёл выпадет ровно k раз.

где:
n — количество подбрасываний (в нашем случае 10),
k — количество орлов (успехов),
p — вероятность орла (для честной монеты 0.5),
Cn^k (сочетания из n по k) — число способов выбрать, в каких бросках выпадет орёл.

💡 Тогда при верной H₀ подставляем вероятности p = 1/2, считаем а какая вероятность получить такие же или более экстремальные значения статистики

Считаем P(X=9), P(X=10) и складываем их между собой.
Получаем p-value ~ 0.01074

🔽 Далее, полученное значение p-value мы сравниваем с уровнем значимости.

1️⃣ Если p-value > alpha, не отвергаем H₀, говорим что монетка честная на уровне значимости alpha.
2️⃣ Если p-value < alpha, отвергаем H₀, говорим что монетка нечестная на уровне значимости alpha.

На уровне значимости 0.05 мы можем сказать, что монетка нечестная, на уровне значимости 0.01 результат на грани, но мы не можем отвергнуть нулевую гипотезу.

🙊 А вообще самый сок, это объяснить бизнесу, что такое p-value, мне кажется, это даже можно спрашивать на собесах. Именно не само определение, а как бы вы простым языком на абстрактном примере рассказали продактам, что это такое и почему мы на это смотрим. Интересно почитать будет ваши комменты.

Ставьте 🐳, если пост зашел, делитесь вашими интерпретациями p-value простым языком!

@zasql_python

Всех с субботой!

Ставьте 🐳, если нужно сделать похожий Colab с методами по 🆎, делитесь как провели эту неделю в комментариях (можно мемы 😁)

Го наберём 200 🐳

UPD: большинство методов на 🐍

✅ Про длительность спринтов

Всем привет! Этот пост будет скорее обсуждением, интересно услышать ваше мнение.

🥳 Итак, я уже успел поработать в четырех компаниях. Понятие спринта абстрактное. Если вкратце, планируется определенный список задач на аналитику / разработку, которые должны быть сделаны к концу интервала времени.

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

👀 Лично я столкнулся с тремя видами на работе:

а) Спринт отсутствует
б) Недельный спринт
в) Двухнедельный спринт

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

⌚️ Второй вариант: недельный спринт. Как будто бы, не особо много разницы, ну что, возьмем просто, попилим количество затрат на два и распределим по неделям. Но! У меня было чувство, что я слишком сильно зажат сроками. Постоянные встречи, доработки по задачам и т.д. В этом случае (лично у меня), получалось так, что какой-то процент задач улетал в следующий спринт + я замечал у своих коллег похожее. Это могло быть связано с недооценкой сложности задачи и иными факторами.

😃 Третий вариант: двухнедельный спринт, у меня сейчас. Кажется, что вариант является удобным, так как интервал более-менее растянут + нет такой жесткой привязки по срокам и это меньше давит. У команд разработки часто спринты по две недели, удается быть в синке и распланировать ресурсы более оптимально. Еще очевидный плюс, что задачи размера L (обычно они занимают 5-6 дней) можно без декомпозиции поместить в двухнедельный спринт. Это нам гарантирует сохранение целостности без потери имеющегося контекста. Ну, а задачи с большей сложностью нужно уже декомпозировать 😞

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

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

@zasql_python

🔗 Text2SQL в аналитике: как мы научили ИИ понимать бизнес-запросы без посредников

В этой статье 🖤 описывают, как внедряли Text2SQL, какие модели использовали и обрисовали общую проблематику, реализуя у себя.

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

Пишете в бота: «Средний чек Москва, 2025 vs 2024, динамика в%» → Через 15 секунд получаете точный ответ с трендом.

❓ Как выглядит пайплайн? (упрощение).

1. Запрос пользователя, промпт с описанием таблицы
2. Text2SQL (LLM)
3. Определение типа визуализации.
4. Бекенд -> БД (забрать данные)
5. Чат

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

😜 В качестве MVP предлагается собрать одну витрину. В примере X5 — это табличка с > млрд. строк и ~150 колонок.

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

🍪🍪 Основные вызовы при решении задачи:

1. Написать логику сборки метрик
2. Учитывать контекст предыдущих сообщений
3. Обработка естественного языка и неоднозначных формулировок
4. Борьба с галлюцинациями
5. Оптимизация скорости и ресурсов
6. Работа с большими схемами данных
7. Интерпретация результата
8. Валидация качества работы модели. В качестве метрики использовали (LLM + EX) / 2 для сравнения нескольких моделей.

🐸 Метрика для оценки качества (LLM + EX) / 2

Метрика рассчитывается через попарное сравнение отсортированных колонок. У этого подхода есть ограничения: если, например, модель вывела долю вместо процента — получим False Negative. Если пользователь сформулировал общий запрос, допускающий несколько корректных SQL-вариантов, то результат также будет считаться ошибкой.

LLM. Совпадает ли сгенерированный SQL с эталонным по логике запроса.
EX (Execution Accuracy). Совпадает ли результат выполнения запроса (таблица/агрегация) с заранее написанным ответом.

🐸 Результаты моделей:

DeepSeek R1 (0.765) — лидер по совокупному качеству: наиболее точные и осмысленные SQL-запросы.
Qwen 2.5-72B (0.425) — уверенное второе место, компромисс между качеством и ресурсами.
SQLCoder-8B (0.185) — слабый результат: частые галлюцинации и ошибки исполнения.

В итоге команда X5 остановилась на Qwen 2.5-72B.

✈️ Дальнейшие планы:

1. Поддержка нескольких таблиц
2. Поддержка запросов с джойнами
3. Внедрение классификации запросов пользователей по сложности
4. Дообучение собственной модели
5. Замена LLM на более лёгкие модели
6. Работа с произвольными Excel-файлами
7. Schema-linking на основе RAG’a

✏️ Дополнительные комментарии

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

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

🔗 За полной статьей сюда, дублирую ссылку.

Ставьте 🐳, если понравилась статья (ну и конечно, если ждете сборник методов по 🆎)

@zasql_python

❓ Вы помните свой первый собес в IT? Как это было?

Давайте разбавим пятницу не душными темами.

Мне кажется, это хорошая рубрика, особенно, для такого замечательного дня недели 🥳

🔽 Можете писать в комменты, а я пока начну.

1. У меня это был Сбер 💳

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

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

4. Результат: Договорились, что я сделаю тестовое задание и пришлю различные визуализации. Я бы вам показал, только, оказывается затер это все на гите (там были графики на матплотлибе, пандас, все без выводов). Как итог, мне кинули реджект. Я немножко погрустил, но пошел дальше откликаться на доступные вакансии. И было тогда не важно, лишь бы взяли на аналитика 🙏🙏

Почувствовал, что если меня рассмотрели в бигтех, значит можно собеседоваться дальше и останавливаться на этом не нужно.

А теперь ваша очередь — где проходили свой первый собес и что из этого вышло?

Ставьте 🐳, если понравился пост и пишите, какой был ваш первый собес 🔽

@zasql_python

☺️ Всех с наступлением выходных!

Делитесь мемами, которые характеризуют ваше состояние после рабочих будней 👇

🆎 ЦПТ, скосы распределений, логарифмирование

В Google Colab приложил симуляции, которые показывают, как интуитивно работают методы + прикрепил разбор статьи с описанием работы различных методов, сходимости и прочее.

🔗👉 Ссылочка тут

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

Если наберется много 🐳, разберу подробней парочку из них. Где-то планируется завышать значение t-критическое, где-то отсекать хвосты и моделировать их через определенный алгоритм, а где-то их обрезать, например, как тут выкинуть топ n% выбросов, ну и существуют методы, когда заменяют выбросы значением квантилей.

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

🐍 Дополнительно дублирую ссылочку на Google Colab

🐸 @zasql_python

комменты в посте сломаны, это грустно ☹️

Классы в Python для аналитика (?)

Знаю, что многим аналитикам тема классов кажется ненужной — и это нормально.

Сам изучал ООП на своем направлении в магистратуре, очень много всего предстояло изучить... И про свойства, про то, как реализовать, жуть короче, хочется функциями пользовать и все (и то максимум)...

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

Например, в pandas 🐼.

1️⃣ Класс: pandas.DataFrame, который задает структуру таблиц: колонки, индексы, методы
2️⃣ Объект: df = pd.DataFrame(...), может быть задан через чтение баз данных, csv, вручную и тд.
3️⃣ Методы: df.groupby(), df.query, df, etc.

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

🔽Опишу самый простой пример 🔽

Класс User описывает пользователя продукта.
У него есть: атрибуты user_id, os, orders и метод is_active(),
который определяет, активен ли пользователь (есть ли у него заказы).

class User:
    """Класс, описывающий пользователя продукта."""

    def __init__(self, user_id: int, os: str, orders: list[int]):
        """
        Args:
            user_id (int): Уникальный идентификатор пользователя.
            os (str): Операционная система (например, 'iOS' или 'Android').
            orders (list[int]): Список идентификаторов заказов пользователя.
        """
        self.user_id = user_id
        self.os = os
        self.orders = orders

    def is_active(self) -> bool:
        """Проверяет, есть ли у пользователя хотя бы один заказ."""
        return len(self.orders) > 0

Я слышал, что на некоторых курсах по аналитике уже включают ООП. Например, в теме по 🆎.
Это логично: когда ты работаешь с десятками экспериментов, хочется выстроить для них единую структуру, чтобы каждый тест имел одинаковый формат, методы расчёта и итоговую инфу 👀

class Experiment:
    def __init__(self, name, control, test, metric_name):
        self.name = name
        self.control = control
        self.test = test
        self.metric_name = metric_name

    def calc_mean(self, group):
        return group[self.metric_name].mean()

    def uplift(self):
        return (self.calc_mean(self.test) - self.calc_mean(self.control)) / self.calc_mean(self.control)

    def summary(self):
        return {
            "experiment": self.name,
            "uplift": round(self.uplift() * 100, 2),
            "control_mean": self.calc_mean(self.control),
            "test_mean": self.calc_mean(self.test),
        }

Но в крупных компаниях зачастую реализована своя A/B платформа, аналитику остается только делать дизайн эксперимента, подводить итоги и делать рекомендации... 🧐

💻💻 Подход с классами не ограничивается тестами.

Необязательно использовать что-то сложное, например, на обучении я реализовывал классы для обращения к API / обработке ошибок / хранения информации на кошельке у юзера. Офк, это можно решить и с помощью SQL (про хранение данных), а у меня проект был без него 💅

Его можно применять и в других задачах — например, в ML, где удобно базово описать модель под свои данные и потом переиспользовать или наследовать её в будущем.

class ConversionModel:
    def fit(self, df):
        ...
    def predict(self, new_data):
        ...

✏️ Что можно почитать?

1. 🔗 Ссылочка 1
2. 🔗 Ссылочка 2
3. 🔗 Ссылочка 3

Если интересен разбор с кейсами применения ООП, ставьте 🐳, пишите, использовали ли вы у себя?

@zasql_python

Рабочая суббота! Правда, замечательно?

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

Но раз у компа, напишите...

Из какой сферы вы вкатились в IT? Или это был логичный переход?

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

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

— классный
— мотивированный
— уверенный пользователь ПК
— знаю метрики
— средний балл хороший!

(не было опыта в общем, хотел себя продать).

Помню, что была смешная попытка собеседования в компанию:

Рекрутер написал, что мне нужно быть в 20:00 со своей ручкой и распечатанным резюме (2021 год на дворе). Наверное надо было пересмотреть Волк с Уолл-стрит и продать ручку...

Конечно же, я не поехал :)

Один знакомый посоветовал курсы Тимофея Хирьянова по алгоритмам. Скажу честно, я все записывал в тетрадочку, но меня хватило ненадолго 😢, не зацепило меня писать код про черепашку

Следующий заход у меня был через полгода ⌚️

Решил вкатиться через хакатон, который длился 7 месяцев кстати 😁

Удалось проскочить в одну компанию с этим проектом и вкатиться в IT,
а дальше вы историю знаете, я надеюсь 👀

А как вы вкатывались в IT? Почему решили вкатиться? Пишите в комментариях 🐳🐳🐳

@zasql_python

🫙 Про чтение в SQL [ч. 1]

Господа-аналитики, ничего сложного, делаем 90% своей работы, все в порядке. А вот как работает все под капотом не было особо сильного понимания. Решил глянуть парочку источников... 🔥

Будем говорить в контексте работы с нераспределенными базами данных. К ним относятся: PostgreSQL, MySQL, Oracle, MS SQL.

Увидел формулировку ниже, решил покопать ⌨️

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

👀 У ИТМО нашел страничку, где описаны объемы, производительности, стоимости, в целом можно собрать какие-то выводы, что оперативка быстрее и лучше, но дороже, в целом понятно, почему хочется меньше жесткого диска)

Но RAM выполняет функцию буфера, а данные хранятся на диске.

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

CREATE TABLE people (
  last_name varchar(32),
  first_name varchar(32),
  second_name varchar(32),
  sex char(1),
  birthday date
);

Допущение, что в среднем фамилия имя и отчество состоят из 7 RU символов,
а кодировка используется Unicode, тогда средняя строка займет на диске:

(7 * 2 + 1)  * 3 + 2 * 1 + 4 = 51 байт

💅 Есть еще определенная метадата, которая будет добавлять +32 байта, тогда средняя строчка займет 83 байта с учетом метадаты. Блок - это минимальная единица чтения и записи базы данных (страница данных в файле таблицы).

Один блок во многих учебных материалах идет в 4 кб (4096 байт)

👩‍💻 У постгре, например, он стоит в 8 кб по стандарту

=> В одном блоке содержится 📛

4096 / 83 = 49 строк и 29 байт остатка

⚠ Важно: база читает не одну строку, а весь блок целиком.

В таблице у нас 1000 записей, значит суммарно у нас будет блоков:

1000 / 49 ~ 20.4 блоков (округляем до 21)

Хотим сделать фильтрацию в SQL 🔽

select * from people where last_name IN ('Иванов', 'Петров', 'Сидоров');  

❓ Мы не знаем где находятся записи, поэтому блоки будем считывать последовательно ([1, 2, 3, ... 21] блок, а может наши данные находятся в 12, 15 и 21 блоке).

🙊 Чем ближе нужные строки друг к другу, тем быстрее запрос. Если они лежат в одном блоке, база считает всё за один проход, а если раскиданы по разным, то придётся читать каждый блок отдельно 🐢

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

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

А я то думал, что когда был в 💙 и строил витрины с сегментациями, сортировками,
думал, что все просто, но еще нужно много всего подучить 🧑‍🎓

@zasql_python

Еще чуть-чуть и снова выходные 🤟

Что планируете успеть сделать за эти три дня?

— Начать писать скрипт для задачи 👍
— Понять, что все работает не так ☠️
— Начать переписывать логику ✏️
— Не сохранить и снова начать писать заново, потому что сервер перезапустился, а автосейв не сработал 🔄
— Отвлечься на несколько адхоков и потерять контекст задачи 🤞
— Потратить несколько минут, чтобы обратно въехать контекст и продолжить делать 👍
— Принять судьбу и с поражением закрыть ноутбук до завтра 🥳
— Повторить цикл ещё пару раз до пятницы 👍
— Идем отдыхать 🛌

Пишите свои дела в комментах 👇

@zasql_python 👉 @ds_memes

🤨 Преобразование Фишера для оценки доверительного интервала корреляции Пирсона

Корреляция может пригодиться в разных сценариях, например, когда мы строим модели линейной регрессии, отбираем признаки или бизнесово смотрим какие метрики линейно связаны ⛓️

Кажется, что np.corrcoef(a, b)[0,1] достаточно.

Ну или аналог ниже 🔽

import numpy as np
r = (np.cov([a,b], bias=True) / np.sqrt(np.var(a) * np.var(b)))[0][1]

Это хорошо, мы можем посчитать точечную оценку на выборке. Но! Мы же не знаем истинного значения коэффициента корреляции генеральной совокупности (также, как и средние, например). Выход: мы обычно строим доверительные интервалы на уровне значимости alpha.

Корреляция 0.8 звучит уверенно, но насколько мы в ней уверены статистически?

Когда это нам может пригодиться?

1. Аналитические исследования: насколько сильно линейно связаны метрики в продукте, для первой итерации по поиску прокси-метрик в 🆎
2. Сравнение корреляций между сегментами.
3. В 💻 насколько фича связана с целевой метрикой...
4. Мониторинг стабильности метрик. Если начала связь разъезжаться, возможно, поведение пользователей поменялось.

Ниже преобразование Фишера, которое делает распределение ближе к нормальному. Сгенерируем две случайные величины с корреляцией, равной 0.8. Для них посчитаем доверительный интервал Фишера на Python 🐍

from scipy.stats import norm 
import numpy as np

np.random.seed(42) 

n = 10000
rho = 0.8

mean = [0, 0]
cov = [[1, rho],
       [rho, 1]]  

x, y = np.random.multivariate_normal(mean, cov, size=n).T

r = np.corrcoef(x, y)[0, 1]

def fisher_ci(r, n, alpha=0.05):
    z = np.arctanh(r)
    se = 1/np.sqrt(n-3)
    z_crit = norm.ppf(1-alpha/2)
    lo = np.tanh(z - z_crit*se)
    hi = np.tanh(z + z_crit*se)
    return lo, hi

lo, hi = fisher_ci(r, n)
print(f"Доверительный интервал корреляции Пирсона: [{lo:.3f}, {hi:.3f}]")

Для Спирмена или Кендалла можно использовать бутстрап или другие приближения...

Если хотите разбор — какие вообще тесты (например для 🆎) бывают и когда какой использовать — ставьте 100 🕺, соберу подборку с примерами

А еще недавно у меня закончился ИС в 🛍, если вам интересно про это почитать, ставьте 100 😎

@zasql_python

👀 Снова собеседования?

Нет, пока я никуда не собираюсь из 🛍, в следующих постах расскажу про прохождение испытательного срока и общее впечатление от процессов

Интересно посмотреть со стороны компании, нанимающей аналитиков сейчас.

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

Много компаний придерживаются следующих этапов:

1. Скрининг + HR
2. Технический этап собеседования
3. Финал

🍪🍪 На скрининге происходит первичный метч между компанией и кандидатом (по зп / релевантному опыту и другим факторам).

А вот интерес к техничке:

Что спрашивать кандидата? Предположим, мы хотим прособеседовать универсального аналитика. Python + SQL + A/B + Статистика + BI + продуктовое понимание + ML (необязательно). Грейд кандидата определяется по количеству выполненных заданий по критериям. То есть под конкретные задачи мы его не закрываем, проходит общий трек.

🐍 Давать SQL, Python? Для общего понимания "хардов" кандидата? Сейчас LLM в большем количестве случаев справляется с написанием кода, но, трехэтажные запросы, создание витрин не вывозит. С Python периодически приходится дебажить, если сложная функция.

🎲 Давать статистику и теорию вероятностей? Мы считаем, что это является прокси к мышлению кандидата? Задачки на теорему Байеса, кубики можно выучить (зачастую их и дают на собеседованиях).

🆎 A/B тесты? Да, если человек проводил эксперимент, он может знать общий регламент. "Продвинутые" методы для A/B тестов давно есть на Хабре, их можно заботать.

📊 BI. Был опыт? Да / нет.

Слышал, что некоторые спрашивают про LLM, но это пока что экстраординарные случаи. Ну и про вайбкодинг, конечно 🤔

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

Некоторые компании (например, 🛍) фокусируются только на продуктовых кейсах, так как уровень кандидата можно понять по разбору его проектов, работе, соответственно. Считаю, что это один из правильных вариантов, так как времени зачастую на проведение секции не хватает. На самом деле, техническая секция в случае с Avito разделена на две. Стата / тервер + оценка по матрице компетенций.

🙊 Если бы вы сегодня собеседовали аналитика — что бы проверили в первую очередь: мышление или харды? Пишите свое мнение, будет интересно почитать.

Ставьте 🕺, если хотите дальше читать про собесы, а я пошел писать пост про мой испытательный срок и 🆎

@zasql_python