Найм разработчиков

Привет, Хабр!

Это моя первая статья!

Хочу поделиться с вами своим мнением и наблюдениями о процессе подбора персонала в разработке.

Думаю, мои наблюдения также могут быть применены в других направлениях.

Статья будет интересна следующим лицам:программистам,HR, Teamleads, директорам HR, IT.

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

Предлагаю принять во внимание следующее:

1. В статьеделюсь только своими мыслями и опытом. Я не могу никого учить. Делайте выводы сами.

2. Все совпадения случайны.

3. Подбор персонала - крайне сложная и ответственная задача.

4. У нас у всех мало опыта, век живи век учись.

Немного о себе:

Мне 30+ лет, работаю уже почти 10 лет IT менеджером в компании ( штат более 500 чел ). На текущий момент моя группа занимается улучшением продуктов компании , также разработкой программ для клиентов и сотрудников. За 10 лет мне приходилось нанимать, обучать, руководить большим количеством людей - в общей сумме более 60 человек. Многие из них "выросли" из начинающих инженеров - в серьезных (разработчики, автотестировщики, devops). На данный момент они работают в TOP IT компаниях России.

Тактика:

Итак, начнем.

1) Убедитесь что ваше/кандидата резюме прочитано

Два года назад я решил попробовать себя в роли мобильного разработчика. На тот момент уменя был опыт 1 год разработки мобильного pet-project. Было 1500 скачиваний, 300 активных пользователей. Я откликнулся на предложение одной из ТОР компаний России.

Читаю описание, вижу что по тех части я подхожу, по руководящим задачам тоже. Отправил отклик и, к моему счастью, меня пригласили! Вау! Я сразу представляю кучу бабок , успех, карьерный рост). Приехал на собеседование, его проводил руководитель IT департамента и какой-то другой руководитель, наверное его зам. Что сказатьстарший был ровно из тех типичных менеджеров , каких любят у нас в России. Возрастом от 40+, полненький на вид, напористый, уверенный в себе. Начали беседу, она длилась не долго, минут 30 . По его разговору я понял, что я ему не нравлюсь. Что именно он спрашивал я не помню, но помню что сказал в конце.

Он: "Знаешь чем отличается опытный разработчик от новичка?".

Я: "Нет".

Он: "Опытные указывают в своем резюме крупные, долго-играющие проекты, со сроком реализации 2-5 лет, а новички напишут в своем все подряд, разных терминов наберут".

Я ушел расстроенный, понял, что мне отказали.

На протяжении где-то полугода я размышлял о его словах и меня, как менеджера , не покидали размышления:

1. Я указал в своем резюме все как есть, ничего не выдумывал, лишнего не указывал.

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

3. Как так вышло, что такой опытный руководитель, по времени он явно былбольше меня на руководящей должности, у которого ЗП больше меня раз в 5, штат сотрудников больше раз в 20, такой матерый и уважаемый человек пригласил меня и сказал, что я ему не подхожу по очевидным и банальным вещам и так понятных из резюме?

4. Он потратил минимум 30 минут своего времени и зама, работа HR, я потратил 1 час на дорогу. И это все просто так? А где же профессионализм, свойственный рук. департамента? В чем заключается ТОП менеджмент?

В итоге , где-то через полгода, меня осенило в чем было дело - просто он не читал мое резюме до встречи, а читали во время. Данный факт подтверждает то, что он озвучил недовольство моим опытом как разработчика, хотя он явно и полностью был описан. Также в разговоре он сослался на глагол "пишут", то есть ему было важно что у меня именно описано. Ну что ж бывает. Занятой человек, ему наверняка было не до этого, сами поймите тех.дир! Только мне от этого не легче, 1,5 часа впустую.

После данного случая я стараюсь поступать следующим образом:

Если бы я был Team lead: Обязательно,до назначения встречи, внимательно прочтите опыт кандидата.

Плюсы: Это сэкономит вам время. Если есть странные моменты, попросите HR их уточнить и дать вам обратную связь.

Минусы: Потратите свои силы, время. Соответственно их не хватит на другие задачи.

Если бы я был HR: Убедитесь у Team lead что он действительно внимательно прочел резюме до встречи. Как вариант можете задатьему уточняющие вопросы, например: "Тебя не смущает что у него опыт всего 1,5 года?", "У него указан опыт коммерческой разработки 1 год, но нет ссылок на продукты, что можешь сказать?", "Тебя устраивает как у него описан опыт с RxJS?", "Смотри у него есть опыт с docker, что у него спросить про это?". Может хотя-бы в этот моментTeam lead (ЛПР) придет в себя и прочитает хотя-бы пару строк из резюме внимательно.

Плюсы:Это может сэкономит вам время. Есть вариант не пригласить кандидата в пустую, если это учитывается в вашем KPI , то для вас это самый раз.

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

Если бы я был Кандидат: Уточните у HR, что ваше резюме прочитали, обязательно сделайте это до приезда в офис или собеседования по Skype. Во время собеседования вежливо спросите читали ли все кто принимает решение о найме ваше резюме. Все люди занятые , запросто могут этого не сделать. Если нет, попросите их прочитать, только потом начинайте собеседование. Сошлитесь на то, что это важно для "эффективной" траты времени, как их так и вашего.

Плюсы: Это может сэкономит вам время.

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

P.S У вас может сложиться мнение, что я пишу какую то ерунду, ну не прочитали резюме и что с этого? Мы то всегда читаем. А с чего ты взял что они его не прочитали, может ты им просто не понравился или нагрубил?

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

Я продолжил свои размышления как менеджер Хорошо, допустим тех.дир не прочел, а HR куда смотрела? Она же предварительно его резюмировала, у них с тех.диром были договоренности, согласование вакансии, описание профиля кандидата, ее работу как понять? Спустя пару месяцев я разгадал и этот пазл.

2) Что очевидно мне - очевидно тебе!

Несколько лет назад до этого собеседования, бизнес-тренер моей компании объяснил мнеодну вещь: "Что очевидно мне - очевидно тебе". Идея в том что при объяснение какого-либо предмета, постановки задачи мы автоматически, точнее по лени, считаем что у собеседника такое же понимание , опыт и видение задачи, предметной области как и у нас.

Например, руководитель в первый раз просит своего подчиненного: "Сделай мне отчет о вчерашних продажах", тот говорит: "хорошо!". И тут вуаля, вылезает сюрприз! Дело в том что в русском языке слово "отчет" является очень абстрактным понятием, и каждый из собеседников представляет себе разную структуру, содержание и полноту отчета. Первый считает что отчет будет выглядеть так как он ожидает - с 7 колонками и 5 графиками. Второй представляет себе тот отчет, который он делал вчера - с 2 колонками и без графиков). Оба результата называются словом "отчет". В итоге , после того, как сотрудник сделает отчет, руководитель , посмотрев и не увидев того, что ожидает, скажет, а может даже заорет: "Ты что тут налепил? Как мне в этом разобраться?"

Чтобы избегать этогоя следую двум простым правилам:

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

2. Уточнять правильность понимания поставленной задачи исполнителем .

Например вот как выглядит "классическая" постановка задачи при поиска кандидата:

Заказчик: Привет HR, у меня уволился разработчик, найди мне, пожалуйста, такого же, только не хуже, можно побыстрее?

HR: Ммм) Хорошо, а не хуже это как? Опишите его, пожалуйста, подробнее.

(Как заказчик представляет егосебе: Знает rxjs: relaySubject, mergeMap, sheduler, как избегать утечек памяти при подписках, как создать утечку памяти, как применять rx декларативно. может объяснить когда плохо и хорошо логирование клиентских логов на сервере и как это сделать, lazy loading, идеально знает разницу межу mvp/mvc/mvvm. может с нуля на голом js реализовать hello world по mvp/mvc/mvvm)

Заказчик: Ну от 2 лет коммерческой разработки, javascript, angular, rxjs, git, jira.

HR: Просматривает резюме кандидатов, видит резюме: "Опыт 1 год,javascript,git, jira. angular." (Что реально знает кандидат:rxjs: switchMap, map. Наangular делал проект уровня hello world)

Т.к. у HR нет подробного описания вакансии и ей не с чем сравнить,у нее срабатывает эффект: вижу то, что хочу и т.к. у нее горят сроки, то.

(HR звонит кандидату)

HR: Здравствуйте, ваше резюме показалось нам очень интересным, вы не хотите пройти у нас собеседования на позицию "разработчик".

Кандидат: ( ууху! Фартуна, лотерея! Куча бабла и тачки.) Да конечно! Я все могу! Куда приезжать?

Аналогичная ситуация происходит когда кандидат сам делает отклик на вакансию.

Кандидат: Открывает вакансию, видит описание:

"2 года коммерческой разработки, javascript, angular, rxjs, git, jira."

Думает: "Ну я уже 1 год делаю сайты на javascript. Пару сайтов делал на Angular. Знаю пару операторов в rxjs, git, jiar тоже без проблем, давай попробую". Откликается.

HR: Получает отклик, видит что у кандидата почти такой же опыт как и в требованиях и приглашает его на собеседование.

Применительно к найму,формализацией поставленной задачи, является детальное описание профиля кандидата.

Я думаю, в идеале, это должно выглядеть так:

- Описание минимальных требований:

Тут нужно указать тот минимум которым должен обладать кандидат. При этом нужно описать его так, чтобыу кандидата, желательно и HR, было бы такое же понимание терминов как и у заказчика.В данном пункте,я считаю, нужно описать, минимум 15 параметров, чем больше тем лучше. Каждый параметр должен быть раскрыт минимум в 3х примерах. При этом, на мой взгляд, желательно описывать типовой функционал кандидата. Знания, опыт которые он может получить, найти в интернете за пару часов описывать не имеет смысла. ( поясню подробнее в другой статье).

- Описание максимальных требований (идеальный кандидат)

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

- Расписать почему идеальный кандидат выберет именно вашу компанию.

Лучше понимать по какой причине, идеальный кандидат, выберет именно вас, а не более известную, крупную компанию с большим бюджетом на "HR рекламу". Например ТОР IT компаний России. Почему кандидат на позицию "React developer" пойдет в "Ромашка и КО" вместо "Яндекса","Mail","Avito" etc если у них открыты такие жевакансии с аналогичными требованиями? Возможно в этом случаем вам стоит снизить требования как к идеальному, так и к минимальному кандидатам.

Иначе будет классический лозунг: "Мы ищем кандидата, да такого такого. чтобы все и сразу, да с опытом 2 года. А почему ? Да потому что мы классные и у насоткрыта вакансия!".

Приведу примеры:

Не правильный профиль идеального кандидата:

Идеальный кандидат - Билл Гейтс

Задачи: Править верстку в лендинге.

У нас есть конкуренты? - полно.

Мы ему интересны? - нет, т.к он миллиардер и у него куча денег, зачем ему наши 80 000 руб. в месяц?.

Правильный профиль идеального кандидата:

Идеальный кандидат - Билл Гейтс

Задачи: Встать во главе нашего сервиса, на стеке компьютерных и биотехнологий.

У нас есть конкуренты? - нет, т.к. в нашей команде есть уникальные специалисты мирового уровня.

Мы ему интересны? - скорее да, т.к он интересуется данной сферой, его наверняка заинтересует наша команда и потенциал роста в мировом масштабе.

Как бы я поступил если бы я был:

Team lead: Расписал бы подробно минимальные, максимальные требования к кандидату.

Тут стоит отметить что именно можно указывать в минимальных требованиях, например:

1. Перечисление библиотек, модулей, подходов хотя бы 15 штук.

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

3. Перечислить какие архитектурные задачи нужно решать с каждой из библиотеки,модулем, подходом

4. Перечислить какие бизнес задачи нужно уметь решать на базе данной архитектуры.

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

Например:

RxJs:

а) Уметь применять на практике - sheduler, forkJoin, catchError, takeUntil, retryWhen.

б) Уметь подписаться на http запрос , отписаться от него по событию, в случае HTTP ошибок подписаться повторно.

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

Расписал для себя причину выбора кандидатом моего предложения. Почему он долен выбрать именно меня? Этим может стать: более низкий порог входа чем у конкурентов (вы берете кандидата с меньшим опытом, но с большим потенциалом и никто его кроме вас , на данную позицию и оклад не возьмет), условия туда, время на дорогу, карьерный рост, наставничество и т.д.

Плюсы: Подробное описание поможет вам на собеседовании , например вы можете задавать нужные вопросы по тех части, озвучить для кандидата плюсы работы с вами. Также подобное описание можно улучшать с помощью "цикла деминга". Например если вы пригласили кандидата, а на собеседовании выяснялось, что он что-то не знает, не умеет, вы можете просто добавить это в мин. требования. Для бизнеса это дает прозрачность контроляпроцесса подбора. В случае ухода "тим-лида", нового легче будет ввести в курс дела, быстро передать ему уже имеющийся опыт. Можно вносить корректировки подбора исходя из целей компании. Теперь новые кандидаты и HR будут знать, что для вас важно, и на следующее собеседование, у вас повышается шанс получения более релевантного кандидата.

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

HR: Требуйте от тим-лида (заказчика) подробного описания минимальных требований, минимум 15 строк по 3 пункта на каждую строку.

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

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

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

Плюсы: Экономия времени, вы можете не обладать какими-либо критичными знаниями, зачем это узнавать на собеседовании?

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

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

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

50% было отказ, 50% были приглашения. И что же я видел в приглашениях?

Компания 1:

Это было мое самое первое предложениена позицию Tem Lead. К сожалению я не сохранил описание их вакансии.

Суть что у них совершенно другой стек технологий, нежели тот, которым я обладал на тот момент. У них был React/Vue/Nest/ , я знал Angular/Node.js.

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

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

Я запрашиваю у них минимальные требования.

Мне отвечают

В итоге я получаю на почту тот же текст что и в описании вакансии.

Если бы они написали что им наfrontend достаточно опыта с одним из фреймворков например: Angular, React,Vuew и на backend: Node.js, Nest.js я бы пошел. Но этого не было. Тратить время в пустую у меня не было желания. И я им не стал отвечать.

Компания 2

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

Например:

1)JavaScript и TypeScript, CSS (Flexbox и Grid) - какие библиотеки, подходы нужно уметь применять?

2) Какие архитектурные задачи нужно уметь решать?

3) Какие бизнес задачи нужно уметь решать?

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

Я надеялся получить развернутый ответ, но в итоге получил:

Честно я был в недоумении. Как так выходит что компания готова оформлять сотрудника официально,платить ему оклад, ДМС, пенсионные выплаты, прочие расходы и при этом не представлять кто именно им нужен, и каким образом их HR хотя бы поверхностно отличить релевантного кандидата от не релевантного?

1. Где подробное описание минимальных тех. знаний?

2. На основе чего HR поймет что кандидат ей подходит, не подходит?

3. Что HR спрашивать у кандидата?

4. Как HR или заказчик поймут сможет ли потенциально ли кандидатрешать их бизнес задачи или нет?

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

Компания 3

Поступило еще одно приложение на позицию разработчика.

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

Непонятно, каким минимум должен обладать разработчик.

1. Реактивные формы нужно уметь использовать?

2. RxJS какие операторы нужно уметь применять?

3. Какие стейт менеджеры уметь применять Ngrx, MobX, Ngxs?

4. Какие библиотеки уметь применять?

5. Как быть unit, e2e тестированием, уровня hello world хватит?

6. Что нужно уметь тестировать - компоненты, сервисы, верстку, e2e тесты?

Я решил попросить у HR подробное описание.

Получил ответ:

Отлично! Ни кандидат, ни HR не понимают кто кому подходит и единственный шанс это выяснить - прийти на собеседование!

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

В итоге выходит классическая схема:

1. HR приглашает всех у кого в резюме есть слова похожие на те, что им предоставил заказчик (Тимлид).

2. Тимлид не внимательно читает резюме которое HR приносит ему на согласование. Либо также как HR смотрит на наличие "ключевых" фраз, например: "Опыт разработки backend на NodeJs 1 год". И ему кажется, что это релевантный кандидат, при этом он не перепроверяет, что именно кандидат подразумевает под данным понятием.

3. В итоге кандидата приглашают

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

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

Компания 4

Вот еще один пример описания вакансии разработчика одной очень известной компании

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

А что на счет минимальных тех. знаний?

1. Typescript 4

2. React 17

И все!

• А если я знаюTypescript и React на уровне hello world я подхожу?

• Если я не знаю оператор "keyof" в Typescript это критично?

• Что значит "middle/senior"?Ведь у каждого кандидата и работодателя разное понимание "middle/senior". Есть ссылка на руководящий документ однозначно их описывающий, например ссылка на RFC?

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

Заключение

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

Я думаю, что по аналогии с военными, нам - заказчикам, также страшно при поиске нового персонала. Нам закрадывается мысль: "Если я возьму плохого, кто отвечать будет?" И в следствии защитной реакции мы придумываем себе волшебные слова "серебряные пули" в надежде что они сами по себе решат все наши проблемы. Кандидаты сами будут понимать подходят они или нет и откликаться будут только действительно классные и нужные ребята. И подобно тем военным, мы выстреливаем в интернет слова:Middle, Senior,2 года коммерческой разработки, Spring Boot, Nodejs, Angular, Kubernates.

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

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

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

P.S.

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

Пишите ваши комментарии - буду рад обратной связи от всех!

Привет! Хочу поделиться своим мнением об оформлении вакансий по поиску разработчиков. Я сам разработчик, руководитель команд в разных компаниях, составлял вакансии и нанимал. Часто вижу вакансии, которые никогда не будут успешны.

Плохая вакансия

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

Чем это чревато:

• Часть потенциальных кандидатов просто-напросто игнорируют такие вакансии, хотя их ценности и желания могут совпадать с тем, что предлагает компания. Компания теряет кандидатов.

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

• Плохая вакансия размещена на платных ресурсах на потенциально больший срок. Компания тратит больше денег.

Примеры плохих вакансий: DOU, HH, Djinni, LinkedIn. Если вы смотрите ссылки, а вакансии внутри не доступы, значит, прошло уже много времени с момента публикации статьи.

Хорошая вакансия

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

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

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

Плохо: молодой международный быстроразвивающийся проект, лидер на рынке доставки продуктов питания.

Хорошо: EasyFood это мобильное приложение, где можно заказать доставку продуктов из магазинов на дом. Покупатель выбирает продукты, заказ берет один из курьеров, едет в магазин, набирает продукты и привозит по адресу. Наши пользователи покупатели и курьеры. Мы сотрудничаем с магазинами типа Ашан, Магнит, Билла. Наша цель сделать доставку продуктов доступной и быстрой для каждого.

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

Плохо: не указывается.

Хорошо: 2 миллиона пользователей, 15 миллионов доставок в месяц. К концу года мы планируем уменьшить time to house на 20 процентов, до 40 минут и делать 20 миллионов доставок в месяц.

Команда. Расскажите про работников компании.

Плохо: талантливый и дружный коллектив.

Хорошо: над продуктом трудится несколько команд (в сумме больше 50 инженеров): фронт-энд, бэк-энд, бизнес-аналитики, дата-сайентисты, тестировщики, мобильные разработчики на iOS и Android, product и project менеджеры, фаундеры активно принимают участие в процессах. Ты будешь работать в команде из 4 дата-сайентистов, будешь активно взаимодействовать с вышеперечисленными командами каждый день.

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

Плохо: не указывается.

Хорошо: покрываем 100% кода тестами на pytest; поддерживаем 25 микросервисов, написанных на Go, Python, и Java, в GCP c Kubernetes; для хранения кода используем Github.

Требования. Указывайте четко сформулированные и реальные требования к кандидату.

Плохо: Python, Django, PostgreSQL, знание микросервисов, самостоятельность.

Хорошо: знает Python не только в контексте фреймворков; был опыт написания веб-приложений и RESTful API; знает и умеет масштабировать базы данных; знает как мониторить и оптимизировать запросы к базе данных; понимает преимущества и недостатки микросервисной архитектуры; может собрать и прояснить требования, написать код и покрыть тестами, развернуть на продакшене.

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

Плохо: не указывается.

Хорошо: опыт работы в продуктовых компаниях; свои open source проекты либо вклад в чужие; английский на уровне Advanced (C1).

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

Плохо: интересные проекты.

Хорошо: сделать алгоритм подбора доставщиков продуктов питания быстрее; сделать модель машинного обучения для рекомендаций к продуктам, которых нет в наличии в магазинах; поддерживать инфраструктуру; участвовать в технических обсуждениях, предлагать идеи новых фич, улучшать процессы разработки;

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

Плохо: команда профессионалов, нет бюрократии.

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

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

Плохо: не указывается, либо указывается с большим разбросом типа $1500-4500, что, зачастую, сигнал для кандидата о недобросовестности компании.

Хорошо: указывается, с маленьким разбросом $2500-3300, или вообще без.

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

Плохо: не указывается.

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

Ссылки. Познакомьте кандидата с вашей компанией, продуктом, командами, культурой заранее.

Плохо: не указывается, нормально, наверное, только для очень известных компаний.

Хорошо: кратко и понятно о самой компании от фаундера можно найти здесь (ссылка); наши ребята из команды бэк-энд активно выступают на конференциях, посмотреть можно здесь (ссылка).

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

Заключение

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

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

Один из интересных и не очень часто освещаемых вопросов ИТ-менеджмента расширение команды инженеров и ошибки, которые можно совершить на этом пути. Я сам активно развиваю свои проекты и поэтому интересуюсь этой темой. Мне удалось поговорить с Алиной Зурабовой, Head of Engineering and Testing в компании Smartcat. Этот стартап с российскими корнями, который развивает платформу управления переводами и привлек более $14 млн. Соответственно, за последние пару лет серьезно выросла и его техническая команда.

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

Введение: зачем понадобилось расширять команду

За несколько лет активной работы мы устаканили видение продукта, поняли, как именно он должен выглядеть хотя бы на текущий момент понятно, что все может меняться. Мы разобрались с тем, кто наши клиенты, какие у них боли и проблемы то есть нащупали, как говорят в США, product/market fit.

В частности, стало ясно, что наша модель это all-in-one-product, то есть мы хотим сделать систему, которая покрывает все бизнес-процессы пользователей разных ролей внутри индустрии переводов. Здесь есть и заказчики, которым нужно как-то получить перевод, и компании-поставщики таких услуг, а есть конечные исполнители, которые переводят контент. Мы хотим автоматизировать работу каждого участника этой цепочки.

При этом под капотом:

• извлечение переводимого текста из файлов офисных форматов,

• куча ассинхронных операций, выполняемых на процессинге расчет статистики, поиск глоссарных терминов, индексация миллионов unitов из баз переводов,

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

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

• система биллинга и инвойсирования, работающая в интеграции с разными платежными провайдерами),

• и т.п.

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

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

Урок #1: структура внутри команды не должна ограничивать рост

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

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

От этой модели при расширении команды пришлось отказаться по ряду причин:

• звено менеджера стало бутылочным горлышком, bus factor начал зашкаливать;

• выросло количество запросов к системе / пожеланий от пользователей;

• наблюдалась потеря информации в узлах передачи информации от клиента к разработчиками;

• сформировалось понимание продукта, на которое не ложилась текущая схема работы, продукт большой, и все не могут разбираться во всем, слишком разные процессы. Да и все за все" не есть структура, давайте не будем забывать про знаменитый знаменитый закон Конвея.

Начали думать, как изменять модель, чтобы победить все эти сложности. В итоге (ничего нового я вам не открою) пришли к тому самому Scrum-процессу. Каждая команда отвечает за один из элементов цепочки продукт для заказчиков перевода, сервис-провайдеров или конечных исполнителей, задачи дробятся в рамках этих направлений (платежи, подбор исполнителей, отчетность и т.п.) Такую систему можно без проблем масштабировать и адаптировать под потребности бизнеса, да и потери и TTM (Time To Market) там меньше.Одним из важных шагов на пути прихода к такому сетапу стала книжка Hyper Growth, если бы знала о ней раньше могли бы пройти некоторые шаги и сделать открытия гораздо быстрее. В общем, да, рекомендую к прочтению всем IT-менеджерам, потом не забудьте сказать мне спасибо за 70 листов отборной полезной информации.

Урок #2: нужно четко планировать расширение команды и адаптировать процессы

Приведу вам пример расширения команды, на котором мы многому научились:Это было в самом начале работы над продуктом мы делали cat-систему, куда просто загружается проект, а затем делается перевод. То есть основной юзкейс такой: у компании есть свои переводчики, и они в режиме мультиюзера переводят проект в нашей системе, используя большую пачку дополнительных ресурсов для ускорения процесса (памяти переводов, МТ, словари и прочее). Функции подбора внешних исполнителей, взаимодействий с ними и оплаты тогда не было.

Первый шаг на пути тестирования гипотезы all-in-one-product заключался в создании еще одного важного компонента системы маркептлейса исполнителей.

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

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

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

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

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

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

• мы успешно протестировали гипотезу маркетплейса, т.е. по сути мигрировали к себе уже готовый клиентский продукт (нам не надо было еще раз экспериментировать и тратить на это время);

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

Урок #3: в стартап нужно нанимать особенных инженеров

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

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

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

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

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

Выводы: о чем помнить при расширении IT-команды в стартапе

В завершение, еще раз выделим ошибки и возможные решения:

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

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

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

Делитесь своими примерами трудностей при развитии технической команды в стартапе соберем максимально полный список проблем и решений в комментариях!

IT-компания Omega провела вебинар Рекрутмент это вам не рекрутинг. Вместе с экспертами digital-рынка искали ответы на главный вопрос 2021 года: как эффективно искать идеальных разработчиков.

Представители IT-индустрии рассказали на собственных примерах, как они справляются с трудностями в поиске сотрудников, какие инструменты используют, как проводят собеседования и проверяют soft-скиллы.

В вебинаре участвовали генеральные директора и представители HR-направления компаний Holyweb, Globus, BSL, IT Test, Open Solutions, Extyl, Omega, а также несколько десятков представителей других IT-компаний. В первой части речь шла о стандартных и необычных инструментах поиска сотрудников. Сегодня делюсь ключевыми моментами из выступлений о том, зачем разработчику необходимо обладать развитыми soft-скиллами, может ли HR-менеджер обойтись без технического специалиста при оценке hard-скиллов соискателя и как должен выглядеть процесс оценки hard-скиллов.

О необходимости soft-скиллов для разработчиков

Максим Кравец, CEO компании Holyweb

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

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

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

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

Денис Чекрыгин, исполнительный директор компании IT Test

Когда мы в течение пяти лет работали без HR-специалиста, мы всегда искали людей по hard-скиллам и имели проблемы с soft-скиллами. У нас бывали случаи, например, когда мы нанимали классного специалиста, но он был токсичен. Рано или поздно приходилось с этим человеком расставаться.

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

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

Алина Пенчук, HR-директор компании Extyl

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

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

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

Кроме этого, задаём вопросы не только о его достижениях, но и о факапах. Это показывает, насколько объективно кандидат оценивает себя.

Вера Муравьева, HR-менеджер компании Omega

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

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

Об оценке hard-скиллов соискателя без участия технического специалиста

Алина Пенчук, HR-директор компании Extyl

Оценить hard-скиллы без технического специалиста невозможно. Тот, кто собеседует, должен иметь глубокие знания в разработке. Даже если у HR-специалиста будет список технических вопросов, он ничего не поймет и отнимет время у кандидата.

У нас кандидат сначала общается с рекрутером, а затем происходит собеседование по Zoom в один этап: на нём присутствует и HR, и IT-директор, и тимлид. Это позволяет нам делать оффер быстрее.

Максим Кравец, CEO компании Holyweb

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

У нас ежемесячно проходит 70-90 первичных собеседований. Поскольку мы работаем в узкой нише JS-разработки, уже на первом собеседовании рекрутер задаёт несколько технических вопросов и тем самым отсеивает откровенно неподходящих кандидатов со слабыми hard-скиллами. Далее техническое собеседование проводит тимлид или техлид. Ежемесячно мы проводим около 12-15 технических собеседований.

Дарья Рязанова, HR-директор компании IT Test

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

Поэтому первоначально мы качественно отбираем резюме и общаемся с кандидатом по телефону. А уже на втором этапе проводим глубинное интервью вдвоём или втроём с техническими специалистами и делим разговор на три этапа: вопросы от HR, технические вопросы и вопросы соискателя. Оно длится не меньше одного часа. После этого HR и технический специалист дают друг другу структурную обратную связь о кандидате и принимают совместное решение. Это позволяет сэкономить время подбора и видеть кандидата объемно, оценивая сразу и soft-, и hard-скиллы.

Сергей Костин, CEO компании BSL

В BSL после первичного просмотра откликов и поиска резюме HR-менеджер созванивается с кандидатом и проводит базовый анализ soft-скиллов. На этом этапе можно проверить готовность соискателя к общению.

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

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

Для успешного прохождения необходимо верно выполнить 60% заданий. Тестирование позволяет отсеивать слабых кандидатов, определять их сильные и слабые стороны, проверять базовые знания и соответствие стеку. Таким образом, мы не тратим время кандидатов и наших специалистов, исключаем конфликты между HR-ами и техническими специалистами о качестве кандидатов. Кроме этого, мы также привлекаем middle-разработчиков на проведение технических собеседований в качестве элемента обучения. Например, в случае собеседования junior-разработчика нет большого смысла тратить время тимлида это может сделать middle.

Далее соискатель попадает на техническое собеседование, в позитивном варианте получает оффер и проходит испытательный срок. По итогу года работы пяти HR-специалистов мы за год выросли на 70 человек. Сейчас в BSL работает более 120 сотрудников, при этом каждую неделю выходит 1-2 новых сотрудника еженедельно.

Инга Морозова, руководитель партнёрской сети компании Globus

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

17-18 октября совместно с McKinsey&Company в рамках инициативы Next Generation Women Leaders провели NGWL.HACK исключительный онлайн-хакатон.

Нужно было собрать вместе девушек, увлеченных Data Science. Мы понимали, что это достаточно узкая аудитория к сожалению, девушек в этой области пока не так много, как хотелось бы всего около 28% по исследованию Forbes. В итоге мы получили 700 заявок из 23 стран! В команды отобрали 156 участниц. Уже на самом хакатоне осознали, что покрыли почти все часовые пояса некоторые участницы специально не спали ночью или вставали на заре, чтобы выйти в эфир.

Хакатон для девушек в Data Science идея McKinsey&Company

Московский офис McKinsey&Company занимает особое место для компании в отношении Data Science и является центром компетенций целого региона. В него входят Россия, СНГ, Турция, страны Африки и Ближнего Востока. С помощью анализа больших данных компания помогает клиентам найти интересные инсайты, причины проблем и пути их решения. Офис растет и требует новых специалистов.

Также один из фокусов McKinsey&Company гендерное равенство. Они хотят развеять миф, что Data Scientist не женская профессия. В компании в Data Science направлении девушки уже работают, но их количество планируют увеличить. А хакатон отличный способ познакомиться с талантливыми специалистами.

Мы тоже замечаем и считаем важной проблему неравенства полов в сфере IT, особенно на российском рынке. Но не без света в конце туннеля женщинам в IT рады все больше. Хакатон исключительно для девушек в Data Science крутая инициатива от McKinsey&Company, которую мы с удовольствием подхватили. Подошли к NGWL.HACK как к смелому эксперименту это первый масштабный хакатон исключительно на девушек в узкой области IT.

Задача хакатона смоделировать отток клиентов Сбермаркета

Сбермаркет быстро развивающийся сервис по доставке продуктов из супермаркетов, который присутствует в 157 городах России. За пандемию доставили свыше 5 млн заказов. Для осознания масштаба, чтобы доставить первый миллион, Сбермаркету понадобилось 7 лет.

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

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

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

В организации хакатона сделали упор на нетворкинг

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

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

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

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

А для создания атмосферы продуктивного нетворкинга позвали двух спикеров девушек, добившихся больших успехов в сфере IT: Эмели Драль (Co-founder, Evidently AI) и Любу Юдасину (Ex-PM, Airbnb).

Эмели Драль поделилась личным опытом в найме и руководстве командой, а также поведала об основных отличиях между работой в ML-стартапе и крупной IT-корпорации.

Люба Юдасина рассказала о том, как отучилась в Канаде на химического инженера, стала software engineer в Airbnb, перешла на Product Management и в итоге ушла в свой стартап.

Дискуссия оказалась настолько жаркой, что участницы задержались ещё на 40 минут!

И про самих участниц. Для нас было важно собрать самых талантливых представительниц направления Data Science. Все получилось конкуренция оказалась весьма высокой: отбор прошла только каждая 6 заявка, среди участниц оказались представители топовых IT-компаний, выпускницы и магистры лучших вузов.

В итоге получили 34 решения, 9 из них оказались выше base line!

NGWL.HACK подарил нам важный инсайт делая фокус на узких аудиториях, можно получить желаемый результат и даже больше. В нашем случае были два сужающих фактора исключительно девушки и интерес к Data Science. Получился душевный по атмосфере ивент с крутой отдачей. При этом изначально участницы почти не были знакомы сдружились за два дня.

Также получили очередное подтверждение, что хакатон один из лучших способов знакомства со специалистами. По словам старшего рекрутера McKinsey & Company Лики Андреевой, главная ценность NGWL.Hack заключается в том, что он помог пообщаться с талантливыми девушками в неформальной и уютной атмосфере. Онлайн-формат убрал границы и позволил познакомиться с участниками из разных стран и городов.

И финальное. NGWL.HACK доказал, что команды исключительно из девушек отлично решают задачи с применением знаний в IT, не уступая парням по результатам.

Мы дали сложную задачу, очень много сырых данных, но участницы смогли быстро разобраться с датасетом и показать отличную точность своих моделей. Однако больше всего нам понравилось то, как девушки провели Exploratory Data Analysis и помогли нам найти много новых инсайтов про клиентов. Многие полученные инсайты легли в нашу коммуникационную маркетинговую стратегию так отозвался о результатах хакатона Дмитрий Зборовский VP Data & Growth Сбермаркета.

Как сказал Александр Финагин операционный руководитель отдела Data Science McKinsey&Company в Москве: NGWL.HACK маленький шаг для каждого из нас, но большой для комьюнити!.