Ищите код, а не резюме: найм программистов 2.0

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

Резюме - это сломанный телефон

У меня есть российское резюме на hh.ru ещё с тех времён когда "GPU" было ключом к интересному проекту. Потом "deep learning" затмил всё настолько, что оба термина уже не означают ничего конкретного. Тем временем, девочки-рекрутеры всё также фильтруют вакансии по ключевым словам. Сейчас это что-то вроде "full stack python C++", которое опять же ничего не означает. Забредший на мою страницу по "C++" рекрутер испугается зарплатных ожиданий и побыстрее пойдёт искать старшекурсника подешевле.

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

OpenSource - лучше, чем резюме

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

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

Как с этим работать рекрутеру?

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

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

Вам нужен даже не сам код, а метаданные репозитория, выгружаемые командой "git log":

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

Заключение

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

0
143 комментария
Написать комментарий...
Dmitry Mikushin
Автор

Во-первых, редкого специалиста вы увидите сразу. Например, мы искали спеца или консультанта по CoreMediaIO - во всем мире нашли человек 20, понятное дело не на HeadHunter, из них половину - по коду на GitHub.

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

Ответить
Развернуть ветку
Evgeny Tulikov

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

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

Мой подход как раз от ошибки и защищает. Opensource - это прозрачность, а прозрачность никому не вредит. Да, есть специфические сферы, где опенсорса мало, например банки. Я знаю истории, люди мучаются от того, что вне стен банка они никто, у них нет имени. Хотя, сейчас opesource есть даже в очень специальных конторах типа NSA.

Ответить
Развернуть ветку
Evgeny Tulikov

В какой-то степени я с вами согласен. Это может быть хорошим доп. инструментом по отсеиванию кандидатов. Но утверждать что opensource делает имя разработчику в корне не верно.
Опытные разрабы приходит на собеседование и через 10-15 минут получают оффер. И плевать им на публичный гит.

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

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

Ответить
Развернуть ветку
Evgeny Tulikov

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

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

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

Ответить
Развернуть ветку
Evgeny Tulikov

У вас либо мало опыта, либо много свободного времени чтобы заниматься opensource. Когда 8-10 часов в день работаешь над проектами клиентов, то вечером нет никакого желания сидеть за компом и показывать себя "большому миру".
И да, я не гордый, если бы нужно было искать работу, то точно не стал бы ждать пока мне напишет HR. Всегда можно и самому написать по вакансии, откройте linkedin и посмотрите, постоянно кто-то кого-то ищет. Но, почему-то, не имея красивого профиля на гите мне часто пишут с предложениями. Что это по вашему, везение?

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

В вашем изложении содержится понимание "проекты клиентов VS opensource" 10-летней давности, я уже говорил об этом. Сейчас уже никто не опенсорсит отдельно от задачи клиентов! И то и другое - на 90% одно и то же. 10% - какая-то кастомизация, контент, ключи доступа. Вы как бы работаете одновременно на двух работах, на двух аккаунтах, один из которых - лично ваш, и будет с вами всегда, с какой бы работы вы ни ушли.

Ответить
Развернуть ветку
Evgeny Tulikov

Нет. Представим я делаю клиентский проект, за который мне платят почасовую ставку. Клиент хочет быстрее запустить проект. Думаете он одобрит, что я отвлёкся на то, чтобы внести что-то в сторонний плагин, который я использую? Если бы я так всегда делал, то работы не увидел бы. Предпочитаю отплатить разработчику opensource проекта донатом и открыть issue, если нашёл что.

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

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

Ответить
Развернуть ветку
Evgeny Tulikov

Если честно, то не совсем вас понял здесь. Ну то есть да, он мне помогут, я возьму готовое решение и применю его в проекте. Дальше что? Если, например, axios работает как мне нужно, то с чего я должен коммитить что-то туда? Чтобы меня нашёл кто-то? Зачем? 
Как мне поможет то, что я коммитил в opensource при устройстве на работу по сравнению с проектами которые решали задачи предыдущего работодателя?

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

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

Ответить
Развернуть ветку
Evgeny Tulikov

Эм, мой проект использует, например, package 1.0.0, и будет использовать этот package обновляясь вплоть до 1.1.0, которая может сломать проект. А версии 1.0.1, 1.0.2 и так далее как правило не ломают ничего, соответственно нужды коммитить нет. Представим, вышла версия 1.1.0. Здесь встаёт вопрос, а нужно ли обновлять проект под новую версию, что это даст? 
Любой долгоживущий проект требует поддержки, так что это не аргумент. 

Ответить
Развернуть ветку
Dmitry Mikushin
Автор

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

Ответить
Развернуть ветку
Evgeny Tulikov

Не всегда, но да, такое возможно. Поэтому, исходя из опыта, я пользуюсь проверенными решениями, в которых ничего не нужно править внутри.
Ещё раз! Работодатель платит за результат. Вы, как разработчик, должны решить задачу так, чтобы в будущем минимизировать работы по поддержке и исправлению. Ну и работать оно всё, конечно же, должно. А ещё, по-хорошему, любой проект пишут по TDD, что практически исключает поломку проекта  в следствии  обновления сторонних решений. У вас попросту упадут тесты и всё. И вот как раз таки умение так выстроить проект и ценится работодателем, а не строчка кода в непонятно каком opensource проекте.

Ответить
Развернуть ветку
Vl Al

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

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