В предыдущей статье про внедрение в нашем стартапе методологии Agile я частично затронул вопрос управления персоналом. В этой статье расскажу как мы этот персонал набираем, какую классификацию применяем, какими испытаниями и методами проверяем их профессионализм и адекватность.
Как в любой молодой компании, наша работа в области подбора персонала начиналась с выработки рекрутинговой модели. Ситуация обстояла следующим образом: у нас уже была команда “коренных” сотрудников, все они были хайскилл и работали на senior – позициях. Этих людей надо было как-то разгружать, то есть необходимости добирать компетенции рыночными специалистами не было, поэтому в период активного расширения штата, подавляющее число вакантных мест было позициями джунов. Перед тем, как разместить вакансии на рекрутинговых площадках мы, решили составить свою внутреннюю классификацию по уровню квалификации и по требованиям, предъявляемым к разным категориям разработчиков.
Была выведена следующая классификация:
0 уровень – fullzero-разработчик, человек прошел пару курсов, усвоил основные конструкции и семантику какого-то языка, почитал несколько статей на хабре по хайповым темам, в итоге от программиста там максимум наклейка на ноутбуке.
1 уровень – junior-разработчик, человек, который отлично пишет код, хорошо разбирается в стеках, находится в курсе текущих трендов, умеет самостоятельно декомпозировать задачу и решать ее.
2 уровень – middle-разработчик, человек обладает всеми вышеперечисленными качествами junior, а также способен выразить свое компетентное мнение по решаемой задаче на основе анализа ресурсов, и может влиять на ход ее выполнения в рамках, выбранного им тулчейна.
3 уровень – senior-разработчик, он же руководитель, он же отец-батюшка, человек, который трансформирует и проектирует задачи из бизнес-плоскости в плоскость разработки, распределяет эти таски по мидлам и джунам, контролирует и помогает с их выполнением.
К этой классификации добавлялись еще такие критерии как: знание нашего тулчейна, адекватность, опыт работы порядка 1-2 лет, и хотя бы один успешно реализованный проект, умение четко выражать мысли, наличие навыков коммуникации, способность признавать свои ошибки и недостатки (здоровая самокритика — это мощный инструмент). Приоритет по набору, как уже было сказано выше, ставился на junior-разработчиков, так как наш опыт общения с мидлами, показал, что, как правило, эти люди уже испорчены каким-то стеком технологий и “уникальными” подходами других компаний. Кроме этого практика показала, наличие большого количества людей на рынке, привыкших к существованию в жесткой вертикальной структуре, где к ним на стол попадает альденте материал из разжеванных задач, который остается лишь набить в виде кода, а задача сеньоров — бить палкой по голове за косяки. Только вот дело в том, что когда действие происходит в молодом стартапе, а в команде всего около тридцати человек, каждый из которых загружен под полный бак, то времени на персональную декомпозицию для каждого сотрудника нет, так как это будет равносильно выполнению этой задачи. В таких условиях, когда написание кода занимает примерно десять процентов от общего времени выполнения таска, необходимо включать не только пальцы, но и голову. Именно это и написано в “библии” всех программистов – Стивен Макконел “Идеальный код” он же Redbook (не путать с американским женским журналом).
Кого только к нам не заносило, начиная от персонажей, которые считают, что они middle потому, что написали целое приложение на Android, у которого целых 37 скачиваний на Google Play, заканчивая людьми, которые считают себя супер синьорами, потому что работали ведущими разработчиками в какой-то студии, хотя их работа, по большому счету, сводилась к приемо-передаче задач от отдела проектирования в отдел разработки, то есть у них не было опыта ни в проектировании, ни в управлении разработкой, а было лишь много амбиций и куча гонора. Были и такие, кто с семимесячным опытом программирования считал себя синьорами, и требовали зарплату 240к, при этом не решая даже элементарных задач для джуниоров. С нашей точки зрения эти люди не были даже джунами. Подход простой, если человек программирует прям от души, он просто программист, если же человек плохо программирует или вообще не тянет, он не джуниор, он просто не программист. Здесь нам помог замечательный лайвхак по отсеву таких кандидатов, называется он “Закон Сантехника”, который гласит: “Каждый новый сантехник приходя на новое место работы поливает грязью другого сантехника, говоря, что у того руки-вантузы, и что теперь придется все делать с нуля”. На практике это работает примерно так: приходит соискатель на должность джуниора, ему дают какой-нибудь готовый кусок кода, например, фрагмент ядра Linux, и спрашивают, что он думает по данному решению? Если он начинает плеваться и говорить что-то вроде: “Что за рукожоп это писал? Здесь надо все переделывать! Дайте мне время, и я напишу все заново”, значит перед вами сантехник, и его первоочередная задача – это ругать предыдущего сантехника.
Микеланджело по этому поводу говорил так: “Я беру камень, отсекаю все лишнее.” Великий мастер не писал скрипты, зато хорошо понимал, что грамотный человек подходит к объекту работы с желанием его понять и при необходимости преобразить, но никак не разрушить и превратить в пыль. То есть если человек на такие вопросы отвечает: “Если код работает в продакшене и выполняет свои функции — это уже хорошо, в отдельных местах я считаю можно улучшить этот код, при необходимости могу показать.”, то с таким человеком можно и нужно продолжать диалог.
Еще одним приемом по определению low-skill джунов это фокус на хайп и хайповые стеки. Если человек приходит на интервью и начинает сыпать трендовые подходы, а на законный вопрос: “С чего ты сделал такой вывод, и проводил ли ты анализ этих инструментов?” — скорчив гримасу, достигшего просветления сеньора, отвечает: “На Этом можно написать все что угодно, за Этим будущее!”, то перед вами в лучшем случае слабенький джуниор, у которого нет никакого анализа ресурсов, стеков и прочего тулчейна, лишь поверхностная информация по хайповым инструментам и подходам.
Помимо вышеперечисленного при найме программиста очень важно получить от него открытую позицию по его знаниям в том или ином стеке. Вы определяетесь со стеком, и он выбирает язык, в котором он “вай вай вай как силен”, допустим он горец JavaScript. Есть готовый набор задачек, например, такая:
Если на вопрос по этой задаче: “Когда будет выведен «Hello World!» ?”, он начинает запинаясь отвечать в стиле: “ Ну…эээ…воот…после выполнения цикла while true или через одну секунду” — это значит, что он абсолютно не знает стек, врет о своих скилах, которые, скорее всего, близки к нулю. Дело в том, что конструкция while загрузит препроцессор, а так как JS однопоточный, то основной цикл никогда не заэмитит событие от таймера. Т.е. правильный ответ — никогда.
Если человек не готов адекватно и честно оценивать свои знания, не способен читать чужой код, то о какой работе в команде может идти речь. Если же человек не проявил себя в качестве “сантехника” и справился с задачками, подтвердив свои знания стека, либо конструктивно отнесся к задаче, своим ошибкам и частичной некомпетентности, то есть шанс, что он станет вашим новым сотрудником, и в перспективе сможет расти в сторону более высоких уровней классификации.
Бывают случаи, когда человек не согласен с внутренней классификацией фирмы, и негативно реагирует, на заявление, что он не тянет на мидла или даже на джуна, и что его решение не будет работать. В таком случае, если он продолжает настаивать, можно пойти на принцип, и запустить его решение в среде, естественно эта конструкция оказывается нерабочей, то есть человек зафакапился. Тогда он может начать давить авторитетом своей предыдущей работы. Например, были случаи, когда человек после такого провала заявлял, что он был очень ценным сотрудником какого-нибудь крупного банка и его там очень ценили. А на деле оказывается, что в этом банке работало еще двенадцать тысяч таких как он, и HR отдел просто проглядел его некомпетентность, и проторчав там около годика, теперь он заявляет о своем статусе специалиста. А здесь, где работает команда порядка двадцати программистов, каждый из которых отлично владеет своим делом, он просто потеряется не в силах работать по прежней клерковой схеме. Наш CEO Илья Быконя по этому поводу говорит так: “ Для меня, как для действующего разработчика и учредителя фирмы, авторитет один — это скилл человека, а где он работал, и какая должность у него была, имеет второстепенное значение.”
Возможно в нашем подходе по оцениванию соискателей есть изъян. И то, что мы “понижаем его в звании”, говоря, что он не мидл, а джун или еще хуже, играет с нами злую шутку. Быть может мы теряем будущих Наполеонов, как в свое время Российская Империя? Кто знает… Но с нашей точки зрения, такая стратегия вполне оправдана своей эффективностью, ну и в конце концов, Наполеон все равно проиграл войну Российской Империи.
Рекрутинговая модель
Как в любой молодой компании, наша работа в области подбора персонала начиналась с выработки рекрутинговой модели. Ситуация обстояла следующим образом: у нас уже была команда “коренных” сотрудников, все они были хайскилл и работали на senior – позициях. Этих людей надо было как-то разгружать, то есть необходимости добирать компетенции рыночными специалистами не было, поэтому в период активного расширения штата, подавляющее число вакантных мест было позициями джунов. Перед тем, как разместить вакансии на рекрутинговых площадках мы, решили составить свою внутреннюю классификацию по уровню квалификации и по требованиям, предъявляемым к разным категориям разработчиков.
Была выведена следующая классификация:
0 уровень – fullzero-разработчик, человек прошел пару курсов, усвоил основные конструкции и семантику какого-то языка, почитал несколько статей на хабре по хайповым темам, в итоге от программиста там максимум наклейка на ноутбуке.
1 уровень – junior-разработчик, человек, который отлично пишет код, хорошо разбирается в стеках, находится в курсе текущих трендов, умеет самостоятельно декомпозировать задачу и решать ее.
2 уровень – middle-разработчик, человек обладает всеми вышеперечисленными качествами junior, а также способен выразить свое компетентное мнение по решаемой задаче на основе анализа ресурсов, и может влиять на ход ее выполнения в рамках, выбранного им тулчейна.
3 уровень – senior-разработчик, он же руководитель, он же отец-батюшка, человек, который трансформирует и проектирует задачи из бизнес-плоскости в плоскость разработки, распределяет эти таски по мидлам и джунам, контролирует и помогает с их выполнением.
К этой классификации добавлялись еще такие критерии как: знание нашего тулчейна, адекватность, опыт работы порядка 1-2 лет, и хотя бы один успешно реализованный проект, умение четко выражать мысли, наличие навыков коммуникации, способность признавать свои ошибки и недостатки (здоровая самокритика — это мощный инструмент). Приоритет по набору, как уже было сказано выше, ставился на junior-разработчиков, так как наш опыт общения с мидлами, показал, что, как правило, эти люди уже испорчены каким-то стеком технологий и “уникальными” подходами других компаний. Кроме этого практика показала, наличие большого количества людей на рынке, привыкших к существованию в жесткой вертикальной структуре, где к ним на стол попадает альденте материал из разжеванных задач, который остается лишь набить в виде кода, а задача сеньоров — бить палкой по голове за косяки. Только вот дело в том, что когда действие происходит в молодом стартапе, а в команде всего около тридцати человек, каждый из которых загружен под полный бак, то времени на персональную декомпозицию для каждого сотрудника нет, так как это будет равносильно выполнению этой задачи. В таких условиях, когда написание кода занимает примерно десять процентов от общего времени выполнения таска, необходимо включать не только пальцы, но и голову. Именно это и написано в “библии” всех программистов – Стивен Макконел “Идеальный код” он же Redbook (не путать с американским женским журналом).
И тут нас накрыло волной…
Кого только к нам не заносило, начиная от персонажей, которые считают, что они middle потому, что написали целое приложение на Android, у которого целых 37 скачиваний на Google Play, заканчивая людьми, которые считают себя супер синьорами, потому что работали ведущими разработчиками в какой-то студии, хотя их работа, по большому счету, сводилась к приемо-передаче задач от отдела проектирования в отдел разработки, то есть у них не было опыта ни в проектировании, ни в управлении разработкой, а было лишь много амбиций и куча гонора. Были и такие, кто с семимесячным опытом программирования считал себя синьорами, и требовали зарплату 240к, при этом не решая даже элементарных задач для джуниоров. С нашей точки зрения эти люди не были даже джунами. Подход простой, если человек программирует прям от души, он просто программист, если же человек плохо программирует или вообще не тянет, он не джуниор, он просто не программист. Здесь нам помог замечательный лайвхак по отсеву таких кандидатов, называется он “Закон Сантехника”, который гласит: “Каждый новый сантехник приходя на новое место работы поливает грязью другого сантехника, говоря, что у того руки-вантузы, и что теперь придется все делать с нуля”. На практике это работает примерно так: приходит соискатель на должность джуниора, ему дают какой-нибудь готовый кусок кода, например, фрагмент ядра Linux, и спрашивают, что он думает по данному решению? Если он начинает плеваться и говорить что-то вроде: “Что за рукожоп это писал? Здесь надо все переделывать! Дайте мне время, и я напишу все заново”, значит перед вами сантехник, и его первоочередная задача – это ругать предыдущего сантехника.
Микеланджело по этому поводу говорил так: “Я беру камень, отсекаю все лишнее.” Великий мастер не писал скрипты, зато хорошо понимал, что грамотный человек подходит к объекту работы с желанием его понять и при необходимости преобразить, но никак не разрушить и превратить в пыль. То есть если человек на такие вопросы отвечает: “Если код работает в продакшене и выполняет свои функции — это уже хорошо, в отдельных местах я считаю можно улучшить этот код, при необходимости могу показать.”, то с таким человеком можно и нужно продолжать диалог.
Еще одним приемом по определению low-skill джунов это фокус на хайп и хайповые стеки. Если человек приходит на интервью и начинает сыпать трендовые подходы, а на законный вопрос: “С чего ты сделал такой вывод, и проводил ли ты анализ этих инструментов?” — скорчив гримасу, достигшего просветления сеньора, отвечает: “На Этом можно написать все что угодно, за Этим будущее!”, то перед вами в лучшем случае слабенький джуниор, у которого нет никакого анализа ресурсов, стеков и прочего тулчейна, лишь поверхностная информация по хайповым инструментам и подходам.
Еще немного про интервью
Помимо вышеперечисленного при найме программиста очень важно получить от него открытую позицию по его знаниям в том или ином стеке. Вы определяетесь со стеком, и он выбирает язык, в котором он “вай вай вай как силен”, допустим он горец JavaScript. Есть готовый набор задачек, например, такая:
setTimeout(()=>{console.log('Hello World!')}, 1000);
while (true) { let a = false; };Если на вопрос по этой задаче: “Когда будет выведен «Hello World!» ?”, он начинает запинаясь отвечать в стиле: “ Ну…эээ…воот…после выполнения цикла while true или через одну секунду” — это значит, что он абсолютно не знает стек, врет о своих скилах, которые, скорее всего, близки к нулю. Дело в том, что конструкция while загрузит препроцессор, а так как JS однопоточный, то основной цикл никогда не заэмитит событие от таймера. Т.е. правильный ответ — никогда.
Если человек не готов адекватно и честно оценивать свои знания, не способен читать чужой код, то о какой работе в команде может идти речь. Если же человек не проявил себя в качестве “сантехника” и справился с задачками, подтвердив свои знания стека, либо конструктивно отнесся к задаче, своим ошибкам и частичной некомпетентности, то есть шанс, что он станет вашим новым сотрудником, и в перспективе сможет расти в сторону более высоких уровней классификации.
Бывают случаи, когда человек не согласен с внутренней классификацией фирмы, и негативно реагирует, на заявление, что он не тянет на мидла или даже на джуна, и что его решение не будет работать. В таком случае, если он продолжает настаивать, можно пойти на принцип, и запустить его решение в среде, естественно эта конструкция оказывается нерабочей, то есть человек зафакапился. Тогда он может начать давить авторитетом своей предыдущей работы. Например, были случаи, когда человек после такого провала заявлял, что он был очень ценным сотрудником какого-нибудь крупного банка и его там очень ценили. А на деле оказывается, что в этом банке работало еще двенадцать тысяч таких как он, и HR отдел просто проглядел его некомпетентность, и проторчав там около годика, теперь он заявляет о своем статусе специалиста. А здесь, где работает команда порядка двадцати программистов, каждый из которых отлично владеет своим делом, он просто потеряется не в силах работать по прежней клерковой схеме. Наш CEO Илья Быконя по этому поводу говорит так: “ Для меня, как для действующего разработчика и учредителя фирмы, авторитет один — это скилл человека, а где он работал, и какая должность у него была, имеет второстепенное значение.”
Подытожим
Возможно в нашем подходе по оцениванию соискателей есть изъян. И то, что мы “понижаем его в звании”, говоря, что он не мидл, а джун или еще хуже, играет с нами злую шутку. Быть может мы теряем будущих Наполеонов, как в свое время Российская Империя? Кто знает… Но с нашей точки зрения, такая стратегия вполне оправдана своей эффективностью, ну и в конце концов, Наполеон все равно проиграл войну Российской Империи.
