Пока собираю пост про собеседования, поделюсь колымской тайгой на фото, которое уже не сделаешь -- там построили-таки ГОК, в 2011 руководил партией геофизиков-изыскателей под его строительство. DS мне тогда приносил катастрофически мало, приходилось подрабатывать иногда)

Точка, смотрю на запад.

#корпжиза

Про собеседования (1/2)
Сначала прелюдия, затем короткие посты-кейсы.

Выше уже описывал процесс– из каких этапов он состоит.

Почему я к этому пришел + несколько советов как проходить собеседования (не только к нам).

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

Тезис 2: процесс из нескольких собеседований с проверкой знаний / скиллов почти безальтернативен
Идеальное собеседование для меня – одно, на котором бы мы с кандидатом обсудили бы любой (по выбору собеседника) из его предыдущих проектов детально и в глубину – какие решения принимал, почему так а не иначе, что еще можно было бы попробовать, а что нужно было бы делать если бы задача чуть-чуть поменялась – цена ошибки выросла бы, или масштаб был бы другим (в любую сторону), какая метрика была, чем она хороша, какую модель использовал и почему и пр. Такая беседа взрослых людей.

К сожалению, в лучшем случае на такой вопрос получал ответ в духе “ну модель построил”. Иногда “сначала данные подготовил, потом модель построил”. Либо “не помню” (ага, год как проект прошел – ты даже не помнишь какая метрика была). В особенно запущенных случаях в HR приходили жалобы что “собеседующий подверг сомнению мою компетенцию”. Еще бывает что “не было времени, поэтому сделали фит-предикт”. Особняком идут накручиватели опыта – детально об этом в кейсах.
Кстати, я не против – если по-другому HR-фильтр не обойти, то почему бы и нет. Только когда уже прошел дальше надо либо детально разбираться в кейсе, который вы себе вписали, либо честно о себе рассказать.

Так что проще оказалось в стандартизованный процесс, проверяя конкретные знания / скиллы / теорию. И то – в ML мы тоже можем попросить кандидата выбрать алгоритм и рассказать как он работает детально. Логика здесь простая – опыт приобретается когда что-то не работает или идет не так. И тут два варианта – за вас кто-то сделает (например на stackoverflow взять готовый сниппет) или разобраться что на самом деле пошло не так.

Тезис 3. С лидами все чуть сложнее дольше
У DS-лидов / тех лидов в среднем с этим уже чуть лучше, но проблемы там начинаются другие. Например, опытные балаболы – считают что надо брать инициативу в свои руки и не давать слово вставить собеседующему, максимально уводить в сторону “а вот если бы у рыбы были бы блохи”. Или канальи-манагеры – которые оскорбляются на простые технические вопросы.
Вообще, если на собеседовании-знакомстве на неджуновую позицию вам резко решили задать вопросы по технике или по каким-то примитивным вещам – значит вы произвели впечатление что вы не в деталях чем занималась команда.

#корпжиза

(2/2)
Тезис 4. Руководитель – этот тот кто знает в каком направлении двигаться, где может быть овраг, а где примерно оазис.
Навыки “организации процессов” или “проектного управления” ничем не отличаются от бытовой способности к планированию, хоть обмажься Prince2 и прочими PMI.
Проектным менеджером может работать любой кто самостоятельно спланировал и организовал свой отпуск, проработав риски и вернувшись, живым, здоровым и с положительными эмоциями. А уже если были стыковочные рейсы или несколько стран – то это уже старший проектный менеджер.
Поэтому на позиции линейного менеджера вообще не стоит напирать на манагерское на собеседовании, лучше показать себя как опытного специалиста с актуальными знаниями и видением как применять ML в этом конкретном кусочке бизнеса.

Тезис 5. Если вам кажется что собес душный – вам не кажется, значит возникли большие сомнения в вашем опыте / компетенциях. И наоборот – когда все ясно все закончится быстро и вам пожелают скорейшего выхода на новое место.

Тезис 6. Процесс найма очень похож на медицинский скриннинг. Он затюнен чтобы не пропустить деструктивный элемент, а не на то чтобы отобрать лучших. Неизбежно будут хорошие ребята, которые не пройдут. Если собес показался вам токсичным / душным / травмирующим – даже кровь из вены сдавать неприятно, не говоря уже о колоноскопии.
В любом случае все что ни делается -- все к лучшему. Значит, попадете в более классное место.

Всего конечно в посте не описать, дальше потихоньку буду набрасывать мини-кейсами.

PS: в сети часто попадается эмоциональное восприятие собеседований.
Две вещи:
1) Отказ в найме по резултатам собеседований это не отказ в совместной работе, было бы желание -- способы найдутся. Не взяли в штат -- ну напишите в телеге нанимающему менеджеру и попроситесь на гпх / предложите вместе статью написать -- вариантов масса.
2) Все до единого опубличенные кейсы, которые я видел, или про которые знаю, когда кого-то "обидели" на собеседовании -- при внимательном рассмотрении оказывались ситуацией когда кандидат сам сильно налажал в общении с собеседующими -- очень часто доказывал что они глупее его и превращал какой-н проходной вопрос в битву за Фермопилы

#кейсы #ML

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

После "привет, меня зовут юзернейм", вместо короткого интро, он сходу начал рассказывать стишок 🤥 как он модели AML делал, называя разные ключевые слова вроде "использовал sklearn и xgboost", как он пользовался гитом и ставил все на “расписание в apache airflow”.

Собственно, я и взял это собеседование, ибо в резюме было ООО “Ромашка” 🌼и комплаенс – думаю, прикольно, бизнес на этом делают, мб узнаю нового 🍿 .

Как и в любом кейсе я спросил что именно моделировали – что было целевой переменной и объектом моделирования. Парень начал агриться и сказал про фродовые транзакции. Фрод задача другая (совсем не AML) и я попросил привести пример такой вот фродовой транзакции или рассказать откуда у него разметка.
Кандидат в качестве примера привел попадание компании в санкционные списки (тоже не AML, с натяжкой мб ФТ).
Я переспросил – транзакция в адрес компании из санкционного списка? А зачем тогда модель? Можно просто по справочнику определить такие.
Тут парень откровенно поплыл, уходя от вопроса во все стороны сразу (хотя схем обнала десятки если не сотни). На вопрос про фичи -- то же самое. Так мы и не выяснили что в итоге моделировалось 😵
Решил добить контрольным – спросил про код 6001 и Росфинмониторинг 😆

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

Если уж накручиваете – вывезите в бар 🍺🍺 товарища и замучайте его вопросами про каждый шаг в кейсе. Тщательно запишите и потом еще раз загуглите каждый термин и саму задачу. Задавайте вопросы из поста выше -- почему решили так а не эдак, как собирали таргет и фичи и тд. При необходимости – повторить, начиная с выбора кейса. Затем поищите в кагле или каком-нибудт открытом курсе похожую задачу и попробуйте закодить решение. Если все-таки нашли на кагле -- посмотрите публичные ноутбуки, как ее решают. Подумайте над тем как найденное решение будет вести себя во времени, если его в прод поставить. Как вы это бедете делать, как мониторить и какие метрики / показатели. Спросите в дружественном DS-чате, мб у кого-то был похожий кейс.

Если не заботали – остается только на собеседовании честно признаться что про опыт соврали чтобы пройти мимо hr и обсудить какие есть варианты получить работу -- так тоже ок.

Вот где обитают leading data processing компании

#кейсы #ML

Следующее собеседование было с девушкой, на лида, пара этапов прошли хорошо, кандидат это понимает,чувствует себя уверенно 😎, и вот идет знакомство c PO, оно у нас в присутствии HR (позиция все же руководящая).

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

Попросил вспомнить ситуацию когда на работе пришлось столкнуться с каким-нибудь сложным технически случаем – чего-то не получалось или не работало как надо, или метрика никак не росла и т.д. (кандидат вроде работала DSом пару-тройку лет судя по резюме).

Диалог получился коротким:
“– Ну один раз надо было семь моделей в пром задеплоить в короткий срок
-- А сложность в чем?
– Ну работать надо было много”. 😂😂😂
После такого ответа и PO и HR как-то резко расхотели ее брать, но пробуем спасти положение:
“– Что, никогда никаких сложностей другого плана не было?
– да все гуглится за 5 минут”.

Результат немного предсказуем.
Действительно, если не пробовать новое, а брать готовые фичи и готовый пайп обучения с вшитыми моделями, не обновлять библиотеки, не участвовать в соревнованиях, не пробовать новые фичи, не менять размер выборки, просто копать картошку – наверное, и правда, годами можно делать одно и то же.
Или просто рядом был кто-то, кто эти проблемы решал? 🤔

#кейсы #ML

Кстати про технические сложности
Вспомнился старый кейс, где я вовсю ощутил свой недостаток образования в Computer Science.

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

Разработка на C/ С++ это вот ни разу не python или Matlab (мой основной иснтрумент тогда), и я в нее не умел (о чем честно сказал на входе). А задачи были – писать модули для той большой системы, и на старте мне дали достаточно простые – одноканальная обработка сигналов, всякие фильтрации/свертки, немного со спектрами и кепстрами.

И как-то мне нужно было пройтись по спектру с шагом 0.1 Гц, что-то сделать, а затем к результату применить обратное Фурье. Только вот не всегда результат обратного преобразования Фурье будет вещественнозначным ) Поэтому делать надо было аккуратно, с первого раза в C не получилось. Списав все на свои кривые руки, решил сделать в матлабе. И там волшебным образом все заработало!

Несколько дней я потратил, пытаясь добиться того же результата в C – без шанса 🙈🤯.
В матлабе же не только индексация массивов отличается)
В итоге пошел на поклон к синьору и тут вскрылся мой недостаток образования на тот момент в CS. Что-то о свойствах вещественных чисел я знал (что на равенство сравнивать нельзя, ибо хранятся они в некотором приближении), но вот глубоко не копал – на чем и погорел.

В чем же была проблема?
Как это выглядело в Matlab:

d = 0;
for i = 1:10000
    d = d + 0.1;
end
fprintf('%.25f', d)
>>> 1000.0000000001588205122970976

Аналогично на python:

d = 0
for i in range(10_000):
    d += 0.1
print(d)
>>> 1000.0000000001588

И вот то же самое (на самом деле нет) на C:

  
   float d = 0;
   for (int i = 0; i < 10000; ++i)
   {
       d += 0.1;
   }
   printf("%.6f", d);
>>> 999.902893

Дело было в том что 0.1 в двоичном виде непредставима как конечная дробь, только как периодическая. А с ограничением точности (float против double, который по умолчанию в python) при суммировании ошибка накопилась и достигла настолько существенных величин, что обратное Фурье становилось комплексным 😱.

PS как-то у коллеги видел очень похожую ситуацию в python (только там он при чтении из файла во float сохранил), уже в 16м, подсказал – помогло.
А копать с тех пор стараюсь поглубже 🪆

#ML

в соседнем канале в качестве решения кейса предложили Kahan summation algorithm, интересная штука

#корпжиза

Очередной собес на лида, или как не стать лидом из синьора

На одном из крупных продуктов жил-был CDO, который хороводил и DS и аналитиков и DE. И в подмогу нужен был молодой лид / вчерашний синьор, который мог бы потихоньку начать разгружать 🤝. Ставка была лидовская, но рассматривали и синьоров, ибо CDO готов был вложиться в развитие.

И вот после пары этапов приходят HR что нужно подключиться на финальный собес с CDO, ибо есть у участников процесса сомнения “по его софтам”, что бы это ни значило. Как всегда на финальном собеседовании с лидами HR с нами, во встречу вложено резюме, глаз цепляется за “в подчинении команда из 2-х Junior DS” 🤴, ну ладно, мб формулировка неудачная.

Итак, цель встречи – понять, насколько кандидат самостоятелен сам и насколько способен организовать команду. За тройку месяцев до этого кандидат собесился к нам на синьора, но в процессе передумал и заявил HR что “рассматривает минимум позицию тимлида”. Ну ок, как раз позиция лида открылась.
.
Начинаем общаться с кандидатом и выясняем что “каждое утро я докладываю начальнику чем сегодня я и подчиненные DS будут заниматься и что сделали вчера, получаю новые вводные” 🤓.
Пытаемся выяснить все же какие решения принимал сам кандидат. Свелось к посещаемости офиса (можно отпустить сотрудника на конференцию на день если сам за него готов в случае чего эту задачу закрыть). Пытаемся выяснить как общение с заказчиком происходит, как со смежниками – ответ расстраивает. Какие планы расти на текущем месте? “-- Спрошу начальника…”.
Видно, собеседование не клеится, кандидатм расстраивается, нам тоже обидно, ну да ладно 😔. Даем какой-никакой фидбек (хоть и не просили), но лучше взять самостоятельного синьора чем несамостоятельного лида.

Так вот, кроме как уметь в problem solving, руководителю надо уметь быть самостоятельным (еще это называется лидерской позицией) – то есть иметь свою полноценную зону ответственности, свой план развития не только по карьере в целом, но и на конкретной позиции в конкретной компании, иметь план развития своего подразделения – куда мы идем, зачем, как выглядит успех.

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

[пафос on] Менеджмент начинается с себя. [\пафос off]

PS А может это особеность культуры? 🤔 Хотеть аппрувов и бояться ответсвенности.

Мой хороший друг несколько лет назад переехал в другую страну на аналитика в компанию, которая публикует аналитические отчеты.
Когда он написал свой первый отчет -- тоже принес начальнику на проверку. Босс посмотрел на него и говорит -- "Ты уверен в своем отчете? если уверен -- публикуй от лица компании, а не уверен -- зачем ты мне его принес?".

#корпжиза

По мотивам обсуждения в прошлом посте -- статья из HBR 2004 1974 года менеджер и его время (которая про обезьянку)

#кейсы #ML

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

Когда опубликовали идею attention, ее сразу же начали пытаться добавлять всюду – и стороной не обошли и графовые свертки.

Итак, 30 октября на архив выкладывают короткую статью Graph Attention Networks. Все бы ничего, но в авторах есть сам великий Yoshua Bengio 🥸!!!

И реализацию статьи добавляют в прекрасный Pytorch Geometric под именем GATConv.

Все бы ничего, но работает эта штука не то чтобы очень.
А все почему? Attention реализовали в виде линейного слоя после линейного слоя 😆😆😆😆. Да, без нелинейности между ними 😂😂😂 А чему учат на первом занятии по DL? Тому что два линейных слоя подряд – снова линейный слой!

Лишь спустя 4 😱 года — в 2021 — на архив выкладывают статью с аккуратным названием How Attentive are Graph Attention Networks?, где ни в коем случае не утверждается что мэтр с командой ошиблись.

Только посмотрите на образец дипломатичной формулировки:

However, in this paper we show that GAT computes a very limited kind of attention: the ranking of the attention scores is unconditioned on the query node. We formally define this restricted kind of attention as static attention and distinguish it from a strictly more expressive dynamic attention

Опытные ребята! 🏆

Исправленную графовую свертку с вниманием назвали не мудрствуя лукаво GATv2Conv. 😄

И если на собесе забудете формулу KQV-attention (которое self), расскажите эту историю про другой механизм реализации идеи внимания, посмеетесь вместе с интервьюером 😁

Статьи про типичные ошибки в DS / ML реально такие

Даже не знаю как такие вакансии комментировать ...

Что мы ожидаем:
✅ Готовность работать в офисе, в СПб.
✅ Опыт работы с AI и глубоким обучением, понимание основ NLP, CV, ASR или TTS.
✅ Уверенные навыки работы с TensorFlow или PyTorch.
✅ Знание C++, Java, Scala и методов параллельных вычислений (CUDA, MPI).
✅ Английский на уровне для работы с документацией и общения.
✅ Приветствуется опыт в крупных технологических компаниях или участие в исследовательских проектах.

AI engineer
200 000 – 800 000 ₽/месяц
Офис, Фултайм

Ищем опытного специалиста в области AI и Machine Learning для работы над передовыми технологиями в области крупных языковых моделей, оптимизации и ускорения вычислений…(читать далее)

#кейсы #ML

Все же самостоятельность и ответственность не нужно путать с безнадзорностью 🤡

Очередное собеседование на лида
Приходит парень – уверенно держится 😎, лидит команду из 5-6 человек в мелкой конторке, делают скоринги (вроде в мфо или для мфо – в общем что-то такое).

Тогда еще не было выстроено какого-то процесса, в общем, это первое собеседование у кандидата в наш департамент.
И речь заходит про саму задачу, как модель используется в процессе, куда они с командой развиваются, как делают модели и такое всякое.
У лидов распространенная тактика на собеседованиях – уходить от технических вопросов, переходя в агрессивное наступление с тезисом а-ля “ты что сам не знаешь как модели строить? Зачем об этом говорить?” 😤 и выворачивая диалог в какую-то актуальную и потенциально выгодную себе сторону. Кто-то это делает наоборт по-панибратски, типо с подимигиванием "ну мы же тут начальнички над землекопами, чего нам в этом хламе ковыряться" 😉.

И вот здесь я услышал незабываемое “я ж не колхозник какой, по одной статье в неделю читаю и мы все внедряем” 🤔🙈.

Далее следует совсем нетарантиновский диалог:

– Реализация какой статьи дала наибольший эффект в вашей задаче?
– Название не помню, но мы фото заемщика добавили в модель и получили +5 Gini
– У вас же бустинги?
– Ну да, добавляет же.
– Мб вы какие-то свертки делали?
– Нет, мы взяли готовую сетку и ее добавили в бустинг.
– Предикты от нее?
– Ну да
– А на что учили?
– На тот же таргет
– А на что были в итоге похожи обученные фильтры? (мне прям дико было интересно что выучила модель – мб там на фото дефолтников вообще лиц не было?)
– Чо? Она джини добавляет, что непонятного?

В этот момент мне стало очень жаль ребят, которых он лидит 🥺🤯.

Поэтому внешний ассессмент действительно очень-очень важен – выступайте на митапах и конференциях, получайте развивающий фидбек, спршивайте в профильных чатах (а их буквально по одному на каждую задачу – например, @ods_recommender_systems, @speech_recognition_ru и пр.), участвуйте в разных проектах в разных командах.
Здесь конечно удобнее и приятнее быть в большой компании – и больше шансов эксперта найти, и больше шансов на ротацию.

Но, в конце концов, мы не на необитаемом острове 🏝 живем, чего-то не знать – не зазорно, зазорно – не спросить.

#кейсы #корпжиза

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

Верно, речь пойдет про аналитиков

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

Много было вопросов по кейсам, но особенно живой интерес возник когда я сказал что аналитики им не нужны – мол, все равно вы не умеете ими пользоваться – что поделать, люблю чуть-чуть набросить 🤓.

Как я вижу работу дата-аналитика:
▪️ дизайн экспериментов / пост-эксперименты (блокинг, матчинг, каузальные выводы)
▪️ кейс-менеджмент
▪️ построение дерева метрик, исследование взаимного влияния метрик друг на друга
▪️ поиск прокси-метрик и прокси-событий
▪️ фин. модели для отмахивания от финансистов и аудиторов

Истории с прототипированием витрин, проверками данных, визуализации, первичную бизнес-валидацию – оставляю за DS, это обязательная и очень большая часть его работы

Истории с сегментацией / кластеризацией клиентской базы – свое отношение к таким “задачам” я в одном из первых постов высказал.

Как чаще всего используют аналитиков в компаниях, в которых продуктовая культура, скажем так, не особенно вызрела?
▪️ черная работа, которую не хочет делать DS / MLE / PO и остальные.
▪️ ad-hoc по велению левой пятки PO / CPO / любого другого манагера / канальи из соседнего отдела / управления / блока / департамента и пр. И суету создает и ЧСВ манагера растит.

И вот последнее отнимает 90-95% времени аналитиков.
Как с этим бороться? Обычно просто частотные запросы оформляют в дэш и берут на поддержку.
Еще были попытки text2sql, но тогда контекста моделей не хватало (да ис. бизнес-глоссариями было не так ровно как хотелось бы)

А как еще? (здесь каюсь, хорошая мысля приходит опосля – хоть я и боролся с ad-hoc, формализовать догадался только лишь потом):
▪️ Требовать дерево решений: вот насчитаю вам, уважаемый заказчик, требуемые показатели. Какие управленческие решения при каких значениях показателей вы сможете принять? Или просто посмотрите и огорчитесь?
▪️ Выдавать доступы к песочницам почти всем – дать им в руки BI с конструктором

Достаточно долго я так жил и работал, пока не так давно не возник следующий диалог с камрадом:
“
– Вы сколько на моделях в этом крупном направлении за год заработали?
– Ну, xxx млн.
– А у нас (компания Y) аналитики (!) за месяц столько же
– ???
“

Итак, суть кейса:
аналитики как обычно генерили свои смешные гипотезы, и в результате проверки одной из них выяснилось следующее: пару лет назад компания Y привлекала клиентов, предлагая им трехмесячную скидку. Аналитики выяснили что разрабы накосячили и скидки не отключились через 3 мес (!). То есть все такие клиенты до сих получают услуги по тем льготным тарифам. Дальше они взяли скоры от модели оттока и начали самым лояльным по этим скорам скидку отменять. Потихоньку, не сразу все базу.

Конечно, без DS они не обошлись (модель оттока все-таки наша), но сам факт!
В итоге мнение о дата-аналитиках и их полезности я сильно поменял. ☺️

Если у вас прикольные кейсы файндингов дата-аналитиков -- не держите в себе, поделитесь, пожалуйста в комментариях

ого, сегодня разоблачили крупную организацию каналий-иллюминатов-разрабов. Хм, что если все мои истории не случайны, и в DS/ ML она тоже есть? 🤔

PS: isDisabled() напомнило про криворуких проектировщиков таблиц с клиентами, которые заводят колонки "sex" или "gender" а потом ты гадаешь что значат {-1; 0; 1; 2}.
Крайне редко увидишь нормальное название -- is_male

#кейсы #ML

Не могу не согласиться с автором вчерашней статьи, которую цитировал в посте в том что такая организация существует.
И вот эта картинка из нее – главная улика.

Встречали когда-нибудь в python ровно 8 😵 вложенных циклов for?

А мы с товарищем пару лет назад встретили 😆 Питонист, который не слышал про itertools.product это ж мистер Джон Ланкастер Пек.

А лет за пять до этого я реально встретил результат саботажа от такого же агента.
Искал я в одной из систем Transact SM Retail – для любознательных и знающих о какой компании речь – табличку с родственниками заемщиков.
Ничего не предвещало беды и таблица такая была – называлась Relatives.

Поля вот только в ней назывались:

r268
r348
r6025
r452
…

И даже это не было страшно, ибо под рукой была расшифровка в excel (о нем мы еще поговорим), и там было прекрасное:

r268: dob родственника 1
r348: имя родственника 1
r6025: фамилия родственника 1
r452: отчество родственника 1
…  
...
r281: имя родственника 14
r361: name of relative 14
r6038: фамилия родственника 14
r464: отчество родственника14

За номера в названиях колонок могу путаться, но описание именно такое

Да-да, 56 полей для 14 родственников, по каждому из которых хранится максимум 4 значения – и это если кто-то в анкете на кредит всех 14 указал (такие правда были, не знаю как фамилии в текстовое поле влезли правда).

Такой подход к формам нормализации оставил неизгладимое впечатление конечно.

И только сейчас я понял в чем же было дело …

#корпжиза
Наброс-вопрос про DS в “продуктовых компаниях”.
Буду осознанно сгущать краски, представим что мир черно-белый

Никогда не понимал вот это вот “продуктовая компания”, “все является продуктом” (реально скрам уже в бухгалтерию внедрили) и как в этом всем должен работать и развиваться DS, строить карьеру, расти в ML. Это же анекдот – знания DS получают на каггле, при подготовке к собеседованиям и на халтурках (когда сам с нуля за мелкий прайс).
Вообще кстати на фразу “относись к продукту как к своему бизнесу” реагирую просто – participation in success есть? Нет? Ну тогда уже бегу, ага. Но сейчас все же про DS

Особенно часто DS работает где-нибудь в change, по условному scrum – там где много унижений и микроменеджмента (чего только ежедневные стендапы стоят – привет, столыпинский вагон; только представьте чтобы совет директоров или правление стоя совещалось – и почасовые оценки задач грумингом), а на выходе минимум 20% времени команды уходит на всякие “церемонии”, фасилитаторов и на переключение между встречами. Хотя и без меня на эту тему написано прилично

И вот бесконечный бег, который поделен на “спринты” и “супер-спринты” – фичу за фичей. А чтобы получить промоушен надо решить технически сложную задачу!
Погодите, а разве развитие продукта не про максимально эффективные решения? Типа вместо двух моделей сделаем одну, вместо модели сделаем бизнес-правило и пр. – если метрики на A/B почти одинаковые? Не каждое стат. значимое изменение метрики приводит к росту прибыли – и вроде как задача продакта вести хозяйство разумно. А что если в продукте нет сложных ML-задач? То есть ты делаешь все супер, но задачи “недостаточно сложные” чтобы тебя повысить?

И другой поинт – если ты живешь спринтами и задачами по 4 часа что ты там сложное решишь?

Явно такие мысли не только у меня – от мотивированных именно на ML стажеров и кандидатов частый запрос – а можно куда-нибудь в RnD? И не то чтобы эти ребята мечтают о карьере академиков и писать статьи, им просто не в кайф быть крысой в колесе.

И их можно понять.
Особенно когда они выгорают, а им предлагают максимум “ротацию” в аналогичного уровня сложности продукт – то есть шило на мыло. (Хотя инструмент ротации я очень люблю – он позволяет создавать конкуренцию между продактами за DS и работает на повышение окладов)

Где-то слышал (мб вранье) что скрам придумали для бадишопов – чтобы клиенты получали иллюзию максимального контроля за своими деньгами.

Еще стоит подумать что бывает когда продукт закрывают как неперспективный. Увольняться из компании? А если компания нравится?

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

Свой ответ напишу в сл посте

Если кто знает правильный ответ -- велкам в каменты