На днях узнал что пчелиные колени - это расизм по отношению к итало-американцам

The phrase about something being "the bee's knees" (to mean really good) is actually racism against Italian Americans
They'd be saying "it's the business" (also meaning really good), but their accent made it sound like 'bee's knees'

Долго смеялся

Доводилось ли вам работать в экстремистких организациях? Я чуть было не попался на крючок экстремистов

https://tass.ru/obschestvo/14041251

23 марта буду читать лекцию в University of Manchester в рамках Google Developer Club про Блокчейн и Машинное Обучение, постараюсь выложить запись

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

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

Как маслом по сердцу

Перестал участвовать в митапах ситимобила с этого года ...

Расскажу историю про цепочки передачи информации

Однажды я работал в компании Foss, которая выпускала и выпускает анализаторы для пищевой промышленности, в том числе для молока. Анализаторы Foss стоят почти на всех заводах Данон, ВимБильДан и тп

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

В большинстве стран, количество молока поступающего на переработку составляет примерно 95-97% от произведенного молока. Часть теряется при перевозке, портится, выпивается и прочая усушка и утруска. В России же, эта доля достигает всего-лишь 50-60%, очевидно потому что в России очень любят пить сырое молоко.

Мы, как люди опытные и живущие в России, объяснили, что это молоко было произведено лишь на бумаге. Есть план по производству молока, в какой-то год он не был выполнен в реальности, но был выполнен на бумаге. На следующий год план считали от предыдущего, так и накопилось с годами планирования на основе некорректной информации.
Garbage in - garbage out.

Самое интересное, что почти все об этом знают. В 2014 году даже предлагали молочную амнистию
https://dairynews.today/news/rosstat-podderzhivaet-molochnuyu-amnistiyu.html

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

Тем не менее, группа неравнодушных людей решила создать Global Tech Talent Pool и используя свои связи помочь людям релоцироваться и устроиться на работу

Прочитать условия и воспользоваться можно здесь

https://airtable.com/shro54oadC9EWpxhc

Написал Engineering Manager соседнего департамента.

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

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

Продолжаем пост из серии как готовиться к интервью, совместно с @nizhib

TL;DR подготовка

1. Решить топ-100 задач по частоте за полгода у нужной компании на leetcode
2. Пройти “Grokking ...” курсы по SD и ML SD, тренировать whiteboard с таймингами, посмотреть интервью по SD и ML SD на Карпов Курсес, по отзывам людей - эти видео очень сильно помогли
3. Сделать интро о себе и написать о себе ответы на вопросы, примерно 1/2 A4 по STAR шаблону на каждый из примерна 40 behavioral вопросов

Теперь немного подробнее.

Как готовиться к интервью по алгоритмам

Интервью по алгоритмам это очень просто, решение задач вроде тех, что можно найти на https://leetcode.com/. Задачки на интервью решаются либо чере сервисы совместной правки кода вроде https://coderpad.io/ либо через гугл док. Вы могли слышать от своих друзей-олимпиадников какие-то заклинания вроде “Красно-черное дерево”, “алгоритм Декйстры”, “Ахо-Корасик” — можете забыть. Типичный уровень интервью с кодом это пара задач easy+medium/hard на 40 минут про поиск в глубину или переворот списка. Как готовится к этой секции с нуля и не только?

От самой платформы есть “батлпасы” с подборками задач по темам — они отображаются вверху над задачами по ссылке. Рекомендуется как минимум присмотреться к батлпасу по алгоритмам и структурам данных.

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

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

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

Можно попробовать пройти пару Мок интервью, тоже полезно

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

В целом, это пожалуй самая легкая часть в процессе найма.

#InterviewPreparation

Через 9 минут выступаю здесь

Присоединяйтесь к нашему голосовому чату. В 19:00 начнём обсуждать ситуацию на рынке труда. Приглашённые гости — наши выпускники и специалисты IT-компаний — ответят на ваши вопросы и поделятся своим опытом работы за рубежом: https://t.me/karpovcourseschat

Продолжаем разговор и сегодня поговорим про еще один архетип Стафф Инженера - Решала

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

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

Зачастую Решала перестает работать над проблемой, как только критическая стадия миновала, что может создать некое ощущение ветрености и непостоянства, так как команда остается поддерживать "решенную" проблему

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

#BigTechLevels

Примерный календарь решалы

Сделаю репост своей записи на linkedin

Why precision is a dangerous metric

I had a recent conversation with a friend of mine regarding the evaluation of fraud models.

Of course, no metric is ideal, and it always depends on what is the final goal. However, we usually want to maintain a specific fraud-to-legit transactions ratio when we speak about fraud models. If we would have ten times more transactions, it is probably ok to have ten times more fraud, but not twenty of thirty. In other words, we want to have a probabilistic model.

Another thing is that fraud usually belongs to the class imbalance problem, and this imbalance is not constant. One day it can be 1:100 (outburst of fraudulent transactions), next day, 1:1000 (an ordinary day) and next day, 1:10000 (fraudsters took a vacation)

The problem with precision is that its calculations take both classes into account, precision = TP/(TP + FP)

Imagine we have a model which has a probability of 95% to predict that fraud is a fraud and 5% to predict that non-fraud is fraud.

Review two scenarios

P = number of positive samples, N = number of negative samples
P = 10000, N = 10000, Precision = 0.95*10000/(0.95*10000 + 0.05* 10000) = 0.95
P = 1000, N = 10000, Precision = 0.95*1000/(0.95*1000 + 0.05* 10000) = 0.65

It is easy to prove that TPR and FPR would not change because those are rates independent of class imbalance. AUC, which can be shown to be an averaged Recall (TPR) of class 1 and 0, is also class balance insensitive and, thus, probabilistic.

Initially, my friend created a notebook to prove me wrong ( I slightly adjusted it to show the opposite). He said, quote:

Model A is better according to both ROC AUC & PR AUC Metrics. However, model B (bad model) still gets a very good FPR (0.00092) even though if it was put into production, the predictions would be rubbish (920 out of 1000 fraud predictions would be incorrect). Precision allows us to see this. It's just 0.08 for Model B, so we'd never even think about putting it close to production :D


Now, what is the fallacy here?
First of all, model B has an FPR of 0.0092, which is 46 times higher than model A, with an FPR of 0.0002. There is no good or bad FPR. It depends on your volume, and even a slight difference might be huge. 0.99 is ten times higher than 0.999, 1:100 vs 1:1000.
But, even here, while precision is only ten times worse, the FPR of model B is 46 times worse, hard to call this to be very good.

As you can see in the notebook above - precision shows a very different number with the shift in class balance, even with the same model performance. At the same time, both TPR and FPR remain the same. Note that the total volume of transactions almost didn't change.

I strongly recommend using the following metric to assess your fraud models.
Fix specificity on the desired level (specificity = TNR = 1 - FPR), for example, in one company, where we had a goal to catch a fraudulent behaviour and more than 100 000 000 000 events per day; we were fixing specificity to be at least 0.999999 (in other words, we were ok to have one false positive per one million events) and maximising recall (true positive rate)

In the next post, I will provide another reason why precision is dangerous.

Пример unbiased estimator в реальной жизни. Youtube попросил оценить видео

Перебираю старые фотки, с ностальгией вспоминаю стендапы в Мета

24 марта в 18:00 в МТС проводят онлайн-митап для дата саентистов, дата инженеров и других дата людей

Ребята из МТС и ivi.ru расскажут про PU Learning и разберут принципы сортировки блоков с фильмами на главной странице IVI. После этого мы с Виктором Кантором и Пашей Мягких устроим панельную дискуссию про использование Data Science в разных сферах бизнеса.

Участие, бесплатное, регистрируйтесь по ссылке:
https://mts-digital.timepad.ru/event/1962458/

Slack ODS (open data science) переводят на Free Plan.

Окончательно заявлять что это приведет к остановке существования нельзя, но чат на 60к с человек, где хранятся лишь последние 10к сообщений и нет мудрости прошлых веков, это совсем другой чат

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

Импортозамещение

Upd. Слак не банит ОДС, до этого мы были на бесплатном режиме, теперь надо платить, сумма измеряется миллионами долларов в год

Отправили вместе с @arsenyinfo из @partially_unsupervised оглавление книги Machine Learning System Design на ревью в издательство, ревью проводит N человек по M пунктам, один из ревьюеров удивил

Is the Table of Contents appropriate for the readers described in the proposal? What should be added or deleted to reflect this reader more accurately?

Yes, the TOC is quite versatile and covers a huge range of topics all important for data science projects. However, ML is normally considered much narrower: ML normaly refers to the learning algorithm alone, so a data science project could use ML (but has not to) but data science is usually considered a much broader field than ML. Now it confuses me a little that a book about ML systems covers things like data gathering and reporting as this is exactly what separates classical ML from data science.

Does this description match the reader you would expect to be interested in this topic? Why or why not?

Not really, as data scientists and software engineers are not the same roles and it is not clear to me who would profit the most. From the TOC and the title it is clear that the book mainly addresses software engineers, but data scientists (more than ML people) are the ones who really have to come up with ML systems, so I would expect data scientists to be the main target audience.

Is the title of the book appropriate to the subject?

I feel that the book is more about data science systems than ML systems as ML for me means mainly learning algorithms, so a book about ML is normally considered to deal with learning algorithms like supervised and unsupervised algorithms, and not about pipelines and data collection, model monitoring etc. An exception is MLOps, which deals exactly with how to operate ML solutions, but I feel that the title could be broader and should not necessarily contain ML at its core.

Много думал

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

https://youtu.be/Ux81IqLuxco

Слава Вадиму

Пришла пора послушать единственного человека @nizhib, успешно прошедшего собеседование
https://www.youtube.com/watch?v=iqbsHiSnZQE