О том, как нанимать IT-специалистов

Разработчики — самые дефицитные IT-специалисты. По данным Hays, в 2018 году на одного разработчика приходилось до семи предложений по итогам собеседований. А судя по аналитике HeadHunter за прошлый год, 38% IT-вакансий приходятся на разработку и программирование.

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

Сегодня мы поговорили с Игорем Алексеенко, преподавателем HTML Academy и нашим первым экспертом React-направления. Он разработал систему трехэтапного скоринга для 6nomads. Мы попросили его рассказать, как он подходит к оценке разработчиков, на что особенно обращает внимание и может ли негигиеничный код просочиться на второй этап его строгого отбора.

В форме, которую заполняют на площадке разработчики, мы, разумеется, не спрашиваем их об образовании — только об опыте работы. А что ты думаешь о профильном высшем? Есть в нем смысл? Какое получал сам?

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

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

Первое — это выигрыш во времени: чем раньше приобретешь навыки, тем раньше сможешь начать работать.

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

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

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


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

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

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

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


Ты разработал трехэтапную систему оценки:
1. Гигиена кода
2. Использование React
3. Осмысленность кода и архитектуры.
Выходит, грязно оформленный код не имеет шанса пройти на второй этап? С такими разработчиками нет смысла работать, и исключений быть не может?

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

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


Cкажи, что думаешь про react.js и про фреймворки в целом

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

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


Как считаешь, достаточно зазубрить один фреймворк и выезжать на этом или ограниченность инструментария быстро выдаст? Раньше, например, были джеесеры, которые знали и умели пользоваться только jquery, где они сейчас?

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

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

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


Что важнее — умение решать задачи на условно инженерном уровне или владение языком программирования?

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


Расскажи про финальный этап. Что ты вкладываешь в понятие «осмысленность кода и архитектуры»?

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

Если смотреть с этой стороны, то использование любой технологии, библиотеки, фреймворка, конструкций языка и даже оформление кода должно быть осмысленным. Тогда споры React или Angular, ES6 или TypeScript и даже табы или пробелы отходят на второй план. На первый же план выходит вопрос: как их использование поможет разработчику решить задачу. Хорошо, когда разработчик выбирает React, потому что ему это подходит, а не потому что он вчера прочитал статью известного автора про React. Мы стараемся понять, насколько осмысленно разработчик подходит к выбору инструментов и насколько правильно их использует.


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

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