Предисловие

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

Завораживающее предисловие, не правда ли?

Я рас-с-с-скажу тебе о нас-с-с-с
Я рас-с-с-скажу тебе о нас-с-с-с

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

Начну с темы найма. Найма питонистов всех мастей. 

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

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

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

Итак, вот 5 конкретных позиций, на которые я искал питонистов или что-то близкое.

Web Developers

Первая позиция была самой простой и очевидной для меня. Занимаясь разработкой java-based веб-приложений много-много лет, я понимал, какими навыками должен обладать бэкенд-разработчик на питоне. Удивительным для меня оказалось то, что уровень подготовки по computer science у джавистов выше, чем в среднем у питонистов.

Обычно кандидаты на эту позицию:

  • Чаще всего знают django, реже fastapi,

  • Умеют работать с git`ом,

  • Немного знают sql и базы данных, чаще через ORM,

  • Не особо умеют в микросервисы и современные подходы к построению веб-приложений (например, асинхронное и многопоточное программирование не их конёк),

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

Поиск подходящих кандидатов занимал достаточно времени, толковых питон-бэкендеров очень мало.

Общая рекомендация: выбрать для бэка что-то более мейнстримовое, например, java. Это облегчит не только разработку, но и все devops-процессы в будущем.

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

BigData Developer

Эта позиция оказалась самой сложной в поиске. Таких людей крайне мало. Толковых ещё меньше. Сложности данной позиции:

  • Знание архитектуры data lake (delta lake в нашем случае).
    Для этого нужно бы разбираться и в реляционных БД, и в нереляционных тоже. Не путать партиционирование и индексирование, понимать стоимость хранения и перемещения данных

  • Знание питона как языка программирования (а не для анализа данных), высокие требования по computer science в принципе.
    Каждая строчка кода - “та же добыча радия, в грамм добыча, в годы труды”.

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

  • Понимание работы Apache Spark, особенно работы со стримингом.
    Переход от мышления “сейчас мы как-то обновим данные” к “добавление (append) данных быстрее и безопаснее, чем перезапись” - это как переход от феодализма к капитализму, сдвиг не меньшего уровня.

За два года - 3 (!) толковых кандидата. Всего три. Двое работают, один переехал в другую страну и вынужден был сменить работу.

Общие черты:

  • Самородки (чесслово),

  • Часто выходцы из дата-инженеров,

  • Владение git`ом - от среднего до очень хорошего,

  • Знание питона хорошее, но не всегда превосходное (вообще, похоже, что глубоко в питон мало кто погружается).

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

Общие рекомендации: искать долго, тщательно, за хорошие деньги, джуниоров на этой позиции быть не может; если брать “на вырост”, то только с очень хорошим бэкграундом и с крайне острым умом.

Тестовые задания обязательны. Цена ошибки в найме крайне высока.

Если сами не сильны в питоне и в BigData, то обратитесь за помощью.

Data Engineer

Здесь как бы всё понятно, но ничего конкретно. Нужны были люди, кто хорошо знают SQL и нормально знают Python. Чтобы и данные могли селектить из 10 таблиц с 5 джойнами и 42 группировками, и в Датабриксе потом могли на питоне поработать с этими данными в DataFrame`е. И понимали, как работают дата-пайплайны.

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

Толковых кандидатов, подходящих под наши требования, оказалось не так много.

Общие черты дата-инженеров:

  • Абсолютно разный бэкграунд. От greenplum’а до Informatica. От визуального построения ETL-процессов до хардкорного программирования. Кто-то не подходил нам, кому-то не подходили мы.

  • В основном хорошее знание SQL и баз данных в принципе. Что логично на данной позиции.

  • Неплохое знание Python. Возможны другие языки, но редко.

  • Computer science почти нет, но он тут и не очень нужен.

  • Очень редкий опыт работы с системами контроля версий. Что требовало дополнительного времени на онбординг.

  • Акцент на решение конкретных задач, поиск конкретных решений четко поставленных задач.

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

Отдельная песня (точнее плач Ярославны) - поиск Data Quality Engineer в команду дата-инженеров.

После десятка первых собеседований были оставлены 2 тестовых задания на SQL (написать 2 запроса на 5 строк буквально) плюс несколько теоретических вопросов, например, про определение качества данных.

В начале были ошибки в найме: около 30% первой волны найма были уволены. Потом стало лучше. И те изначальные 70% работают до сих пор. И хорошо работают, надо сказать.

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

Data Analyst

Аналитики. Отвечают на конкретные вопросы про конкретные данные. Могут (и должны) разобраться в хитросплетении таблиц и зависимостей в БД. Ждут чётко определённых задач, тогда работают прекрасно. 

Могут нарисовать красивые дашборды под конкретные данные.

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

Питон в основном используется как инструмент анализа данных (Pandas, numpy), навыки именно программирования минимальны. 

Умение работать с git`ом - редкость.

Data Scientist

Несмотря на обилие курсов по data science, людей, кто в этом действительно разбирается, мало. Дать ответ на основе xgboost могут многие, объяснить почему он такой получился - нет.

Если кратко сформулировать отличия от аналитиков, то:

  • Аналитики ищут ответы на вопросы, которые мы знаем,

  • Сайентисты ищут ответы на те вопросы, которые мы даже не знаем как задать.

Общие черты выделить сложнее, потому что кандидатов на Data Scientist было немного. Тем не менее:

  • Умные люди, пришедший в data science из других областей. Хотя бы из той же аналитики. Видимо, богатый жизненный опыт - одно из требований поиска ответов на неизвестные вопросы.

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

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

  • Зато они понимают что такое “feature” и даже “feature store”.

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

  • Нацелены на уникальные задачи, не на построение приложений или систем.

Конкретные тестовые задания должны быть схожими с реальными задачами на вашей работе. 

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

Послесловие

Для меня найм питонистов стал большим открытием. Позиции оказались разными, кандидаты ещё более разнообразными. После нескольких лет поиска java backend developer’ов и веб-разработчиков с таким разнообразием нужно было освоиться. Сейчас набраны 3 команды по 8-12 человек, каждый разработчик выполняет свои задачи. Около 33 питонистов и получилось в итоге.

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

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

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


  1. Mirzapch
    29.11.2022 15:38

    5 Джонов слишком мало для 42 группировок. Принцип Дирихле не позволяет.


  1. prohvost
    29.11.2022 15:39
    -1

    Сам работаю в ИТ уже более 20 лет. Программист. Почитал, любопытно, интересно. Так, для информации принял. Спасибо!
    Убивает лишь стилистика... До отвращения. Море "умных" en-терминов, имеющих в великом и могучем русском языке вполне внятные, корректные синонимы. Но, на вкус и цвет, как говорится.
    В целом, познавательно.


    1. Kipriz Автор
      29.11.2022 15:44

      Да, бывает я говорю русско-английском суржике, некоторые термины понятнее в оригинале. 17 лет работы с иностранцами дают о себе знать.

      Буду рад примерам подходящих переводов.


      1. Mirzapch
        29.11.2022 16:04
        +2

        Суржик - гибрид русского и украинского языка. Русско-английский - Рунглиш, русслиш, руглиш, или русинглиш. Трасянка - гибрид белорусского и русского.

        Но интересно другое. Что вы делаете с сэкономленными предлогами?

        говорю русско-английском суржике


        1. Kipriz Автор
          29.11.2022 16:50

          Предлоги исчезают из речи ближе к полуночи =) Телеграм-стайл, так сказать.

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


  1. GothicJS
    29.11.2022 20:31

    Поиск подходящих кандидатов занимал достаточно времени, толковых питон-бэкендеров очень мало.

    Общая рекомендация: выбрать для бэка что-то более мейнстримовое, например, java. Это облегчит не только разработку, но и все devops-процессы в будущем.

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


    1. Kipriz Автор
      30.11.2022 00:17

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

      Взаимозаменяемость разработчиков на уровне языка стоит того, чтобы разобраться в тонкостях питона.

      Мы выбрали питон для бэкенда, и проект состоялся. Если бы выбрали джаву, то проект бы тоже состоялся. Как всегда главная сложность была в самой предметной области.


      1. AI4
        30.11.2022 18:54

        А как насчёт разницы в производительности? Или в данном проекте она не критична?


        1. Kipriz Автор
          30.11.2022 19:40

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


  1. megamrmax
    29.11.2022 22:46

    Несколько недель назад тут была статья со статистикой резюме. Питонисты там в первом ряду....видимо всякие Войтивайти пекут их со страшной силой - а вот девать некуда. Да и качество выпечки зачастую не соответствует ГОСТу


  1. Andrei1038
    30.11.2022 16:51

    Сейчас каждый, кто умеет писать print('Привет Мир!') считает себя программистом.