#interview #advice
Какой процесс собеседования мне кажется адекватным? (часть 1)
Начну с того, что собеседования проводят кто во что горазд. Это сложно, причем все сложнее с ростом уровня кандидата. Оттого и получаются очень полярные истории от "поговорить по душам" до "экзамен по олимпиадным задачкам".
Сам я больше склоняюсь к "поговорить по душам", но задачи в том или ином виде приходится задавать, чтобы срезать тех, кто совсем ничего не может сформулировать по итогам задачи.
Какие основные темы, которые обычно спрашивают на собеседованиях (и я в том числе):
1. Прикладная статистика. Сюда же можно отнести и вопросы на теорию, задачки на тервер и статистику. Очень не люблю задачки на какие-то формулы в этой секции, куда более подходящим считаю копать в сторону опыта (или интуиции при отсутствии такого) в области прикладной статистики, к примеру, попросив описать, как проводятся A/B тесты, почему стоит разбивать группы так, а не иначе, почему используются такие тесты и какие могут быть подводные камни;
2. Python, другие языки и технологии. Т.к., де-факто Python является наиболее частым в области анализа данных (но, конечно, кто-то может использовать R, для computer vision будет важен C++, а дата-инженерам может быть важнее Java или Scala), то обычно его и спрашивают.
Здесь задачку считаю куда более уместной, но задачу не очень высокого уровня, которая просто отсекает совсем плохо сведущих в языке. Задачи на live-кодинг, в принципе, дать можно, но если это что-то сложное, то отнимет слишком много времени. Ну и не все кандидаты могут без нервов решить сложную задачу на кодинг на время, еще и перед глазами интервьюера. Потому считаю вполне допустимым либо давать задачи попроще, либо позволять гуглить, но давать более размытую постановку. Умение гуглить очень важно в работе, так что глупо считать, что у кандидата должно быть все в памяти, а решать он должен задачки на кручение деревьев и выдумывание сортировок. Умный кандидат таким заниматься не будет (если только не собирается в FAANG, но то другая история, они могут позволить себе куда больше обычного места), а дурак вызубрит.
Про технологии лучше общаться в виде обсуждения. Можно на ситуации, можно просто с вопросами, что и как делалось в каком-либо проекте у кандидата.
Если есть github или аналог - то совсем круто. Я их обычно просматриваю, т.к. сразу можно видеть какие-т примеры работ. Но наличие github обязательным не считаю, т.к. это скорее история про хобби, а не про работу.
3. SQL, классическая аналитика. Здесь уместна простая задачка, чтобы понять, что там с SQL. Но т.к. это очень быстро учится, смысла сильно карать за это нет. Вопросы про внутренности каких-либо СУБД считаю странными, если только у кандидата не написано, что он профи в одной из них. Но общие вопросы SQL/NoSQL, звезду/снежинку можно задать, чтобы оценить уровень кругозора.
По аналитике можно смоделировать ситуацию и спросить, что же кандидат будет делать в ней. Либо можно попросить визуализировать набор данных (хотя бы указать, какой тип визуализации использовался бы). Отчасти это совмещается с вопросами про статистику, так что можно сделать переход от секции к секции.
4. ML/DL. Здесь больше люблю задавать вопросы про проекты кандидата с последующим уходом вглубь технической реализации, выбора метрик и прочего. Еще люблю открытую постановку кейса с таким же постепенным усложнением.
Вопросы, в стиле "вспомни формулу функционала оптимизации для такой-то задачки" считаю избыточными, т.к. помнить такое будут либо свежие выпускники, либо кто-то, кому повезло недавно на это наткнуться.
А вот вопросы на метрики и их выбор куда более уместны. Все же правильно поставленный вопрос - большая часть ответа. Так вот и правильные метрики - весьма важная часть ML решения.
По DL только общие вопросы, но это не моя специализация. В основном, на понимание разных архитектур, подводные камни тех или иных решений.
5. BigData (опционально).
Какой процесс собеседования мне кажется адекватным? (часть 1)
Начну с того, что собеседования проводят кто во что горазд. Это сложно, причем все сложнее с ростом уровня кандидата. Оттого и получаются очень полярные истории от "поговорить по душам" до "экзамен по олимпиадным задачкам".
Сам я больше склоняюсь к "поговорить по душам", но задачи в том или ином виде приходится задавать, чтобы срезать тех, кто совсем ничего не может сформулировать по итогам задачи.
Какие основные темы, которые обычно спрашивают на собеседованиях (и я в том числе):
1. Прикладная статистика. Сюда же можно отнести и вопросы на теорию, задачки на тервер и статистику. Очень не люблю задачки на какие-то формулы в этой секции, куда более подходящим считаю копать в сторону опыта (или интуиции при отсутствии такого) в области прикладной статистики, к примеру, попросив описать, как проводятся A/B тесты, почему стоит разбивать группы так, а не иначе, почему используются такие тесты и какие могут быть подводные камни;
2. Python, другие языки и технологии. Т.к., де-факто Python является наиболее частым в области анализа данных (но, конечно, кто-то может использовать R, для computer vision будет важен C++, а дата-инженерам может быть важнее Java или Scala), то обычно его и спрашивают.
Здесь задачку считаю куда более уместной, но задачу не очень высокого уровня, которая просто отсекает совсем плохо сведущих в языке. Задачи на live-кодинг, в принципе, дать можно, но если это что-то сложное, то отнимет слишком много времени. Ну и не все кандидаты могут без нервов решить сложную задачу на кодинг на время, еще и перед глазами интервьюера. Потому считаю вполне допустимым либо давать задачи попроще, либо позволять гуглить, но давать более размытую постановку. Умение гуглить очень важно в работе, так что глупо считать, что у кандидата должно быть все в памяти, а решать он должен задачки на кручение деревьев и выдумывание сортировок. Умный кандидат таким заниматься не будет (если только не собирается в FAANG, но то другая история, они могут позволить себе куда больше обычного места), а дурак вызубрит.
Про технологии лучше общаться в виде обсуждения. Можно на ситуации, можно просто с вопросами, что и как делалось в каком-либо проекте у кандидата.
Если есть github или аналог - то совсем круто. Я их обычно просматриваю, т.к. сразу можно видеть какие-т примеры работ. Но наличие github обязательным не считаю, т.к. это скорее история про хобби, а не про работу.
3. SQL, классическая аналитика. Здесь уместна простая задачка, чтобы понять, что там с SQL. Но т.к. это очень быстро учится, смысла сильно карать за это нет. Вопросы про внутренности каких-либо СУБД считаю странными, если только у кандидата не написано, что он профи в одной из них. Но общие вопросы SQL/NoSQL, звезду/снежинку можно задать, чтобы оценить уровень кругозора.
По аналитике можно смоделировать ситуацию и спросить, что же кандидат будет делать в ней. Либо можно попросить визуализировать набор данных (хотя бы указать, какой тип визуализации использовался бы). Отчасти это совмещается с вопросами про статистику, так что можно сделать переход от секции к секции.
4. ML/DL. Здесь больше люблю задавать вопросы про проекты кандидата с последующим уходом вглубь технической реализации, выбора метрик и прочего. Еще люблю открытую постановку кейса с таким же постепенным усложнением.
Вопросы, в стиле "вспомни формулу функционала оптимизации для такой-то задачки" считаю избыточными, т.к. помнить такое будут либо свежие выпускники, либо кто-то, кому повезло недавно на это наткнуться.
А вот вопросы на метрики и их выбор куда более уместны. Все же правильно поставленный вопрос - большая часть ответа. Так вот и правильные метрики - весьма важная часть ML решения.
По DL только общие вопросы, но это не моя специализация. В основном, на понимание разных архитектур, подводные камни тех или иных решений.
5. BigData (опционально).
👍1
#interview
Можно ли использовать линейную функцию активации между слоями полносвязной нейронной сети? Почему это имеет или не имеет смысла?
1. Конечно, ничего не мешает использовать сколько угодно слоев подряд с линейными активациями. Но тут есть одно "но";
2. Если мы составим несколько полносвязных слоев и линейные активации, то получим просто линейную комбинацию линейных функций. А это значит, что наши несколько слоев будут эквивалентны одному слою. Получаем бессмысленное нагромождение слоев, которые успешно заменяет обычный линейный перцептрон.
Можно ли использовать линейную функцию активации между слоями полносвязной нейронной сети? Почему это имеет или не имеет смысла?
1. Конечно, ничего не мешает использовать сколько угодно слоев подряд с линейными активациями. Но тут есть одно "но";
2. Если мы составим несколько полносвязных слоев и линейные активации, то получим просто линейную комбинацию линейных функций. А это значит, что наши несколько слоев будут эквивалентны одному слою. Получаем бессмысленное нагромождение слоев, которые успешно заменяет обычный линейный перцептрон.
Forwarded from эйай ньюз
Корейцы из Naver Lab взялись переразмечать самый популярный в компьютер вижне датасет ImageNet. Примечательно, что делают это они с помощью нейросети натренированной на еще больших датасетах типо InstagramNet-1B (миллиард инста-фоточек).
Казалось бы, а толку тогда от такой разметки, если это все равно предсказания алгоритма, но не тут то было, оказалось толк есть. ResNet-50 натренированная на новой разметке показала точность на 1.4% (процентных пункта) выше, чем она же натренированная на оригинальном ImageNet.
Будь я журналистом, написал бы что это конец, нейросети обучают нейросети и готовятся порабощать человечество, но я, конечно же, так делать не буду.
Казалось бы, а толку тогда от такой разметки, если это все равно предсказания алгоритма, но не тут то было, оказалось толк есть. ResNet-50 натренированная на новой разметке показала точность на 1.4% (процентных пункта) выше, чем она же натренированная на оригинальном ImageNet.
Будь я журналистом, написал бы что это конец, нейросети обучают нейросети и готовятся порабощать человечество, но я, конечно же, так делать не буду.
#interview #advice
Какой процесс собеседования мне кажется адекватным? (часть 2)
В прошлой части я написал, какие обычно бывают секции вопросов на собеседовании. Теперь опишу примерную последовательность общения с кандидатом (пункты могут меняться местами, в зависимости от того, какой опыт у кандидата):
0. Если есть код/записи выступлений/ссылка на блог в резюме - то смотрю их до собеседования;
1. Вводный рассказ о вакансии и компании. Тогда же обговаривается план собеседования;
2. Рассказ кандидата о себе с промежуточными уточнениями по задачам, которые кандидат решал. Если какие-то пункты кандидат сразу хорошо рассказывает (к примеру, сразу рассказывает про проведение A/B тестов у них в компании так, что нет смысла повторно обсуждать);
3. Одна-две простых задачи на Python/SQL, вопросы про кодинг и БД;
4. Вопросы про A/B тестирование, статистику. Можно добавить вопрос про "объясните результат/понятие менеджеру";
5. ML секция в виде достаточно размытой постановки задачи "от менеджера". Задается вопрос, к примеру: "мы хотим возвращать пользователей в продукт посредством персональных рекомендаций покупок и рассылки спецпредложения". Далее идет общение по задаче.
Тут, обычно, ожидаются (и заранее предлагаются) дополнительные уточняющие вопросы, т.к. постановка максимально общая. Общими усилиями с "менеджером" прорабатывается концепция решения. Такой подход позволяет оценить и навыки общения (что спросит и как), и технические навыки (на что обратит внимание и как спроектирует решение). А так же позволяет уходить в глубь по разным фронтам (больше в ML, больше в техническую реализацию, либо в общение).
6. Подводятся итоги, ответы на вопросы кандидата;
7. Опционально можно дать тестовое задание. Я их не люблю, но если поток кандидатов большой, а вакансия предполагает уровень джун/миддл, то тестовое может быть неплохим решением;
8. Если все ок, то отзыв проходит дальше и кандидат идет на следующий этап - общение с руководством.
Такой подход неплохо позволяет фильтровать джунов/миддлов. С сеньорами история более специфичная и требует отдельного поста.
Какой процесс собеседования мне кажется адекватным? (часть 2)
В прошлой части я написал, какие обычно бывают секции вопросов на собеседовании. Теперь опишу примерную последовательность общения с кандидатом (пункты могут меняться местами, в зависимости от того, какой опыт у кандидата):
0. Если есть код/записи выступлений/ссылка на блог в резюме - то смотрю их до собеседования;
1. Вводный рассказ о вакансии и компании. Тогда же обговаривается план собеседования;
2. Рассказ кандидата о себе с промежуточными уточнениями по задачам, которые кандидат решал. Если какие-то пункты кандидат сразу хорошо рассказывает (к примеру, сразу рассказывает про проведение A/B тестов у них в компании так, что нет смысла повторно обсуждать);
3. Одна-две простых задачи на Python/SQL, вопросы про кодинг и БД;
4. Вопросы про A/B тестирование, статистику. Можно добавить вопрос про "объясните результат/понятие менеджеру";
5. ML секция в виде достаточно размытой постановки задачи "от менеджера". Задается вопрос, к примеру: "мы хотим возвращать пользователей в продукт посредством персональных рекомендаций покупок и рассылки спецпредложения". Далее идет общение по задаче.
Тут, обычно, ожидаются (и заранее предлагаются) дополнительные уточняющие вопросы, т.к. постановка максимально общая. Общими усилиями с "менеджером" прорабатывается концепция решения. Такой подход позволяет оценить и навыки общения (что спросит и как), и технические навыки (на что обратит внимание и как спроектирует решение). А так же позволяет уходить в глубь по разным фронтам (больше в ML, больше в техническую реализацию, либо в общение).
6. Подводятся итоги, ответы на вопросы кандидата;
7. Опционально можно дать тестовое задание. Я их не люблю, но если поток кандидатов большой, а вакансия предполагает уровень джун/миддл, то тестовое может быть неплохим решением;
8. Если все ок, то отзыв проходит дальше и кандидат идет на следующий этап - общение с руководством.
Такой подход неплохо позволяет фильтровать джунов/миддлов. С сеньорами история более специфичная и требует отдельного поста.
#interview
У нас есть два класса. Объекты первого лежат в 1 и 3 четвертях координатной плоскости. Второго - во 2 и 4 четвертях. Как нам их линейно разделить на классы?
Достаточно классическая задача. Но иногда ее любят спрашивать.
Напрямую нам их линейно не разделить, т.к. расположение объектов нам этого не позволяет. Соответственно, надо что-то придумать.
В данном случае, подойдет "трюк" с отображением в другое пространство, где классы были бы разделимы. Построим признак x * y, где x и y - координаты точек. Тогда все точки с положительным знаком произведения пойдут в один класс, а все точки с отрицательным - в другой класс. Что нам и требовалось сделать по условию задачи.
У нас есть два класса. Объекты первого лежат в 1 и 3 четвертях координатной плоскости. Второго - во 2 и 4 четвертях. Как нам их линейно разделить на классы?
Достаточно классическая задача. Но иногда ее любят спрашивать.
Напрямую нам их линейно не разделить, т.к. расположение объектов нам этого не позволяет. Соответственно, надо что-то придумать.
В данном случае, подойдет "трюк" с отображением в другое пространство, где классы были бы разделимы. Построим признак x * y, где x и y - координаты точек. Тогда все точки с положительным знаком произведения пойдут в один класс, а все точки с отрицательным - в другой класс. Что нам и требовалось сделать по условию задачи.
#advice #libraries
Как оказалось, японцы весьма специфично записывают год.
Если для нас это просто n-й год н.э., то у представителей страны восходящего солнца это n-й год эры такого-то императора. К примеру, сейчас идет эра Рейва, так что 2021 год будет Reiwa 3 (то есть 3й год эры Рейва).
Что с этим делать?
Я нашел библиотечку для парсинга года по японскому исчислению. Там возможен перевод с достаточно бородатых годов по нынешнее время. Если вдруг понадобится работать с данными в японском формате - используйте ее.
Как оказалось, японцы весьма специфично записывают год.
Если для нас это просто n-й год н.э., то у представителей страны восходящего солнца это n-й год эры такого-то императора. К примеру, сейчас идет эра Рейва, так что 2021 год будет Reiwa 3 (то есть 3й год эры Рейва).
Что с этим делать?
Я нашел библиотечку для парсинга года по японскому исчислению. Там возможен перевод с достаточно бородатых годов по нынешнее время. Если вдруг понадобится работать с данными в японском формате - используйте ее.
#management
Почему в data science командах плохо приживается scrum?
Провокационный заголовок, но я правда считаю, что в чистом виде scrum плохо приживается в data science командах. Какие-то смеси и вариации запустить можно, но все равно придется учитывать специфику.
А какая тут, собственно, специфика?
1. Очень сложно оценить заранее, сколько займет та или иная задача. Да, даже в майках/картах и т.п. Да, даже при неплохой декомпозиции задач. Т.к. достаточная часть задач являются исследовательскими, неопределенность в них зашкаливает. А при высокой неопределенности и оценки будут скакать;
2. Некоторые задачи могут перестать быть актуальными в середине спринта. К примеру, вы исследовали данные и поняли, что данных вам не хватает (и не хватит в ближайшее время). Сделали тикеты на доработку, успокоились. Но вот еще половина спринта осталась. То ли всегда брать больше задач (и часто проваливать спринт), то ли часто получать ситуацию, что команда отдыхает половину спринта. Нехорошо;
3. Тяжелый хвост для некоторых задач. Бывают случаи, когда задача вроде бы начинает решаться, работы идут. Но тут оказывается, что нужно исправлять разметку, править библиотечную реализацию, дорабатывать гипотезу и т.д. И такое случается гораздо чаще и с гораздо большей задержке, чем в разработке. Тогда задача начинает кочевать из спринта в спринт с переносами.
Учитывая особенности выше, частенько скрам об них разбивается. И тогда либо на что-то забивают и делают, как выйдет, либо колются дальше, народ негодует и потихоньку разбегается.
Как адаптироваться?
В принципе, неплохо подходят смешанные подходы, вроде скрамбана (https://ru.qaz.wiki/wiki/Scrumban). Может подойти использование канбана, но с учетом того, что у нас есть какой-то план релизов или предоставления артефактов. Но результат все равно придется под себя адаптировать.
Еще вариант - это помимо “сложности” задачи учитывать степень ее неопределенности. В таком случае, можно попробовать вставлять в спринт задачи не только на основе стори-поинтов, но и на основе уровня неопределенности задач. К примеру, если у нас есть задачи, плотно упаковывающиеся в спринт, но с высокой неопределенностью, то лучше понизить неопределенность за счет возможной недозагрузки спринта. Либо тасовать задачки таким образом, чтобы там точно набирался нужный процент “безрисковых” задач. Ну и абсолютно точно придется часто заново калибровать наши шкалы задач и степени неопределенности.
Почему в data science командах плохо приживается scrum?
Провокационный заголовок, но я правда считаю, что в чистом виде scrum плохо приживается в data science командах. Какие-то смеси и вариации запустить можно, но все равно придется учитывать специфику.
А какая тут, собственно, специфика?
1. Очень сложно оценить заранее, сколько займет та или иная задача. Да, даже в майках/картах и т.п. Да, даже при неплохой декомпозиции задач. Т.к. достаточная часть задач являются исследовательскими, неопределенность в них зашкаливает. А при высокой неопределенности и оценки будут скакать;
2. Некоторые задачи могут перестать быть актуальными в середине спринта. К примеру, вы исследовали данные и поняли, что данных вам не хватает (и не хватит в ближайшее время). Сделали тикеты на доработку, успокоились. Но вот еще половина спринта осталась. То ли всегда брать больше задач (и часто проваливать спринт), то ли часто получать ситуацию, что команда отдыхает половину спринта. Нехорошо;
3. Тяжелый хвост для некоторых задач. Бывают случаи, когда задача вроде бы начинает решаться, работы идут. Но тут оказывается, что нужно исправлять разметку, править библиотечную реализацию, дорабатывать гипотезу и т.д. И такое случается гораздо чаще и с гораздо большей задержке, чем в разработке. Тогда задача начинает кочевать из спринта в спринт с переносами.
Учитывая особенности выше, частенько скрам об них разбивается. И тогда либо на что-то забивают и делают, как выйдет, либо колются дальше, народ негодует и потихоньку разбегается.
Как адаптироваться?
В принципе, неплохо подходят смешанные подходы, вроде скрамбана (https://ru.qaz.wiki/wiki/Scrumban). Может подойти использование канбана, но с учетом того, что у нас есть какой-то план релизов или предоставления артефактов. Но результат все равно придется под себя адаптировать.
Еще вариант - это помимо “сложности” задачи учитывать степень ее неопределенности. В таком случае, можно попробовать вставлять в спринт задачи не только на основе стори-поинтов, но и на основе уровня неопределенности задач. К примеру, если у нас есть задачи, плотно упаковывающиеся в спринт, но с высокой неопределенностью, то лучше понизить неопределенность за счет возможной недозагрузки спринта. Либо тасовать задачки таким образом, чтобы там точно набирался нужный процент “безрисковых” задач. Ну и абсолютно точно придется часто заново калибровать наши шкалы задач и степени неопределенности.
#libraries
OSMNX - библиотека для получения данных о дорожных сетях из OSM. Можно указывать, какой город или полигон вас интересуют и получить дорожную сеть в виде графа и географической информации.
По полученным данным можно строить статистики на графе, искать кратчайший путь (не очень быстро из-за реализации), строить путь на карте.
В общем, очень удобный инструмент для работы с данными графов дорог. А главное - открытый.
OSMNX - библиотека для получения данных о дорожных сетях из OSM. Можно указывать, какой город или полигон вас интересуют и получить дорожную сеть в виде графа и географической информации.
По полученным данным можно строить статистики на графе, искать кратчайший путь (не очень быстро из-за реализации), строить путь на карте.
В общем, очень удобный инструмент для работы с данными графов дорог. А главное - открытый.
#competition
Почему участвовать в соревнованиях лучше командой?
На самом деле, ответ простой - распределение рисков. Если вы участвуете в одиночку, то призов получите больше, но и рисков будет пропорционально больше. Все оттого, что не всякий сможет тащить много активности в одно лицо.
Какие плюсы команды:
1. Больше мотивация. Если кто-то застопорился, то нежелание подвести товарищей может помочь продолжить “пилить”;
2. Перенос знаний. Каждый из нас лучше знает те или иные области. Чем больше людей - тем больше разных точек зрения, подходов, фишек. Особенно, если подобралась опытная компания;
3. Больше идей. В одиночку сложно штормить, а командой можно собираться каждую неделю и устраивать новый штурм по итогам недели;
4. Больше работы в единицу времени. Чем больше людей - тем больше можно сделать работы, тем больше проверить гипотез. Верно и обратное - чем больше людей, тем меньше работы для каждого из них. Соответственно, вероятность выгореть меньше (ну если вы только не тянете лямку за всю остальную команду, тогда шансы подгореть выше);
Какие минусы:
1. Выигрыш (при наличии такового) делится на всех. То есть денег на человека будет меньше;
2. Кому-то нужно организовывать команду и тратить время на коммуникацию. Если все суровые интроверты, то команде будет туго;
3. Если команда не сыграна, то могут быть конфликты. Кто-то решил отдохнуть вместо своей части, кто-то не согласен с “линией партии”, кто-то считает, что наработал на половину приза, а не на четверть. Все это ведет к конфликтам и может потопить команду.
В общем, я бы рекомендовал иметь на примете товарищей. Особенно, если хочется “зайти” сразу в несколько разных соревнований. В таком случае, у вас будет меньше шансов выгореть, а работа получится более дисциплинированной.
Почему участвовать в соревнованиях лучше командой?
На самом деле, ответ простой - распределение рисков. Если вы участвуете в одиночку, то призов получите больше, но и рисков будет пропорционально больше. Все оттого, что не всякий сможет тащить много активности в одно лицо.
Какие плюсы команды:
1. Больше мотивация. Если кто-то застопорился, то нежелание подвести товарищей может помочь продолжить “пилить”;
2. Перенос знаний. Каждый из нас лучше знает те или иные области. Чем больше людей - тем больше разных точек зрения, подходов, фишек. Особенно, если подобралась опытная компания;
3. Больше идей. В одиночку сложно штормить, а командой можно собираться каждую неделю и устраивать новый штурм по итогам недели;
4. Больше работы в единицу времени. Чем больше людей - тем больше можно сделать работы, тем больше проверить гипотез. Верно и обратное - чем больше людей, тем меньше работы для каждого из них. Соответственно, вероятность выгореть меньше (ну если вы только не тянете лямку за всю остальную команду, тогда шансы подгореть выше);
Какие минусы:
1. Выигрыш (при наличии такового) делится на всех. То есть денег на человека будет меньше;
2. Кому-то нужно организовывать команду и тратить время на коммуникацию. Если все суровые интроверты, то команде будет туго;
3. Если команда не сыграна, то могут быть конфликты. Кто-то решил отдохнуть вместо своей части, кто-то не согласен с “линией партии”, кто-то считает, что наработал на половину приза, а не на четверть. Все это ведет к конфликтам и может потопить команду.
В общем, я бы рекомендовал иметь на примете товарищей. Особенно, если хочется “зайти” сразу в несколько разных соревнований. В таком случае, у вас будет меньше шансов выгореть, а работа получится более дисциплинированной.
#interview #AB
Задача со страницы вакансий одной компании, название которой начинается на Y.
На прошедшей неделе в рекламной сети параллельно размещались два баннера. Оба баннера были показаны один миллион раз. Первый получил 10 000 кликов и 500 установок, а второй — 10 500 кликов и 440 установок. Маркетолог просит у вас совета: какой баннер оставить, а какой отключить. Что вы ему ответите? Обоснуйте свой ответ.
Тут идет первый вопрос - а что нам важнее? Установки или клики? Вопрос с подвохом, т.к. рекламной сети могут быть важный как первый, так и второй показатель. Все сильно зависит от того, по какому критерию производится оплата. Соответственно с этим, нам нужно считать результат.
Получаем, что нужно проверить два результата и выдать рекомендации:
1. Нужны установки;
2. Нужны клики.
Сделаем две оценки - посредством критерия хи-квадрат. Вторую оценку сделаем посредством бутстрепа.
В итоге получим, что для:
1. Важности кликов лучше взять первый баннер (где 10000 кликов и 500 установок);
2. Важности установок лучше взять второй баннер (где 10500 показов и 440 установок).
Расчеты в ноутбуке.
Задача со страницы вакансий одной компании, название которой начинается на Y.
На прошедшей неделе в рекламной сети параллельно размещались два баннера. Оба баннера были показаны один миллион раз. Первый получил 10 000 кликов и 500 установок, а второй — 10 500 кликов и 440 установок. Маркетолог просит у вас совета: какой баннер оставить, а какой отключить. Что вы ему ответите? Обоснуйте свой ответ.
Тут идет первый вопрос - а что нам важнее? Установки или клики? Вопрос с подвохом, т.к. рекламной сети могут быть важный как первый, так и второй показатель. Все сильно зависит от того, по какому критерию производится оплата. Соответственно с этим, нам нужно считать результат.
Получаем, что нужно проверить два результата и выдать рекомендации:
1. Нужны установки;
2. Нужны клики.
Сделаем две оценки - посредством критерия хи-квадрат. Вторую оценку сделаем посредством бутстрепа.
В итоге получим, что для:
1. Важности кликов лучше взять первый баннер (где 10000 кликов и 500 установок);
2. Важности установок лучше взять второй баннер (где 10500 показов и 440 установок).
Расчеты в ноутбуке.
#libraries
Pandas-profiling - библиотека для просмотра описательных статистик набора данных. Очень удобна для первичного EDA, если нужно быстро просмотреть набор данных и сформулировать первичное мнение и гипотезы.
Встроены: наиболее частые значения, гистограммы, корреляционные графики, графики попарных связей. Все в одном интерактивном окне.
Из минусов стоит отметить, что может долго раскочегариваться при запуске на объемных наборах данных.
Pandas-profiling - библиотека для просмотра описательных статистик набора данных. Очень удобна для первичного EDA, если нужно быстро просмотреть набор данных и сформулировать первичное мнение и гипотезы.
Встроены: наиболее частые значения, гистограммы, корреляционные графики, графики попарных связей. Все в одном интерактивном окне.
Из минусов стоит отметить, что может долго раскочегариваться при запуске на объемных наборах данных.
#competition
У меня есть некоторая эвристика - на соревнование стоит закладывать не меньше 50 часов.
Почему так?
На EDA, первый baseline, его допил до второго baseline закладываем 8 часов. Умножаем сроки на 2 (весьма щадящий коэффициент для переоценки сроков). Получаем около 50 часов.
Конечно, это скорее шуточное замечание, но примерно так обычно и выходит. Редко когда удается что-то приличное сделать за малое число часов, если нет уже готовых частей pipeline по задаче с каких-то предыдущих соревнований.
У меня есть некоторая эвристика - на соревнование стоит закладывать не меньше 50 часов.
Почему так?
На EDA, первый baseline, его допил до второго baseline закладываем 8 часов. Умножаем сроки на 2 (весьма щадящий коэффициент для переоценки сроков). Получаем около 50 часов.
Конечно, это скорее шуточное замечание, но примерно так обычно и выходит. Редко когда удается что-то приличное сделать за малое число часов, если нет уже готовых частей pipeline по задаче с каких-то предыдущих соревнований.