#кейсы #ML
Первое знакомство с накручивателем опыта было забавным и поучительным.
Это был парень, который в резюме указал что строил модели комплаенс.
После "привет, меня зовут юзернейм", вместо короткого интро, он сходу начал рассказывать стишок 🤥 как он модели AML делал, называя разные ключевые слова вроде "использовал sklearn и xgboost", как он пользовался гитом и ставил все на “расписание в apache airflow”.
Собственно, я и взял это собеседование, ибо в резюме было ООО “Ромашка” 🌼и комплаенс – думаю, прикольно, бизнес на этом делают, мб узнаю нового 🍿 .
Как и в любом кейсе я спросил что именно моделировали – что было целевой переменной и объектом моделирования. Парень начал агриться и сказал про фродовые транзакции. Фрод задача другая (совсем не AML) и я попросил привести пример такой вот фродовой транзакции или рассказать откуда у него разметка.
Кандидат в качестве примера привел попадание компании в санкционные списки (тоже не AML, с натяжкой мб ФТ).
Я переспросил – транзакция в адрес компании из санкционного списка? А зачем тогда модель? Можно просто по справочнику определить такие.
Тут парень откровенно поплыл, уходя от вопроса во все стороны сразу (хотя схем обнала десятки если не сотни). На вопрос про фичи -- то же самое. Так мы и не выяснили что в итоге моделировалось 😵
Решил добить контрольным – спросил про код 6001 и Росфинмониторинг 😆
Мораль истории проста – если накручиваете опыт – не берите специфический кейс, где доменные знания будут очень влиять на построение модели. Берите массовые кейсы – какие-н продажи, рекламные рассылки и пр. Что-то чем реально может заниматься небольшая неизвестная компания (если большая и известная то скорее всего у собеседующего по закону подлости будут знакомые именно в том отделе, который вы вписали).
Если уж накручиваете – вывезите в бар 🍺🍺 товарища и замучайте его вопросами про каждый шаг в кейсе. Тщательно запишите и потом еще раз загуглите каждый термин и саму задачу. Задавайте вопросы из поста выше -- почему решили так а не эдак, как собирали таргет и фичи и тд. При необходимости – повторить, начиная с выбора кейса. Затем поищите в кагле или каком-нибудт открытом курсе похожую задачу и попробуйте закодить решение. Если все-таки нашли на кагле -- посмотрите публичные ноутбуки, как ее решают. Подумайте над тем как найденное решение будет вести себя во времени, если его в прод поставить. Как вы это бедете делать, как мониторить и какие метрики / показатели. Спросите в дружественном DS-чате, мб у кого-то был похожий кейс.
Если не заботали – остается только на собеседовании честно признаться что про опыт соврали чтобы пройти мимо hr и обсудить какие есть варианты получить работу -- так тоже ок.
Первое знакомство с накручивателем опыта было забавным и поучительным.
Это был парень, который в резюме указал что строил модели комплаенс.
После "привет, меня зовут юзернейм", вместо короткого интро, он сходу начал рассказывать стишок 🤥 как он модели AML делал, называя разные ключевые слова вроде "использовал sklearn и xgboost", как он пользовался гитом и ставил все на “расписание в apache airflow”.
Собственно, я и взял это собеседование, ибо в резюме было ООО “Ромашка” 🌼и комплаенс – думаю, прикольно, бизнес на этом делают, мб узнаю нового 🍿 .
Как и в любом кейсе я спросил что именно моделировали – что было целевой переменной и объектом моделирования. Парень начал агриться и сказал про фродовые транзакции. Фрод задача другая (совсем не AML) и я попросил привести пример такой вот фродовой транзакции или рассказать откуда у него разметка.
Кандидат в качестве примера привел попадание компании в санкционные списки (тоже не AML, с натяжкой мб ФТ).
Я переспросил – транзакция в адрес компании из санкционного списка? А зачем тогда модель? Можно просто по справочнику определить такие.
Тут парень откровенно поплыл, уходя от вопроса во все стороны сразу (хотя схем обнала десятки если не сотни). На вопрос про фичи -- то же самое. Так мы и не выяснили что в итоге моделировалось 😵
Решил добить контрольным – спросил про код 6001 и Росфинмониторинг 😆
Мораль истории проста – если накручиваете опыт – не берите специфический кейс, где доменные знания будут очень влиять на построение модели. Берите массовые кейсы – какие-н продажи, рекламные рассылки и пр. Что-то чем реально может заниматься небольшая неизвестная компания (если большая и известная то скорее всего у собеседующего по закону подлости будут знакомые именно в том отделе, который вы вписали).
Если уж накручиваете – вывезите в бар 🍺🍺 товарища и замучайте его вопросами про каждый шаг в кейсе. Тщательно запишите и потом еще раз загуглите каждый термин и саму задачу. Задавайте вопросы из поста выше -- почему решили так а не эдак, как собирали таргет и фичи и тд. При необходимости – повторить, начиная с выбора кейса. Затем поищите в кагле или каком-нибудт открытом курсе похожую задачу и попробуйте закодить решение. Если все-таки нашли на кагле -- посмотрите публичные ноутбуки, как ее решают. Подумайте над тем как найденное решение будет вести себя во времени, если его в прод поставить. Как вы это бедете делать, как мониторить и какие метрики / показатели. Спросите в дружественном DS-чате, мб у кого-то был похожий кейс.
Если не заботали – остается только на собеседовании честно признаться что про опыт соврали чтобы пройти мимо hr и обсудить какие есть варианты получить работу -- так тоже ок.