Самый странный собес в моей жизни на позицию аналитика

⌚️ Это было примерно 3-4 года назад, когда у меня уже был реальный опыт работы.

✅ Компания: онлайн-кинотеатр
👌 Позиция: младший аналитик данных

Первое, что меня смутило: на собеседовании сидело 5 человек
Ощущение — будто я подопытный кролик, а не кандидат 🫙

🙊 Наверное, я могу себе это объяснить следующим:

1. это был показательный собес для других аналитиков (было 3 аналитика)
2. был кто-то из продукта (для оценки продуктового мышления)
3. был HR, но для меня это странно на технической секции
4. ...или я просто попал в реалити-шоу, я в телеке, ура!
5. ...или мне сразу решили устроить стресс-тест

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

Помню задачу на расчет метрик, а конкретно фидбек нанимающего менеджера

Максим, мне все понятно, собеседование закончим,
ты медленно решаешь задачи, нам нужны специалисты, которые быстро могут написать SQL-запросы 🔥

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

🔥 Я тогда жестко сгорел, у меня опустились руки, но вот что я хочу донести этим постом (первый раз не через HR сказали странный фидбек):

1. Отсутствие фидбека — красный флаг. Если тебе не могут дать четкий фидбек, можно задуматься, сейчас стараюсь на собесах четко говорить по каждой задаче, что можно улучшить, о чем можно рассказать.
2. Иногда отказ — это лучшее решение для тебя. Спасибо, что тогда не взяли на работу 😂
3. Думать вслух. Важно при найме оценить то, как мыслит кандидат. Структурно он решает поставленную задачу или нет.
4. Собеседования — не оценка компетенций. Это навык, который нарабатывается путем прохождения различных собеседований + изучения чего-либо. Как вы думаете, задачу бы на собесе не решили без ограничения по срокам и наличием гугла / LLM?
5. Много людей не должно вызывать стресса. Представьте обычную рабочую встречу: вы общаетесь сразу с несколькими людьми, обсуждаете задачу, отвечаете на вопросы.

🏃‍♀️ Тут можно сказать, что я не прав, и аналитик должен быстро решать базовые задачи. Возможно, тогда в компании реально были процессы, где скорость критична.
Но вопрос другой: должно ли это быть решающим фактором при выборе аналитика?

🔽 Интересно ваше мнение, пишите в комментариях

Как вы считаете, стоит давать обратную связь сразу же на собеседовании?

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

Зашел такой пост? Ставьте 🐳, посмотрим, какие у меня еще есть истории с собесов

Помните свой странный собес? Напишите в комментариях — интересно собрать реальные кейсы 👇

@zasql_python

Листал Linkedin, нашел такой пост, интересно посмотреть там комменты :)

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

1. Джуны действительно нужны, нужно вкладывать в развитие команд + можно нанять больше сотрудников.

➕ Инвестиция в команду, рост лояльности, масштабирование

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

➖ Время сеньоров, ответственность, риск неокупаемости

Пара комментов из поста:

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

Ни одному синьеру не нужен никакой джун, время на него тратить еще и ответственность ненужная

К сожалению, "Хороший человек" - это не профессия.

А утверждение "любой Сеньор будет рад стажеру - более чем спорное...

🙊 Лично мне кажется, что вопрос не в нужны или не нужны джуны, а в том, есть ли у компании инфраструктура под их рост.

Что думаете по этому поводу? Пишите в комментариях 👀

Ставьте много 🐳, выпущу пост-разбор задачки с собесов :)

@zasql_python

Классическая задача на повышение матожидания

Вариаций много, встречается часто с равномерным отрезком [0;1] или с перебросом шестигранного кубика.

🤓 Условие задачи

У вас честный шестигранный кубик.
Вы делаете первый бросок и видите результат X. Затем вы можете:

1. оставить этот результат
2. сделать второй бросок (перебросить) и тогда итогом станет результат второго броска Y.

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

Решение под спойлером

1. Матожидание кубика = (1+2+3+4+5+6) / 6 = 3.5

Ключевая идея: в среднем мы будем стремиться к 3.5 при бесконечном количестве бросков. Мы хотим максимизировать выигрыш. Для этого мы должны сравнить теоретическое значение с фактическим.

а) Если x > 3.5, выгоднее оставить, так как в среднем мы получаем меньше, чем видим сейчас
б) Если x < 3.5, лучше перебросить, в среднем мы получаем больше, чем видим сейчас
в) Если x = 3.5, ничего. Но фактически мы не можем получить 3.5, поэтому разбивается на два сценария (только а и б).

Имеем исходы с перебросом: {1; 2; 3} и исходы без переброса: {4; 5; 6}

2. Теперь к выигрышной стратегии

Пусть W выигрышная стратегия а E(Y) — матожидание кубика, будем смотреть на вариации первого броска и дальше считать матожидание стратегии

При X <= 3

E(W|X=1) = E(W|X=2)=E(W|X=3) = E(Y) = 3.5

💡 Когда нам выпало 1, 2 или 3, мы отказываемся от этого значения и фактически играем заново с чистого листа, а значит в среднем получаем матожидание одного честного броска — 3.5. Второй бросок — обычный честный кубик 🎲

При X > 3

E(W|X=4) = 4
E(W|X=5) = 5
E(W|X=6) = 6

Тогда E(X| X > 3) = (4+5+6) / 3 = 5

При выпадении 4, 5 или 6 текущее значение уже больше математического ожидания нового броска (3.5), поэтому перебрасывать невыгодно. Поэтому условные матожидания будут фактическими значениями на кубике.

Тогда получаем матожидание выигрышной стратегии

E(W)= P(X<3) * E(Y) + P(X>=4)*E(X|X>=4) = 3/6 *3.5 + 3/6 * 5🥳🥳🥳

Еще есть интересный вопрос на понимание: А что будет, если перебрасывать мы будем не один раз, а два, три и так далее? Меня это кстати спрашивали на собеседовании в одной компании. Нужно включить голову 🤔

Спойлер для двух перебросов (максимум 3 броска):

Так как при одном перебросе (двух бросках) матожидание оптимальной стратегии равно 4.25, то при двух перебросах оптимально оставлять 5 и 6.

E(W) = 4.25 * 4/6 + (5 + 6) * 2/6 = 14/3 = 4.666...

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

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

🐍 Python можно задать вот так

def expected_value(rerolls, sides=6):
    """
    Возвращает максимальное матожидание,
    если осталось несколько перебросов
    """
    V = (sides + 1) / 2

    for _ in range(rerolls):
        total = 0
        for x in range(1, sides + 1):
            total += max(x, V)
        V = total / sides

    return V

for k in range(5):
    print(f"{k} перебросов. Матожидание = {expected_value(k)}")

Ставьте 🐳, если понравился разбор и нужен разбор еще задач!
Делитесь в комментариях, попадалась ли вам подобная или похожая задача? Можно разобрать!

👌 Если у вас есть Premium, вы можете бустануть канал — это бесплатно и занимает 3 секунды. Нам совсем чуть-чуть осталось до 10 уровня, хочу поставить обои!

@zasql_python

Как правильно входить в собеседование

Оригинал поста

Ладно, тут не только про шашлыки

🙊 Комментарии к посту

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

Не вижу ничего плохого в том, что такие кандидаты сразу освобождают место для более внимательных и заинтересованных кандидатов :)
Да и для компании хорошо - лучше всё сразу понять на собеседовании.

Так в чём неуважение-то проявляется в случае с шашлыком? У меня в 2025 году вообще было 2 собеседования в ресторане. И что тут неуважительного? И вопросы позадавали, и поели вкусно.

А вы что думаете? Норм шашлыки делать на собесе или стрем?

🍢 — норм, можно показать на практике многозадачность, критическое мышление и умение жарить шашлыки.

👎 — стрем, кандидат должен быть вовлечен в собеседование и это смущает вообще. Хочется быть "на равных".

@zasql_python

[СТАТЬЯ] Покоряем гору временных рядов: делаем прогноз для 200+ рядов с библиотекой Etna

У Магнит OMNI ❤ 19 января вышел туториал для новичков по временным рядам с использование библиотеки ETNA

Ниже короткий разбор, что в ней есть 👇

1. В статье начали с наивных прогнозов последним значением, а далее начали применять библиотеку ETNA
2. Сравнивали несколько моделей по WAPE (абсолютной взвешенной ошибке)
3. Показали как применить пользовательские преобразования (в примере — создание линейного тренда для модели линейной регрессии) ✏️
4. Выделили блок про стандартизацию данных для оценки временных рядов (в целом, это нужно для соразмерности сравнения ошибок между моделями).
5. Уделили время аномалиям (что они влияют на прогноз и как фреймворк может их обнаруживать).
6. Какими значениями можно заменять аномалии (в примере — предыдущее значение).
7. Далее указали, что проблема может быть в точках изменения тренда.

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

Сам сталкивался с проблемами аномалий и точек перегиба — в статье это подсвечено.

Если вдруг будет интересно, можно попробовать собрать пару постов по прогнозу временных рядов, если увижу много 📈 (давайте попробуем 150+).

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

А как у вас дела с временными рядами? Успели с ними поработать и что-то спрогнозировать? Делитесь в комментариях

@zasql_python

Что ж, всех с понедельником! Календарь забит важными встречами, просьба не отвлекать по всякой ерунде 😂

А как планируете провести эту неделю? И этот день?

Я:

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

А у вас как по плану? Работа, сияние или сразу царственно отдыхать? 😌

@zasql_python

Проблемы с фокусом во время работы — это не лень

Вы погружены в задачу, хочется ее решить.
Голова работает.
Но...

1️⃣ Вас выдергивают на важные встречи.
2️⃣ Вам спамят личку и спрашивают, какой статус по задаче
3️⃣ Вы думаете, что задачу нужно отдать идеально
4️⃣ Вы переключились на другую вкладку и в итоге забыли, зачем открывали
5️⃣ Параллельно вы начали делать другую задачу

И под конец рабочего дня задача не сделана, вы устали, чувствуете вину

Фокус ломается не из-за лени, а из-за среды и когнитивной перегрузки. Это проблема неправильной организации внимания.

🟢 Должен быть четкий объект фокуса. Нужно себе ответить на вопрос, над чем сейчас работаешь, чтобы явно себе понять, на чем нужно сфокусироваться.
🟢 Отключить ненужные уведомления. Нам кажется, что мы постоянно должны впитывать любую информацию. Но любая информация — это потеря фокуса на основных задачах 🔕
🟢 Выбрать оптимальную технику для фокуса. Это может быть Pomodoro, Deep Work, Pomodoro 2.0 даже. Техники бывают разные, в Яндексе я старался работать по Deep Work и это было эффективно. Сейчас выбираю для себя Pomodoro 🍅
🟢 Убрать мелкие выборы. Иногда себя ловлю на мысли о том, а какую вкладку нужно открыть (особенно, когда их много). Ранее слышал, что любое принятие решение тратит когнитивные силы, поэтому убираем 🤔
🟢 Фиксировать момент потери фокуса. Вы отвлеклись на другое дело? Это важно, потому что фокус теряется не случайно.

📺 Кстати, у Андрея было классное видео про то, как он вернул себе фокус на задачах

Еще из прикольного: там говорится о разгрузке мозга с помощью любого текстового документа, физическую активность...

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

А как у вас с фокусом? Теряетесь или все в порядке? Ставьте 🐳, если пост понравился, делитесь с теми, у кого проблемы с фокусом

@zasql_python

😁 Нашел себе занятие на выходные... на ближайшие N месяцев

💻 Забрал сегодня предзаказ книги Валеры Бабушкина и Арсения Кравченко по машинному обучению на русском языке.

Буду периодически закидывать сюда свои мысли по прочитанным материалам, формировать конспекты.

Если вам интересно, отреагируйте на пост реакциями или комментами 🐳

Кто-то успел ее уже прочитать на английском языке? Как ваши впечатления? Делитесь 🍪🍪

@zasql_python

🟡 ROC-AUC кривая. Метрика оценки качества модели классификации в машинном обучении

Да чего там делать пост, берешь sklearn, делаешь импорт из metrics и погнал. Чем ближе к 1, тем лучше => выбираем. Но давайте разбираться более детальною.

❓ ROC-AUC — это вероятность того, что наши положительные классы получили больший скор, чем отрицательные.

🔽 Пример: предположим, у нас есть следующая таблица.

| object | score value | y |
|--------|-------------|---|
| A      | 0.92        | 1 |
| B      | 0.81        | 1 |
| C      | 0.74        | 0 |
| D      | 0.63        | 1 |
| E      | 0.41        | 0 |
| F      | 0.27        | 0 |
| G      | 0.18        | 0 |
| H      | 0.05        | 1 |

✏️ Для каждого порога (в таблице значения) в отсортированной по скору таблице вычислим по строкам значения:

Для 1 строки считаем какие объекты попадают в score >= 0.92 — это один положительный класс. Среди всех положительных (4) => TPR = 1/4. При этом мы рассмотрели только один объект положительного класса => FPR = 0.

Для 2 строки считаем уже два объекта A, B. Это оба положительных класса. Среди всех положительных (4) => TPR = 2/4 = 1/2. Пока что объектов с классом 0 не попалось.

Для 3 строки считаем уже три объекта A, B, C. Смотрим на объект со скором >= 0.74. TPR по-прежнему = 1/2, а вот FPR увеличился, так как залетел новый объект с меткой 0. Среди всех отрицательных классов (4) => FPR = 1/4.

Далее считаем TPR, FPR для каждой из строк (Сколько объектов мы отнесли к положительному классу из всех возможных объектов класса).

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

Графически это выглядит как ступеньки (по оси X — FPR, по оси Y — TPR). При движении по трешхолдам для отнесения к классам смотрим как меняются значения TPR и FPR, кстати еще есть значения трешхолдов в самой библиотеке sklearn.

🧠 Чтобы посчитать вручную само значение:

Нужно взять все сочетания положительных и негативных классов и сравнить в каких случаях выше. Для нашего случая это:

1. A > C, A > E, A > F, A > G (пол.)
2. B > C, B > E, B > F, B > G (пол.)
3. C > D, C > H (нег.)
4. D > E, D > F, D > G (пол.)
5. E > H (нег.)
6. F > H (нег.)
6. G > H (нег.).

Считаем количество всех сочетаний: 16
Считаем количество правильных среди положительных: 11
ROC-AUC = 11/16 = 0.6875

✋ Ограничения в ML

1. Не учитывает цену ошибок (FP = FN по важности)
2. Не даёт порог для принятия решения
3. Ломается при сильном дисбалансе
4. Игнорирует калибровку вероятностей
5. Одно число скрывает локальные ошибки

🐍 Как можно применять для аналитики

1. Если есть модель и мы хотим определить есть ли сигнал в данных (ROC-AUC > 0.5). То есть позволяют ли наши признаки сделать модель такую, чтобы она была лучше случайности.

2. Понять, какие фичи улучшают разделение между TP и FP. Например, при добавлении фичи ROC-AUC увеличился => появился новый сигнал.

3. Проверка эвристики против модели. Оправдано ли применение ML-модели в принципе или достаточно эвристику.

4. Сравнение сегментов / источников сигнала. Задача: понять, где модель работает.

5. Оценка классификации по неделям. Понимаем, что ROC-AUC по неделям деградирует => нужно добавить больше признаков для обобщения.

6. Сравнение разных таргетов. Один таргет лучше отделяется => он более предсказуем и устойчив

Если коротко: ROC-AUC отвечает на вопрос есть ли сигнал, а не как принимать решение

Понравился пост? Ставьте 🐳, пишите комментарии!

@zasql_python

Перед запуском проекта привлекайте всех заинтересованных лиц (ну или почти всех)

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

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

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

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

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

3. Понятный список обязанностей на проекте. Казалось бы, что может здесь пойти не так. У дизайнеров свой вайб, у разработчиков и аналитиков тоже. Но есть часть задач, которые находятся на пересечении. Стоит это заранее обсудить перед запуском, так как возникнут сложности, либо несколько людей будут делать одну и ту же работу.

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

🥺

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

А у вас было такое, что вы узнавали о ключевом процессе уже после продакшена? Чем это закончилось — спасли или тушили пожар? Ставьте 🐳, пишите комментарии!

@zasql_python