Опыт разработки требований к профессиональным качествам data scientist

Сегодня практически любой бизнес ощущает потребность в исследовании данных. Data science не воспринимается как нечто новое. Тем не менее не для всех очевидно, каким должен быть нанимаемый специалист.

Данная статья написана не HR-специалистом, а дата сайнтистом, поэтому стилистика изложения весьма специфична, но в этом есть и преимущество – это взгляд изнутри, позволяющий понять, какие качества data scientist являются необходимыми для профессии, для того, чтобы компания могла положиться на такого человека. Опты компании Uninum.

Пролог

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

“В инженерном деле, если не знаете, что делаете — не стоит этого делать.”

Ричард Хэмминг

Как мне сначала казалось, человек требовался вполне определенный: всего лишь обычный дата-что-то-там...программист, аналитик, статистик. Так в чем же сложность составить список требований?

Подошел я к делу как обычно. Достал два листа бумаги. Один озаглавил «Технические навыки», другой - «Профессиональные качества». После этого возникло желание полезть на какой-нибудь ресурс, найти там пачку резюме, выписать списки качеств, выбрать те, что понравятся. Но что-то меня остановило. “Это не мой способ, - сказал я себе. - Я в этом не разбираюсь. Я разбираюсь в задачах..”

Я попытался пойти от задачи. Задачи у нас простые. Тебе дают нераспарсенную CRM сомнительного наполнения и просят предсказать объем продаж на пару месяцев вперед. Совсем просто. Кто угодно справится... Оговорка: если сможет разобраться в бизнесе клиента. В идеале для этого берется рабочая группа, которая абстрагируется от всех прочих задач и посвящает себя разбору именно этой. На входе – желания клиента, на выходе – решение, которое можно проверить, не вдаваясь в подробности и не дублируя выполненную работу.

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

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

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

Выплывали либо общие формулировки вида «ответственность», либо под качествами понимались навыки, что относилось к другому списку.

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

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

Формулировка Задачи

Предприниматель решил открыть магазин при бадминтонных кортах, чтобы посетителям не пришлось ездить в супермаркет за воланами (shuttlecock) и ракетками (racket).

На протяжении года предприниматель сохранял все чеки (receipt) от покупок, чтобы впоследствии понимать, какие решения следует предпринимать для увеличения прибыли. Информация с чеков содержится в прилагаемом файле train_dataset.csv .

Воланы и ракетки он упаковывал и продавал исключительно наборами трех видов:

1. ракетка и два волана,

2. ракетка и пять воланов,

3. десять воланов.

Время от времени предпринимателю приходилось изменять цены с оглядкой на цены в супермаркете и налоговые ставки.

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

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

1. только одна ракетка – 11 долларов 80 центов

2. пять воланов – 5 долларов 90 центов

3. одна ракетка и один волан – 12 долларов 98 центов

Требуется установить размер дохода предпринимателя в январе.

Чувствительность к вероятностям

“Я верю, что лучшие предсказания основаны на понимании вовлеченных в процесс фундаментальных сил.”

Ричард Хэмминг

Задача была составлена в подражание настоящим задачам из жизни, но искусственным образом, что не скрывалось от кандидатов. А, следовательно, для создания датасета были применены некие формулы. Пусть, сдобренные случайными переменными, но формулы. В любом случае, предполагалось, что data scientist имеет возможность эти формулы обнаружить и использовать для прогнозирования.

Конечно, нельзя отбрасывать и такую возможность, что датасет не даст полной картины, позволяющей восстановить формулы с нужной точностью. Но на этот случай в реальной жизни мы придумываем, какой должна быть дополнительная информация, и откуда бы ее достать.

Вообще, стремление найти «закон мироздания» - это хорошее профессиональное качество. Умение понять, что искать и где искать – тоже. Господин Хэмминг знал, о чем говорит. И благодаря ему, в моем списке требований появилась первая строка:

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

Не случайно здесь я употребил словосочетание «полезную для бизнеса». В моей личной практике часто оказывалось так, что не ответ к задаче приносил бизнесу прибыль, а некий побочный результат, который получался за счет открытия каких-то внутренних зависимостей. В отдельных случаях это приносило стартапу дополнительные деньги, новые контракты, растило объем ноу-хау и побочных продуктов.

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

Самоуверенность

“Если какое-то событие привлекает наше внимание, ассоциативная память начинает искать его причину, а точнее, активируется любая причина, уже хранящаяся в памяти.”

Даниель Канеман

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

И она же ставит нам подножку в виде предвзятости подтверждения.

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

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

Так я вписал в список качеств следующее:

Критичность мышления, в том числе, в отношении собственного опыта.

Очень хотелось добавить сюда «и знаний», но далее мне показалось, что эта приписка открывает большую новую тему.

Нейротизм

“Разработав ту или иную теорию, мы вновь обращаемся к наблюдениям, чтобы проверить ее.”

Грегори Мэнкью

В литературе по data science разбираются способы автоматизировать проверку гипотез. Однако, я редко встречал методические указания по их применению. Из-за этого, поверите или нет, однажды я запутался между двумя, казалось бы, очень разными мероприятиями – проверкой статистических гипотез и проверкой модели.

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

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

Как уже было сказано, длина интервала была подобрана специально. Я хотел, чтобы кандидаты имели необходимость и возможность предложить собственные способы проверки наличия сезонности для рассматриваемой задачи. И это качество я тоже добавил в список требуемых профессиональных качеств:

Умение проверять предположения стандартными способами и придумывать новые способы проверки.

Наверное, «придумывать новые способы» звучит слишком громко. Я редко когда сталкиваюсь с необходимостью придумать что-то новое. Вполне подходит метод простых соображений, следующих за вопросом «А что, если?».

В красивой статье «Это правильно, но неверно» Александр Черноокий привел примеры быстрого и почти интуитивного решения для нескольких вероятностных задач. Подобный механизм, как мне кажется, довольно хорошо подходит и для проверки предположений.

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

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

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

Вот мы и получили простой способ проверить наличие сезонности за неимением достаточно продолжительного интервала данных.

Внимание

“Наш разум не подготовлен к пониманию редких событий.”

Роберт Баннер

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

И недостатков.

На деле зависимость между двумя величинами далеко не всегда настолько проста, что ее можно опознать по численным характеристикам. Каким бы красивым ни было линейное приближение взаимосвязи двух величин, всегда остается возможность, что мы имеем дело с чем-то более сложным. Английский математик Френсис Энскомб проиллюстрировал этот феномен четырьмя примерами, которые позже получили наименование «квартет Энскомба».

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

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

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

На деле «спрятать» мало подходит к ситуации. Я просто поставил это распределение рядом с другими, более привычными и понятными. Разница была очевидной на графиках, как мне казалось, но заметили далеко не все. И особенно интересной была попытка одного из кандидатов «улучшить» аппроксимацию переходом к полиному более высокого порядка.

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

Уметь вычленять значимые наблюдения, строить гипотезы относительно их значимости.

Импульсивность

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

Тимоти Лири

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

Однако требуется понять, что может скрываться за выражением «настолько малы».

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

В некотором смысле любое сделанное нами наблюдение или вывод могут восприниматься как результат измерения. Мы смотрим на условия задачи и измеряем доход на еще не случившемся временном интервале. Здесь я заменил таинственное и магическое для многих слово «прогнозируем» на слово «измеряем». В рамках своей обыденной работы я могу вполне так сказать, поскольку прогноз при достаточно высоком уровне точности замещается рутинным расчетом.

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

Указание доверительного интервала есть даже не рекомендация, а необходимость, о которой часто забывают. Более того, хотя в моих словах прозвучит некая педантичность, я считаю, что расчет доверительного интервала есть акт самоуважения, а следующее качество входит в число необходимых качеств для data scientist:

Аккуратность в соблюдении формальных требований алгоритмов и методов, особенно когда дело касается расчета доверительных интервалов и проверки необходимых и достаточных условий.

Пластичность

“Это положение не вполне верно, но верно в достаточной мере для практического применения в большинстве случаев.”

Френсис Энскомб

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

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

В самом деле, что нам известно о продажах? Есть люди, которые в силу известных и перечисленных причин производят покупки. Можно почти полностью смоделировать весь процесс, поскольку мы нашли все зависимости и выяснили, что необъясненный остаток является нормально распределенным и имеет очень маленькую дисперсию.

Начинают появляться вопросы: а покрывает ли покупаемый объем товара потребности людей? Что они делают, когда потребность остается неудовлетворенной? Например, что они делают, если цена на товар, по их мнению, слишком велика? Откуда берется линейная зависимость спроса?

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

Что, если существует проверяемая и непротиворечивая модель, описывающая ситуацию с использованием только имеющихся у нас известных данных? Это тоже стоит проверить.

Эпилог

Позвольте составить итоговый перечень выписанных мною профессиональных качеств data scientist.

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

2. Критичность мышления, в том числе, в отношении собственного опыта.

3. Умение проверять предположения стандартными способами и придумывать новые способы проверки.

4. Уметь вычленять значимые наблюдения, строить гипотезы относительно их значимости.

5. Аккуратность в соблюдении формальных требований алгоритмов и методов, особенно когда дело касается расчета доверительных интервалов и проверки необходимых и достаточных условий.

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

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

Автор: Валерий Кондаков, Co-founder и CTO компании Uninum

Соавтор: Павел Жирновский, Co-founder и CEO компании Uninum

P.S.

Статистика по вакансии на 25/06/19

Дата размещения вакансии: 27/05/19

Всего просмотров вакансии: 2727

Всего откликов: 94

  • Прислали решение задачи, но оно оказалось неверным: 20%
  • Согласились решить задачу, но не прислали ответ: 30%
  • Отказ на стадии рассмотрения резюме по различным причинам: 45%
  • Прислали решение, близкое к правильному: 5%
0
18 комментариев
Написать комментарий...
Вася Пражкин

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

Ответить
Развернуть ветку
Pavel Zhirnovskiy
Автор

Что вы имеете в виду под уровнем? На эту вакансию откликались люди с очень разным уровнем опыта, образования и пожеланий по з/п, но ошибки в решении задачи все делали одинаковые. Более того, 2-мя месяцами ранее у нас был опыт найма без тестовой задачи, который, к сожалению, получился не очень продуктивным))

Ответить
Развернуть ветку
Вася Пражкин

Павел, в IT всех специалистов делят на уровни - Junior, Middle, Senior, Lead, Team Lead, Technical Lead и другие. Опыт у всех разный, денег хотят тоже по-разному. Вы же когда в автосалон приходите, уже примерно представляете, что хотите или тоже готовы рассмотреть от Соляриса до S-класса?

"опыт найма без тестовой задачи" - как оценивали специалиста, по интуиции?

Ответить
Развернуть ветку
Pavel Zhirnovskiy
Автор

Возможно, дело в том, что у нас достаточно специфические задачи, условия работы и соответственно пожелания к кандидатам.

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

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

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

В случае с наймом без тестовой задачи мы оценивали кандидата по его опыту, научным публикациям и впечатлениям от собеседования.

Ответить
Развернуть ветку
Вася Пражкин

"у нас достаточно специфические задачи, условия работы и соответственно пожелания к кандидатам"

Вы заставляете людей одновременно кодить, петь Хава Нагилу и отбивать чечетку ногами? Это IT, тут уже Best Practices выработаны десятилетиями, может стоит упростить все Ваши требования до реально нужных?

"те 2 кандидата, которые нас устроили (один из них уже работает), обладают совершенно разными "уровнями", но при этом хотят похожих денег "

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

"когда вы выбираете между солярисом и мерседесом, отличия явны и очевидны"

Для опытного нанимателя отличия между Junior и Lead также очевидны, как между Солярисом и S-классом.

"В случае с наймом без тестовой задачи мы оценивали кандидата по его опыту, научным публикациям и впечатлениям от собеседования. "

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

Ответить
Развернуть ветку
Pavel Zhirnovskiy
Автор

"Вы заставляете людей одновременно кодить, петь Хава Нагилу и отбивать чечетку ногами? Это IT, тут уже Best Practices выработаны десятилетиями, может стоит упростить все Ваши требования до реально нужных?"

- пока да, и сами так делаем, максимум пользы-минимум ресурсов

"Для опытного нанимателя отличия между Junior и Lead также очевидны, как между Солярисом и S-классом."

- я не могу назвать себя опытным нанимателем, хотя в течение своей трудовой карьеры нанял в районе 100 человек/будем надеяться, что со временем я смогу различать junior и lead или что еще лучше, это будут делать специально обученные люди))

Ответить
Развернуть ветку
Вася Пражкин

"пока да, и сами так делаем, максимум пользы-минимум ресурсов"

Эх, мне аж жаль стало ваших Data-Scientist'ов )). Разделение труда придумали не просто так, актуально даже для маленьких стартапов!

"в течение своей трудовой карьеры нанял в районе 100 человек"

Это ж как Вы глаз не набили, 100 человек-то наняв?

Ответить
Развернуть ветку
Pavel Zhirnovskiy
Автор

жаль или не жаль - это вопрос мотивации к труду)) кому-то хочется стабильности и вовремя домой уходить, а у кого-то амбиции, жажда знаний и высокие устремления, а мы пока не гугл, чтобы создать условия и для того и для другого))

еще раз повторюсь - на данный момент условия и требования специфические, такой этап развития, поэтому важны 2 вещи: как человек соображает и что умеет (видно из задачи) и личные качества (частично проверяются в процессе общения по задаче)

Ответить
Развернуть ветку
Valery Kondakov

Смею напомнить, что перечисленные "Junior, Middle, Senior, Lead, Team Lead, Technical Lead" - это должности, отражающие не столько уровень мастерства, сколько внутреннюю подчиненность в каждой конкретной компании. Практика использования этих наименований для того, чтобы как-то более-менее точно определить подготовку кандидата, существует и довольно распространена, чтобы сбить с толку. Однако это разделение не соответствует ни оценке навыков, ни профессиональных качеств.

Ответить
Развернуть ветку
Вася Пражкин

"Team Lead, Technical Lead" - это должности, а остальные - просто градации мастерства, хотя иногда в компаниях могут сделать и должностями. Градации мастерства обычно делят по опыту работы, что весьма условно, так как можно проработать 10 лет, а прогресс будет небольшой, а у кого-то и за 3 года прогресс с Junior до Senior.

Примерно понимается, что Junior - человек без опыта или с минимальным опытом. Middle - уже начал есть собаку, но требуются советы умного человека. Senior - собаку съел, опытный боец, может сам воевать в одиночку. Lead - гроза морей и океанов, может в одиночку захватить Албанию.

Ответить
Развернуть ветку
Valery Kondakov

Ну, как вы сами правильно заметили, "примерно" и "понимается". А если без "примерно" и без "понимается", то все эти термины обозначают должности.

Ответить
Развернуть ветку
Вася Пражкин

Употребление "примерно" и "понимается" значит лишь то, что мир - многообразен. Структура и должности команды, что применима к стартапу, сильно отличается от структуры компании со штатом в 100 человек.

Ответить
Развернуть ветку
Valery Kondakov

Да, структура и должности отличаются. И именно поэтому не стоит путать понятия. Вы употребляете должностное деление для описания достаточных для должности навыков и качеств. Но следует понимать, что множество "достаточных" не определяет множество "необходимых". И если уж говорить, что именно следует делать в первую очередь, так это определять необходимое множество навыков и качеств, а уже потом создавать градацию до "достаточного". Необходимые условия проверяются первыми, а уже потом достаточные. Так же и здесь. Прямо в первом параграфе во втором абзаце видим: "какие качества data scientist являются необходимыми для профессии". Не достаточные для Junior, не достаточные для Middle, не достаточные для Senior, а необходимые для любого уровня в данной профессии.

Ответить
Развернуть ветку
Вася Пражкин

Валерий, как-то все размыто пишите.. Зачем придумывать что-то, если уже оно придумано до нас? Собеседование Data-Scientist мало чем отличается от того же DevOps или Developer, просто технологии и стек разный. Статья - это реально каша в голове и попытка из этой каши что-то вычленить. Но по хайрингу написано насколько много статей, что изобретать что-то свое - это как изобретать велосипед.

Ответить
Развернуть ветку
Valery Kondakov

Ну, если разница для вас между Data-Scientist и Developer, а уж тем более, между ними и DevOps заключается только в технологиях, то не буду вас сбивать с пути истинного.

Ответить
Развернуть ветку
Anton Z.

"Lead - гроза морей и океанов, может в одиночку захватить Албанию."

чисто ремарка. Lead подразумевает, что он кого то ведет, т.е. это добавка управляющих компетенций.

Ответить
Развернуть ветку
Вася Пражкин

Lead не всегда кого-то ведет :) Часто это просто очень опытный товарищ, который не хочет менеджерить.

Ответить
Развернуть ветку
Вася Пражкин

.

Ответить
Развернуть ветку
15 комментариев
Раскрывать всегда