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


(Заранее извиняюсь за обилие английских слов, какие-то из них я не знаю как перевести, а какие-то мне переводить не хочется.)



Краткое содержание первой части:


  • Январь — пришло четкое осознание, что защита через несколько месяцев и пора думать, что делать после того как я покину альма матер и, что постдок — это не вариант, а Data Scientist — это хоть и не работа моей мечты, но лучше сходу ничего не придумывается, и потому принимается за рабочий вариант, и что пора шевелится в этом направлении.
  • Июнь — выпуск из университета.
  • Июль-Август — полуактивный поиск работы.
  • Сентябрь — очень активный поиск работы.(Я спал в спальнике на полу в подвале дома одного своего знакомого. Стимулирует.)
  • Октябрь — предложение о работе, которое я, собственно, и принял.

Важно отметить, что я ушел из академической среды не потому что я не люблю науку — я ее очень люблю, а потому что у меня сложилось стойкое впечатление, что на данном этапе работа в индустрии мне даст больше. Например, мне откровенно не нравился код, который я пишу, особенно после прочтения какой-нибудь книжки на тему “clean code”, а также не нравилось, как я его поддерживаю. Да, я активно использовал git и для каких-то проектов, и при написании статей (правда научного руководителя на это не раскрутил, он больше по старинке), но это самообучение, все-таки отличается от реального проекта со 100 разработчиками. И то, что академическая среда очень консервативна и нетороплива — это тоже меня всегда раздражало. Хотелось окунуться во что-то новое, динамичное, молодежное, так, чтобы слова agile development, а также вещи вроде "round B financing” из абстрактных понятий из книжки превратились во что-то естественное и понятное. И стартап в кремниевой долине — это, однозначно, был замечательный вариант.


И что было дальше...


Контора, которая называется Bidgely, предложила мне позицию Data Scientist с окладом $130k в год грязными (примерно $7400 в месяц чистыми) работать в офисе, расположенном в городке Sunnyvale, что в Кремниевой Долине, в паре километров от штаб квартир Google, Linkedin, Apple, и т.д.


Bidgely (далее по тексту иногда будут называться кодовым словом “Индусы”) — это стартап, который занимается тем, что берет потребление энергии как функцию времени и раскладывает на компоненты — это стиральная машина, это кондиционер, это кухонная плита, это холодильник — и т. д.



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


В теории выглядеть это должно как-то вот так

Бизнес был построен по модели B2B, то есть клиентами были не простые смертные, а компании типа ПетроЭлектроСбыта.


Конечные пользователи на экранах видят примерно такую картину:



Зачем это надо поставщикам электроэнергии?


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


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


Или, например, вот такой интересный use case — в Австралии летом очень жарко и поставщики энергии зашиваются в том смысле, что инфраструктура не справляется с нагрузкой, и для них смягчением проблемы было попросить (и предложить $20) тем, кто активно пользуется кондиционером в энергетический час пик, остужать жилище за час до предполагаемой максимальной нагрузки, что позволяет эту нагрузку распределить.


Что является продуктом? => алгоритм + визуализация.


Не смотря на то, что вышеописанное может показаться маркетинговой туфтой, продажники умудрились убедить кучу компаний в Австралии, США, Канаде, и странах Европы, что за этим будущее и надо, как минимум, попробовать. Причина, почему у меня были сомнения в коммерческой эффесктивности этого продукта — это то, что уж больно он напоминает Google Fit, в том смысле что выдает некий анализ происходящего, но насколько этот анализ решает какие-то реальные проблемы мне было не очевидно.


Ни одна серьезная контора не будет сразу во что-то вписываться, и поэтому охмурение компаний происходит в три этапа:


  1. Пилотный проект, стадия альфа. В 20-100 домов устанавливаются датчики, которые по wifi пересылают данные о потреблении электроэнергии, а пользователи на сайте/телефоне могут отслеживать разложение этого потребления на компоненты.
  2. Пилотный проект, стадия бета. Тоже самое, но на 500-1000 домов.
  3. Доступ ко всем пользователям данного поставщика энергии.

Компания за год выросла с 18 до 50 с лишним человек. Пока она была совсем маленькой, Data Science team была представлена одной девушкой, которая незадолго до того как наняли меня перешла в Facebook, а так же парнем по имени Алекс, который то ли был у нее на подхвате, то ли они работали параллельно. После того, как компания разрослась было принято решение усилить команду Data Scientist’ов и под это наняли меня и индуса по имени Pratik, оба, только что закончили обучение, то что называется fresh grad, для того, чтобы снять часть нагрузки с Алексa, впитать от него часть знаний и после того, как эти знания впитались — усиленно двинуть искомый алгоритм в светлое будущее, а компанию к миллиардным прибылям.


Алекс выглядит вот так.

У компании два офиса: frontend, продажники, высший менеджмент, Data Science в США, а весь backend и QA из соображений экономии — в Индии.


Все вычисления на AWS. Основные языки программирования Java — frontend/backend. Matlab — для Data Science.


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


То есть это индусское предложение я принял, с одной стороны потому что спать в спальнике в подвале у приятеля, вставая каждое утро с мыслью, что деньги на кредитках скоро закончатся, работы нет и вообще перспективы у новоиспеченного кандидата наук достаточно мутные, мне надоело, а с другой, мне предложили внятные для Junior позиции деньги (диапазон по зарплатам в долине на похожую позицию 100-150k/год) в компании, которая вся из себя динамичная (то, что она динамичная я понял на oniste интервью у них в офисе, когда увидел как все метаются). И задача интересная с математической точки зрения, да и имеет практическое применение.


Одно мне у них не понравилось — офис, шумный, и очень много света. Яркие лампы плюс здоровое окно в которое агрессивно светит солнце в первой половине дня. По глазам бьет мама не горюй. Во время onsite я уточнил про офис, на что CEO сказал, что беспокоиться совершенно не о чем, потому что этот офис никому не нравится и через пару месяцев всё-равно переезжаем в новое помещение в Mountain View.


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


За исключением офиса, который всего лишь временная проблема, это не работа, а песня.


Первый день


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


По приходу мне выдали MacBook 13” 2012 года с 4Gb ram, что, на мой взгляд, слегка слабовато для разработки алгоритмов даже и на небольших объемах данных. Алекс, который был назначен мне ментором, по-быстрому набросал схему того, что надо сделать, ткнул в кусок кода, добавил что это очень важно, выдал инструкцию о том как компилировать код и улетел по своим делам.


Следую инструкции — пытаюсь скомпилировать код, а он не компилируется. Поймал Алекса и выяснилось, что для того, чтобы все получилось надо отключить unit тесты, потому как они устарели, и вообще unit тесты — низкий стиль. Я не являюсь религиозным привережнцем TDD, в чистом виде этот подход у меня никогда не работал, но, не смотря на это, такое отношение Bigely к тестрованию кода меня напрягло.


Открываю код в Matlab’е и мне становится страшно. Одна из причин, почему я ушел из академической среды — это для того, чтобы со временем научиться писать production quality code. И для того, чтобы этому научиться, кроме чтения правильных книжек, надо работать над сложным кодом в команде со старшими опытными товарищами, которые тебя, если что, во время code review носом ткнут куда надо, и научат использовать эффективные инструменты вроде умных IDE, написания тестов, правильной архитектуры и т.д.


А страшно мне стало, потому что от первого взгляда на код мне стало ясно, что я жестко попал на код которого насмотрелся и с которым накувыркался в аспириантуре. Да, они пытались создать модульную архитектуру, и что-то где-то получилось, но рандомная индентация, функции по 1000 строк, полное отсутствие комментариев к коду, названия переменных с мистическим смыслом вроде pkI, vIdx, featsT, pkPos, M1, практически в каждой функции по магическому числу, и никакой документации.


Я Алекса спрашиваю:" Как быть? Тут вилы." А он мне так и говорит искренне: “Ну у меня времени не было писать хороший код, хотя я, конечно, умею, а вот теперь когда нас трое — мы все будем делать по уму, а пока, говорит, в принципе тут все просто. Debagger’ом прогони строчку за строчкой и посмотри на эволюцию переменных, и сразу все будет понятно. Тут всего то 10000 строк”.


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


Далее


Я думаю, что вся эта индусятина в коде во многом вызвана тем, что и Алекс, и та, ушедшая в Facebook девушка, как и я, пришли прямо из академической среды, где в среднем пишут хреновейший код, в стартап на ранних стадиях развития, в котором надо было фичи плодить быстро, причем для этого использовался MatLab, который заставляет писать нечитаемый код и не имеет IDE, которая поддерживает рефракторинг. А раз осуществлять рефракторинг без удобных инструментов болезненно, то они его и не делали.


При этом те, кто занимался frontend / backend, писали нормальный код, но что происходит в тех модулях, что пишут Data Scientist’ы не понимали даже на высоком уровне и использовали его как black box.


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


Как вывод на будущее из этой нездоровой ситуации — если в описании к вакансии есть слово Matlab — для меня эта вакансия автоматически исключается из рассмотрения. Во-первых, потому что наверняка код — это сплошная нечитаемая, не тестируемая индусятина, добавлять фичи в которую это океан боли. А, во-вторых, потому что сам по себе Matlab, за исключением библиотеки для обработки сигналов, не обладает никакими серьезными преимуществами на фоне других инструментов. И тот факт что Data Science team выбрала его и после трех лет использования не поменала на что-то более внятное — это сигнал о том, что уровень квалификаций этой команды ниже чем то, где хотелось бы работать.


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


Когда я cпросил нашего CEO: “Красиво — это сколько?”, он сказал, что понимает, что данные шумные, абсолютной точности не достичь и то что сейчас уже всё почти замечательно, и осталось слегка подкрутить, так чтобы стало 90%. Времени оставалось не много, и поэтому мне делегировали алгоритмы, которые детектируют посудомоечную и стиральную машину, а электроплиты, бассейны, холодильники достались Data Scientist’ам, которые работают в индийском офисе.


Устроит 90% — значит попытаемся выдать 90%. Два месяца — это не много, но на kaggle.com я хорошие модели и за меньшее время выдавал, и поэтому “партия сказала надо, комсомол ответил есть”.


Встает вопрос — а как вообще это точность меряется?


Я представлял, что это типа классического cross validation или еще чего-то похожего, но выяснилось, что у Индусов свои Индусские пути. По уму нужен набор размеченных данных, которые пытаются изображать из себя репрезентативную выборку того на чем алгоритм будет применяться, на нем сравниваются предсказания и то, что размечено — получается оценка точности модели. Тут море нюансов, как это делать правильно (точность модели на тренировочных, тестовых данных и в production — это три большие разницы), но, как ни крути, чтобы понять что такое плохо, а что такое хорошо — нужен некий эталон, с которым предсказания и сравниваются.


После трех лет работы над всеми этими алгоритмами у Индусов такого эталонного отмаркированного набора данных не было. А это очень-очень плохо. Данные это важно.(Хороший пост на эту тему). Надо заметить, что в большинстве случаев, насобачившись, можно визуально, по форме сигнала отличать, кто тут стиральная машина, а кто бассейн. Так вот Индусы сделали что — они наняли целую команду, которая за небольшие деньги, визуально сравнивает наши предсказания c тем, что они видят глазами. И в случае каждого несовпадения сабмитят bug report. Но при этом не делают никаких попыток создать отмаркированный набор данных. То есть оценка точности алгоритма происходит субъективно.


И всё ещё печальнее, потому что решение о переходе пилотного проекта на следующую стадию принимается во многом по тому, как менеджеры компании поставщика электроэнергии впечатлены нашим disaggregation для их собственных домов. И слова про 90% точность в целом их волнуют постолько поскольку, они смотрят на то, как алгоритм работает на данных, которые поступают из их жилищ.


То есть существовали 3 различные точности:


  1. Зашкаливающая точность на данных поступающих из VIP домов.
  2. Хорошая точность в домах пилотного проекта.
  3. Средняя точность для всех остальных.

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


Иногда поставщики электроэнергии устраивали конкурс, чтобы выбрать с кем начать пилотный проект и тогда начинался жесточайший hand labeling, когда пол нашего и весь индийский офис вручную маркировали данные. Как потом выдавать такую же точность, когда мы впишемся в пилотный проект вопрос не поднимался.


И вот сижу я и думаю, c чего начать? Отмаркированных данных нет. Оценка точности алгоритма непонятна. С грехом пополам разобрался, что происходит на идеологическом уровне с этими стиральными машинами. А там система хаков и противовесов, которые работают с магическими числами, которыми пестрит код. И идея вроде неглупая, но что делать непонятно. Спрашиваю Алекса — а он опять:"Ты дебагером пробегись, да посмотри как и что эволюционирует". И это, конечно, вариант, если ты код понимаешь, а если по верхам, то черт его знает. И я обеими руками за то, чтобы осуществлять визульную инспекцию того, что происходит как можно больше и чаще, но полное отсутствие документации, даже и устаревшей это неправильно, как минимум потому что в долгосрочной перспективе это неэффективно. И то что наш CTO на этот вопрос ответил:"Ну что ты хочешь? Мы же стартап." — это, но мой взгляд, не ответ, для компании в 50+ человек.


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


Ясное море что для выживания компании надо, чтобы была клиентская база и строить ее надо по возможности быстро, пока не закончилось финансирование. Но развитие компании — это марафон, а не спринт, и пытаться выжать из работников все соки не надо, как минимум потому что в долгосрочной перспективе это не работает. Я не парился в том смысле, что приходил в 9, уходил в 5 вечера. У меня в контракте написано, что я работаю 8 часов в день. Я под этим подписался, значит так оно и есть. Но тот же Алекс в день работал часов по 10 минимум. Он, конечно, религиозный азиат(в церковь несколько раз в неделю ходил в обязательном порядке), может ему так нравится. Но меня такая перспектива не возбуждала.


Еще один важный нюанс — нам часто требовалось взаимодейтсвие с QA и backend, и для этого нужно было общение с индийским офисом, где они и находились, а часовые зоны сильно разные, и поэтому назначались meeting’и по вечерам и выходным. Я к паре из них присоединялся — но потом пришло осознание, что полуночные совещания — это не исключение, а правило, и что работу по ночам и по выходным мы не обсуждали, и то, как правильно организовать взаимодействие между командами в разных часовых поясах — это проблема менеджеров, а вовсе не моя. Так что я себе в календарь добавил, что занят с пяти вечера и вроде как меня на такие полуночные совещания приглашать перестали. При этом я не против участвовать в on-call ротации, когда в случае каких-то больших проблем тому кто on-call в аварийном порядке надо что-то решать, даже если это два часа ночи.


И то, что надо напрячься сейчас, а вот после запуска пилотного проекта будет чуть проще — это тоже не аргумент, в силу того, что продажники охмуряли кучу разных компаний и какой-то очередной проект запускался каждые пару месяцев. (И таки да, после Австралии пришла Германия, а после нее шла подготовка к Италии и шли разговоры про Гон Конг)


Отмаркировал я сколько-то этих стиральных машин, штук 100, наверное. Написал код, который оценивает точность, переписал какие-то куски для увеличения скорости (Мой маленький Macbook уж больно слаб, а на мое предложение выполнять вычисления в облаке Алекс отмахнулся). Прогнал алгоритм. F1 score = 0.5 (если грубо, то можно интерпретировать как точность). А это даже и не рядом с 0.9 о которых возбужденно говорил наш генеральный директор.


Алексу показал — тот расстроился, что точность маленькая, но обрадовался, что наконец-то у нас будет правильный систематический научный подход. Я ему чуть в бубен не дал, ибо у него PhD по Computer Science, полученное в UC Berkley, и про то, как оценивать точность моделей в машинном обучении он, как минимум, слышал. Но этот олень и вся контора за 3 года этим не озадачились и вместо этого страдали какой-то неструктурированной неэффективной фигней.


К середине декабря, после прочтения пары книжек, вопросов на stackoverflow, общения с парой профессоров, которые занимаются обработкой сигналов, легкого измения логики работы алгоритма, подкручивания магических чисел и добавления пары эвристик, наш доблестный алгоритм распознования стриральных машин выдавал F1 = 0.65. Прошел пилотный запуск в Австралии и я уехал домой в Питер на пару недель с мыслью, что по приезду надо будет искать новую работу.


После нового года


Важно отметить, что я находился на студенческой визе, которая к тому времени давно истекла. Тут все легально, хоть и непрозрачно. Находится в США я мог, работать мог, выехать мог, а вот въехать нет. Для того, чтобы въехать, надо получать новую визу. Причем, для того, чтобы ее получить, из США надо выехать. За пять лет обучения я этим пару раз занимался и оформение новой визы занимало чуть больше недели. Предполагалось что раз раньше это работало, то и сейчас это сработает точно так же. Но был нюанс… В те разы я был студентом и получал студенческую визу, а тут я получал студенческую визу, для того чтобы работать. мужик, который у меня в американском консульстве в Санкт Петербурге документы принимал, сильно удивился всей этой ситуации, попросил прислать список публикаций и резюме и отправил мои документы куда-то на рассмотрение.


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


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


Что мне не нравилось в текущей ситуации и над чем надо было работать?


  • Однозначно не нравился офис. Каждый вечер болели глаза.


  • Мне не нравились те технические навыки, которым я учился на работе. Магию git’а и Jira на том уровне, что она использовалась в компании, я давно впитал. Качество написания кода не повышалось, как минимум потому что весь Data Science team писал хреновый код, то есть впитывать было не от кого. Да, я привыкал к Matlab’у, но без этого навыка можно было спокойно жить. В алгоритмах, которые использовались в конторе, я разобрался, причем большого потенциала у них я не видел, а о нейронных сетях (это я не к тому что мне хочется везде воткнуть нейронные сети, а потому что под эту задачу они ложатся очень естественно, и на эту тему есть интересные статьи), Алекс слышать не хотел. Была попытка подтолкнуть компанию начать двигаться в сторону python, как языка разработки и наш CTO, и все Data Scienist’ы были обеими руками за, но Алекс, как большой фанат Matlab’а, был непреклонен. Логика была такая: “У Matlab’а бинарник скомпилировал — залил на сервер и все. А тут инженеру в Индии придется и бинарник компилировать и питоновский код из репозитория дергать — это сложно, так делать не будем.” Причем я пообщал сам переписывать функцию за функцией, тестировать что всё работает, и объяснить инженеру в Индии как и что делать по шагам, но не получилось. Видимо не те слова говорил и не так. Машинным обучением, которое мне очень сильно нравится и которое во многом обусловило мое решение уйти из университета, как это ни странно, Bidgely не занималось. Алгоритмы, которые использовались — это набор эвристик и чуть чуть статистики. Ничего плохого в таком подходе тоже не было, но масштабировался он так себе. Мы пытались использовать один и тот же алгоритм в различных частях света и с этим наш алгоритм справлялся плохо, как минимум потому что ему не хватало свободных параметров (capacity of the model), но увеличивать их число мы тоже не могли, потому что существующий параметры мы выставляли вручную, а не пытались извлечь из данных, как это делается в классическом машинном обучении. Забить болт на процесс увеличивания знаний в машинном обучении я тоже не мог и практически каждый вечер после работы смотрел лекции, читал статьи и книжки, а также участвовал в соотвествующих соревнованиях на кагле.


  • Мне не нравился Sunnyvale. Я думал, что Кремниевая долина — это молодежно динамично, инновации на каждом шагу, и в Mountain View и Palo Alto во многом так оно и есть, но Sunnyvale к этому коллективу не относился — это большая деревня где по большому счету в свободное время и делать то нечего.


  • Зарплата меня вполне устраивала, но тот факт, что другие выпускники нашего доблестного факультета получали 140-150k, что не намного, но приятнее, тоже подталкивало к мысли, что пока что-то менять.

Раз уж я так не вписывался в эту позицию, то почему сразу и не ушел?


Во-первых, то, как я влетел с визой в России, мне не то, что не понравилось — меня это припугнуло.


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


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


Наш CEO с Алексом тоже сделали выводы из того что ставка на то, что достаточно нанять пару неглупых Fresh Grad’ов и вопрос с главным алгоритмом будет закрыт за пару месяцев не сработала, и было принято решение нанять пару Data Scienеist’ов но с 2-3 годами опыта работы в индустрии, а также Director of Analytics который и поведет весь наш коллектив к светлому будущему.


Кроме всего прочего наш CEO, решил влится в процесс разработки и улучшения алгоритмов и лично присутствовать на наших митингах, но при этом так, чтобы они назначались в соотвествии с тем, когда у него окно свободного времени, например, в 6 вечера в пятницу. Из плюсов то, что ему можно было подкинуть идею, которую Алекс не одобрил, и убедить попробовать, и тормозящий момент от Алексовского:"I am not convinced that this your idea will work, let's not do it", был преодолен.


Проведение интервью


Стали нанимать. Bigely связались с рекрутерскими агенствами, запостили вакансии везде, где надо, описание вакансии и в нашу сторону полетели резюме. Большую часть наш VP of Engineering, отсеивал, но и из того что оставалось получилось много. Процесс интервью был организован так:


  1. Общение кандидатов с рекрутерами.
  2. Телефонное: Проверка навыков написания кода в collabedit.
  3. Телефонное: Знание статистики/машинного обучения и умения эти знания применять.
  4. Oniste к которому надо подготовить некое домашнее задание. (Ссылка для тех, кому интересно.)

И понеслось. У меня и Pratik 4-5 интервью в неделю. Производительность труда просела еще больше. У Алекса все еще хуже, потому что ему надо еще оценивать кандидатов на Director Of Analytics. Я поначалу достаточно жестко фильтровал в надежде на достойного кандидата, но после первого месяца в таком режиме сильно все ослабил, мотивируя тем, что так мы вообще никого не наймем, а хотелось бы чтобы люди были уже вчера. Была пара сильных кандидатов, но они от оферов отказались.


Процесс общения с десятками кандидатов, причем у каждого опыт работы в 2-3 года работы сильно поднял мою уверенность в себе и своих технических навыках. Забегая вперед, скажу что Bidgely таки наняли Data Scientist’a через 5 месяцев(В Data Science не соображал, но зато писал хороший код, что и не удивительно при том, что его предыдущая позиция Sr. Software Engineer) и Director of Data Science через 8 месяцев этого трудоемкого процесса. (его я не застал, так что комментировать не могу). Оба, кстати, тоже индусы.


Я, правда, в связи с возросшей нагрузкой не расстроился, а скорее обрадовался. Как раз пошли важные знания, а именно — появилась база данных резюме которые я анализировал на тему того, что я в этих резюме вижу, что мне нравится, что мне не нравится, и как это связано с тем, что я слышу во время интервью. Плюс я распросил всех кто с процессом наема Data Scientist’ов был связан, что они видят и что хотят увидеть.


Дальше улучшать стиральную машину повесили на Pratik’a, чтобы уж он то выдал 90 процентную точность за месяц. Я у него на днях спросил — он ее до сих пор оптимизирует. А на мне осталась посудомоечная.


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


Не смотря на то, что выше я сказал, что Sunnyvale — это деревня, он все-таки недалеко от Mountain View, в котором много правильных стартапов и компаний имеют свои офисы, и, как следствие, организуют интересные и не очень митапы, на которые я активно начал гонять, благо в велосипедной доступности.


Весна


В начале апреля почти в один день со мной связались рекрутеры Google и Facebook, и предложили пообщаться, и стало понятно, что пора. Я слегка поправил резюмe, начал его рассылать, связался с рекрутерами которые работали на Bidgely, и попросил их помочь, а также пробросил свое резюме используя наработанные знакомства. И выяснилось, что ситуация на фоне того, что было за год до этого, сильно изменилась c лучшую сторону, и что мои страхи что работу будет не найти и, что никому не понравится мое резюме в котором небольшой опыт работы, были напрасны.


Чего мне хотелось?


  • Офис, в котором у меня бы не болели глаза из-за неправильного освещения.
  • География — San Francisco. Пустынные Sunnyvale — это не мой вариант. Надо чтобы было всего и много и рядом. Если в компании офисы в различных часовых поясах, то чтобы меня это напрямую не касалось.
  • Чтобы было напрямую связано с машинным обучением. Я себя достаточно комфортно чувствую в этой области, но хотелось бы углубить эти знания. Вариации на тему когда я днем работаю и не получаю знаний, а потом компенсирую это занимаясь по вечерам — это не круто и этого бы хотелось избежать.
  • Основной язык программирования: Python — оптимально. R — тоже можно. Java/Scala — по ситуации, но скорее нет чем да, Java/Scala и Data Science — это ближе к Data Engineering, а это мне не интересно. Занимаюсь, лишь потому что приходится. Matlab — это даже не обсуждается.
  • Позиция: либо Junior в большой компании (пусть меня научат), либо Senior в стартапе, чтобы мое мнение имело какой-то вес при планировании и выборе инструментов (я все сделаю красиво, главное не мешайте).
  • Жизнь в долине очень дорогая, поэтому очень бы не хотелось, чтобы зарплата была ниже. Такая же вполне бы устроила.
  • Поменьше индусов. Это, конечно, расизм и среди индусов много классных ребят, да и вообще по отдельности они все нормальные, но когда их целый коллектив, в него тяжело вписаться. Думаю что и индусу было бы тяжело в преимущественно русскоговорящей команде.
  • Чтобы присутствовал Head of Data Science/Director of Analytics, то есть менеджер, который понимает что происходит в команеде, сам разбирается в Data Science и нарезает правильные задачи с правильными интервалами и в правильной последовательности. Это самоорганизующася структура с вкраплениям влияния нашего CEO, которую представляла из себя Data Science, в Bidgely мне не понравилась.

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


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


(Примерно такой же длины список которым не понравилось мое резюме.):


  • Facebook — завалил онсайт.
  • Google — добрался до onsite, но отменил.
  • Uber — добрался до онсайт, но отменил.
  • Twitter — они долго телились с рассмотрением резюме, отменил телефонное интервью.
  • Quad Analytix — взаимно не понравились друг другу на onsite.
  • LendUp — взаимно не понравились друг другу на onsite.
  • TrueAccord — принял предложение о работе.

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


Cписок вопросов, который я в той или иной форме спрашивал у всех компаний с которыми общался на тему работы


Первый


Какова структура Data Science Team? И если бы кто-то говорил, что самоорганизация энтузиастов => на этом всё бы и закончилось. Но к счастью такого не случилось. В идеале от стартапов хотелось услышать: Вот это команда N человек, John — Data Analyst, Mary — Data Engineer, Mike — Head of Data Science, Jennifer — experimentation, и т. д.


Второй


Если у нас будет взаимная любовь и я начну работать на этой позиции, какие конретно задачи планируется я буду решать? Хотелось избежать ситуации когда надо будет делать какие-то совершенно не интересные мне вещи, особенно когда их много и разных, и одновременно. Как, например, улучшение алгоритма, маркировка данных (я бы этого избежал), высокоуровневый анализ пилотных данных вручную в Google Sheets, то есть то, что в автоматическом режиме бы решила связка DataDog и Tableau. И тут же оценка того, насколько это Junior позиция.


Третий вопрос


Какие языки программирования/инструменты используются? Влететь, как получилось с Matlab’ом, очень не хотелось.


Четвертый


Как происходит тестирование точности моделей? Тут хотелось избежать того что субъективная оценка — это единственный доступный способ, как это было в Bidgely, и о том, откуда берутся отмаркированные данные. Ситуации, когда надо улучшать/разрабатывать алгоритм, но возможности численно оценить его точность нет — это нафиг. Тут я повторю ссылку на правильный текст.


Пятый


Как обстоит ситуация с прямыми конкурентами? Большие компании я об этом не спрашивал, но у стартапов однозначно интересовался. Очень хотелось избежать ситуации как в Bidgely, когда несколько (больше пяти) игроков дышут друг другу в спину, число поставщиков электро энергии сильно ограничено, и продажники втюхивают то, чего нет, а потом приходится изворачиваться чтобы клиент не поймал на лжи во время пилотного эксперимента, включая все эти нездоровые манипуляции с hand labeling, когда вручную подкручиваются результаты. Да и весь этот режим “пожаротушения”, когда прыгаешь с одной задачи на другую, пытаясь впихнуть невпихуемое тоже ногами растет во многом именно оттуда.


Самый главный вопрос


Насколько будет комфортно работать в этом офисе? Для этого требуется прогуляться по офису во время onsite интервью.


Так вот, не смотря на то, что TrueAccord на фоне гигантов вроде Google, Uber и Twitter, мною рассматривался, как запасной вариант, на все вышеперечисленные вопросы они дали ответы, которые меня устроили и я принял их предложение о работе и, четыре месяца спустя, всё выглядит так, что я с выбором не ошибся. Ну и тот факт что у нашего CEO это третий или четвертый стартап и у всех предыдущих был удачный выход (их всех задорого купили) добавил уверенности что менеджеры тут поопытнее и рабочий процесс организован на уровне. Вроде пока так оно и есть.


Заключение


На фоне вышеописанного текста может сложиться впечатление, что я пытаюсь выставить Bidgly в плохом и свете и я тут один Д'Артаньян. И если такое впечатление сложилось, за это я прошу прощения. Bidgely это замечательный стартап, только, пожалуй, не для меня. Яркий тому пример Pratik, который начал работать примерно в то же время, и ему, действительно, нравится культура в Bidgely. Правда он и сам индус, но не факт, что это важно.


Скорее всего разница была в другом.


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


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


В-третьих, Pratik пришел в Bidgely работать. Я же пришел учиться. Возможно, те, кто дочитает этот тест до этого места скажут, что таких работников как я сразу надо гнать вшею. И скорее всего будут правы, потому что я рассматриваю работу как процесс конвертации одной валюты в другую, а именно секунд моей жизни в комбинацию денег и знаний. Причем знания имеют больший вес чем деньги, и, например, 5 лет в аспирантуре за маленькие деньги я воспринимаю как удачную сделку. И при совершении такой сделки хочется чтобы курс был справедливый и всяческие скрытые накрутки вроде полуночных совещаний без дополнительной оплаты я воспринимаю как попытку меня развести. А использование Google Sheets там где надо использовать Tableu и Matlab там где есть гораздо более внятные инструменты как потерю своего времени. С другой стороны я крайне негативно отношусь к тем, кто приходит на работу не работать. Если подписал контракт, то свои восемь часов в день надо работать с максимально возможной отдачей.


Я пообщался c Pratik и он мне сказал, что сейчас многое не так как раньше, а гораздо лучше, и я на это сильно надюсь, и даже отзывы на Glassdoor сменили свой крайне негативный окрас на очень позитивный (насколько они объективные сказать сложно, год назад наш CEO рассылал всем email с текстом вроде: “Для улучшения репутации компании было бы неплохо всем написать положительные отзывы о нас." Но хочется верить, что так оно и есть.)


Итак. Все более-менее, но план махнуть в Сингапур, Токио или Лондон, как планировалось в первой части откладывается на год. Не смотря на все свои злоключения я отчасти нахватался тех знаний, которые хотел получить покидая академическую среду, но этот вопрос до конца все еще не закрыт.


P.S. Завлекающая картинка в шапке — это вид с балкона, который я наблюдаю, когда вечером пью чай и думаю о смысле жизни.
P.P.S. В новый офис Bidgely так и не переехали.
P.P.P.S. Для тех, кому интересно, как может выглядеть резюме и LinkedIn под позицию Data Scientist в Кремниевой Долине:


Поделиться с друзьями
-->

Комментарии (29)


  1. lex-sey
    23.09.2016 12:06

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


    1. ternaus
      23.09.2016 19:46
      +1

      Спасибо.

      Я думаю, что анализ текущего рабочего места будет в следующей серии когда я перейду на следующую позицию, которая, по каким-то причинам мне понравится больше, чем то, что есть сейчас.

      Этот текст я написал, когда смог сравнить различные подходы, а именно Bidgely vs TrueAccord. Будет больше данных для сравнения, а именно Bidgely vs TrueAccord vs XXX — будет новый текст.


  1. Vjatcheslav3345
    23.09.2016 12:48

    Вопрос — а не легче ли в этом стартапе произвести разделение труда — один товарищь пишет быстро и, по возможности, правильно, правильно работающий код а другой -сразу же его только рефакторит пока он "горяч" и в промежутках рефакторит старьё — все равно там пара человек работает в сущности над одним и тем же? Тот же Алекс быстро говнокодит, а автор исходной статьи за ним идёт как фермер-перфекционист — в двойных рыбацких сапогах с лопатой.
    Маркировку наверное можно было бы проводить автоматом при сборе данных, используя знания о том, откуда пришел тот или иной пакет по сети (список адресов с информацией об установленном на адресах оборудовании наверняка есть).


    "Спрашиваю Алекса — а он опять говорит — ты говорит дебагером пробегись, да посмотри как и что эволюционирует. "

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


    1. ternaus
      23.09.2016 20:17

      Я думаю, что в тех компаниях, которым не требуется быстро развиваться, используется похожая схема Data Scientist пишет прототип, Software Engineer переписывает его и отправляет в production.

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

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

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


      1. Vjatcheslav3345
        23.09.2016 22:16

        Я не совсем это имел в виду — не нужно пихать датчики. Это делается на этапе заключения договора между поставщиком и потребителем энергии — тогда то и поставщик и получает список устройств потребителя с их установленной электрической мощностью, взятой из техпаспортов — дальше скачки мощности соответствуют мощности включаемых и выключаемых устройств из списка а продолжительность потребления данной мощности — подсказка о характере устройства — прерывистое равномерное потребление в течение многих, многих ночей и дней даст только холодильник, 5-минутные подъёмы в 1-1,5 кВт — скорее всего дрель или пылесос, утренние и вечерние подъёмы в 1-5 кВт — электроплита, более поздние 40 мин.- 2 ч. 1-1,5 кВт — стиралка.
        Все это дело передаётся по сети, одним датчиком — тем, что на электросчетчике, и можно, зная адрес с которого датчик дал данные, маркировать их автоматом по имеющемуся на адресе списку устройств.
        Кроме того, можно вспомнить про переходные процессы из электротехники и регистрировать их, если датчики счетчика это позволяют — они дадут конкретный "почерк" каждого устройства, подобный "почерку" радиста.


        Вообще же этот стартап, просто ещё один представитель поколения компаний "интернета вещей". "Интернет вещей" сейчас буквально из каждой щели лезет, — что бы вы сказали, например, если бы попали в положение одного из героев романов Ф. К. Дика, который однажды с утра не смог выйти на улицу — потому что у него не было денег, которыми можно было бы открыть требующую платы за открывание дверь квартиры — бред, да?
        Бред, бредом, но вот "охочие до денежек" вещи, пришедшие к нам из Завтра уже серийно производятся, и совсем скоро электроэнергию можно будет оплатить в своём электрощитке (кстати, не забудьте его закрыть на ключ — иначе туда установят банкоматный скиммер ...:)), — это электросчетчики марок СТК-1-10 и СТК-3-10, принимающие к оплате карты. Заодно поставщик энергии сможет предложить кучу тарифов, отключить, если потребитель превысил отведённый ему лимит электроэнергии или же закончилась предоплата за электроэнергию или же произошли не оговоренные договорами колебания мощности и/или напряжения.
        А что касается схемы разработки — ну так это неизбежное зло, но, если уж хочется избавляться от говнокода, то придётся сделать это так — Data Scientist делает плохую программную модель и постепенно добивается её правильной работы, затем переписывает результаты не в виде кода, а в виде систем математических уравнений, (кодовый прототип Software Engineer не получает), которые Software Engineer набирает набело "с бумаги".
        Кстати, в качестве рабочего языка конечной реализации, возможно, подойдёт Standard ML или Ada, — из-за их сверхмощной модульности, препятствующей расползанию говнокода, появляющегося из-за правок при эксплуатации, а прототипирование лучше вести на знакомом по аспирантуре лиспе, схеме или используя Agda, Cog, Isabelle (proof assistant), Maxima.
        Разные языки прототипирования и реализации как раз и гарантируют, защищают от соблазна "чуть допилить" прототип.


        1. ternaus
          23.09.2016 22:48

          Подход, который вы предложили, действительно сработает, но поставщикам электроэнергии это не надо.


          Стартапы вроде Bidgely предлагают им готовое решение, в виде работающего алгоритма, а то что у Bidgely нет отмаркированных данных — это проблемы Bidgely.


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


          В Питоне с этим все нормально, в Matlab более-менее, в Standard ML и Ada, насколько я знаю — никак.


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


          На днях был пост на эту тему. => https://habrahabr.ru/post/310310/


          1. Vjatcheslav3345
            24.09.2016 00:19

            Ну да, Вы писали в публикации про "клиентскую базу", которую набирают, чтобы жить за счёт долговременной работы с ними, при данном бизнес-поведении качество кода = низкие затраты на поддержку+долговечность программы.= выживаемость стартапа на последующих этапах. Я ориентировался на то, что буквально прочёл в статье.
            Ну, если с библиотеками остаётся, главным образом, питон, то для нетривиальных задач (машобучение имеет отношение к математической вероятности), попробуйте применить "вероятностные языки программирования" — может, проще и быстрее прототипы разрабатывать можно будет (пользуясь ими для "набросков" модели):
            https://habrahabr.ru/post/244625/
            https://habrahabr.ru/post/242993/


            1. ternaus
              24.09.2016 00:44

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


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


              И использование MatLab'а — это как раз нездоровый маневр, как минимум потому что нет IDE, которая поддерживает рефракторинг.


              Машинное обучение действительно имеет наипрямейшее отношение к математической вероятности, в половине алгоритмов это Maximum likelihood estimation.


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


  1. SKolotienko
    23.09.2016 13:10

    Я так понимаю, основные знания и практика в области ML были получены во время учёбы в Дэвисе? Или тут больше кагл повлиял?


    1. ternaus
      23.09.2016 20:00
      +2

      В Дэвисе я занимался Classical/Quantum Monte Carlo всех его вариациях, но никак не ML, правда на интервью в том году я утверждал обратное.

      Алгоритмы ML — это кагл + статьи, книжки, видео лекции. Как правильно поставить задачу, выбрать метрику, которая отвечает интересам бизнеса и сделать так, чтобы алгоритм заработал в production, так как должен — это уже на работе.

      Наверно, что-то по алгоритмам я и на работе выучился, но это пренебрежимо мало. Все таки у кагла по метрике знания в определенных областях ML в единицу времени конкурентов нет.

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


  1. ProRunner
    23.09.2016 15:52

    Так по какой визе вы сейчас там находитесь? H1B? Там же вроде не так легко попасть в квоту.


    1. lookid
      23.09.2016 16:02

      Какую квоту? H1B дается на компанию. 10к для майкрософта. 1-2 для стартапа из 7 человек. Главное найти компанию, которая тебе её выдаст.


    1. ternaus
      23.09.2016 20:00

      Пока на студенческой, то есть вопрос пока не закрыт.


      1. ProRunner
        23.09.2016 20:07

        То есть F1? Так по ней же легально только на кампусе можно работать.


        1. ternaus
          23.09.2016 20:27
          +3

          Мужик в конусльстве мне именно так и сказал.

          Есть тут такой финт, если ты на F1, можно подать на Optional Practical Training, то есть в теории — это вы чему-то научились в университете, а после этого в учитесь в индустрии.

          Но есть ограничение, работать можно на той позиции, которая связана полученние специальностью.
          «Связана» — это очень нечеткое понятие, но, например в MacDonalds'e кричать «касса свободна» мне нельзя. А вот в Data Science — можно, потому что и неспециалист поймет, что Data Science и физика как-то связаны.

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

          OPT — 1 год, в течение него можно не работать 90 дней
          OPT extension — еще два года сверху. OPT+OPT extension — в сумме можно не работать 120 дней.


  1. sergeyns
    23.09.2016 17:18

    Ну что ж, мое мнение о подходе индусских разработчиков к разработке (сорри за тавталогию) не изменилось…


  1. Strowitzki
    23.09.2016 17:18

    Спасибо за статью.


  1. Virtual77
    23.09.2016 20:01
    +1

    Ну все как в россии, не важно стартап или нет, не важна даже область, поверьте мне сменил много мест работы в россии, что у нас, что там все то же самое, куда-то бежим, делаем как попало заворачиваем в блестящую обертку, лишь бы клиент купил, нанимаем хорошего продажника — продаем. И в таком сумасшедшем ритме живут 80% компаний:)
    По крайней мере читая статью, у меня такое впечатление сложилось, везде все одинаково. :)


    1. SADKO
      23.09.2016 21:47

      Таки да, но всё же есть национальные особенности :-)


  1. Ilias
    23.09.2016 20:01

    а что значит «добрался до onsite, но отменил»? кто отменил? почему отменил?


    1. ternaus
      23.09.2016 20:05

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

      Так вот когда Google и Uber, написали что хотели бы пригласить меня к ним в офис на это oniste интервью я вежливо отказался.


      1. Ilias
        23.09.2016 20:21

        а почему, если не секрет? большие компании, вы им понравились.


        1. ternaus
          23.09.2016 20:50
          +5

          • Приглашение на onsite — это не предложение работы. Совсем не очевидно, что даже если бы мне сильно захотелось там работать — мне бы сделали офер.
          • Вакансия в Google была Quantitative Analyst — а это практически чистая статистика, а не машинное обучение. Не интересно. Вакансия была в их штаб квартире, а это в Mountain View, что опять же не интересно.
          • Uber — удачное расположение (их штаб квартира через дорогу от квартиры, что я снимаю). И позиция скорее мидл, с потенциально быстрым ростом до Senior, но там тоже не чистое машинное обучение, а микс всего со всем. Но про них я много думал.


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



  1. Stas911
    23.09.2016 22:58
    +1

    Монументально! Очень интересная статья, спасибо!


  1. 0xd34df00d
    25.09.2016 00:11
    +1

    Эх, питон, R, матлаб… Нигде хаскеля нет :(


    1. ternaus
      25.09.2016 00:20
      +1

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


    1. barmaley_exe
      25.09.2016 23:08
      +1

      В фейсбуке есть отдел Applied Machine Learning, где-то там пишут на Хаскелле (вот, например). Но оно и не удивительно, не зря же ФБ Саймона Марлоу нанял.


      1. ternaus
        25.09.2016 23:23
        +1

        Я бы с удовольствием вбухал время в Haskell, но под это нужна задача где он будет обладать серьезными преимуществами на фоне Питона.


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


  1. nikolay_karelin
    25.09.2016 20:44

    Спасибо за интересный материал!

    Я читал близкие вещи в книге «Analyzing the Analyzers», бесплатно доступна (после регистрации) на сайте O'Reily: http://www.oreilly.com/data/free/analyzing-the-analyzers.csp

    Судя по всему, вопрос взаимодействия разработчиков и ученых — это еще не совсем решенная проблема в индустрии…