Делится Desktop Lead в компании ENESTECH Software Константин Колесниченко.
Привет, меня зовут Константин Колесниченко. Я Desktop Lead в компании ENESTECH Software, входящей в холдинг TECHIIA. Поделюсь наработками, как в поиске опытных разработчиков находить «своих» людей и отсеивать недостаточно подготовленных. Статья рассчитана на начинающих лидов и тех, кто планирует стать руководителем. Кандидаты могут подсмотреть, чего ждать на собеседованиях. А опытным коллегам-менеджерам буду благодарен за отзывы и кейсы в комментариях.
В IT я работаю с 2004 года. За плечами — Кибцентр (Институт проблем математических машин и систем Национальной академии наук Украины), геймдев и разработка софта для мобильных телефонов. Последние годы работаю в ENESTECH Software, где собирал команду, строил рабочий процесс и возглавлял различные департаменты. Наш главный продукт — SENET — SaaS-сервис для компьютерных клубов и киберарен, который используют в 60+ странах мира. В команде разработки сейчас более 20 человек.
Поговорим о том:
- какова цена ошибки найма;
- что и зачем указывать в вакансиях
- на что смотреть в резюме, пет-проектах, на встрече;
- заставлять ли писать куски кода на листочке и как вообще построить собеседование;
- что делать в случае несовпадения.
Зачем заморачиваться правильным наймом
По моим наблюдениям, опытных разработчиков ищут прежде всего продуктовые компании и такие, у которых нет времени на долгую раскачку и обучение. «Опытный» означает, что человек встречался с реальными практическими задачами и находил решения. В идеале — знает, где искать и как. Или как минимум хочет найти.
Для других опыт не всегда важен. На разогретом рынке компании готовы брать людей чуть ли не со школы, чтобы научить их под свои задачи. Об этом поговорим позже.
Есть два этапа, на которых можно выявить неопытного разработчика. Первый и самый важный — собственно поиск и собеседование. Второй и маловероятный — во время работы, если вдруг вы пропустили «симулянта».
Люди с недостаточным опытом приходят практически на любую должность. Некоторые, проработав полгода, идут в соседнюю компанию, там могут предложить немного больше. Многие аутсорсинговые компаний к такому уже привыкли, но из-за этого необходимо особенно тщательно выбирать людей.
Каждый неэффективный найм имеет свою цену. Мы с коллегами из других компаний TECHIIA подсчитали, что ущерб от ошибки составляет 6-9 месячных рейтов специалиста. Иногда меньше, иногда больше. Если вам эта цифра кажется космической, вот несколько аргументов.
1. Менеджер тратит время на поиски и согласование. Вместо выполнения прямых обязанностей, он или она готовит требования, читает входной поток резюме от рекрутеров, участвует в интервью, дает фидбек, проверяет тестовые. Таких циклов может быть несколько.
2. Новый человек проходит адаптацию. Например, мы работаем над продуктом, поэтому шансы взять с улицы человека, который за неделю начнет выдавать результат, почти нулевые. В лучшем случае хватает месяца, в реальности нужно два-три. Все это время компания платит за то, чтобы разработчик:
- прочитал документацию;
- разобрался в нюансах продукта / проекта;
- поговорил с техническими и другими менеджерами;
- настроил процессы;
- влился в команду.
3. Менеджер, у которого есть свои задачи, тратит время на обучение новичка. Поэтому производительность команды в период онбординга может даже уменьшиться. В среднем лишь с третьего-шестого месяца специалист и команда выходят на тот уровень производительности, ради которого и брали новичка. И это нормально.
Если же взяли не того человека, ресурсы потрачены впустую. Для продуктовой компании крайне важны как деньги, так и время. Сделать свою часть работы, чтобы продукт или обновление вышли на рынок в запланированные сроки, — самое важное. Если этого не произойдет, то потеря денег на найм станет наименьшим злом. Ведь компания может упустить подходящий момент и уже никогда не выйти на желаемый рынок.
Как готовить вакансию
Прежде чем дать задание рекрутеру, определяем, чем именно человек будет заниматься. Это сохранит нервы и компании, и кандидатам.
Пример. Когда мы набирали команду для SENET, на бэкенд нам был нужен человек с трехлетним опытом на Python Django, который сразу включится в работу. По моему мнению, за три года человек как раз успевает пройти кучу различных задач и научиться их самостоятельно выполнять.
Но недостаточно сказать рекрутеру: «нужен питонист с трехлетним опытом Django». Потому что такой кандидат может и веб-страницы для магазина делать, и сложный бэкенд. У каждого — своя специализация. Кому-то нравится работать с базами данных, а кто-то пилит секьюрити или пишет мегаоптимальный код для работы с сетью. Поэтому мы указываем рекрутеру предметную сферу и части проекта, для которых ищем кандидата.
Далее следуют дополнительные пожелания:
- Образование. Желательно высшее профильное. Такие специалисты, по моему опыту, мыслят более системно. Исключения также есть: у нас есть разработчик без базового IT-образования, но это компенсируется талантом и огромным интересом.
- Язык. Английский хотя бы на уровне быстрого чтения и понимания.
- Технические нюансы. Условно, если ищем человека на Django, надо понимать SQL, базы данных. Для C++ - уметь работать с WinAPI, применять современные технологии и паттерны.
Ну и, конечно, описываем формат работы и бонусы. Не знаю, насколько пункты о дружном коллективе, кофе и печеньках нужны, но это уже вроде традиции. Тем более, когда это правда.
Вот . Перед финализацией мы просматриваем текст еще раз, чтобы убрать лишнее и зафиксировать нюансы, без которых кандидат не попадет на собеседование, например, опыт определенного домена.
Первые фильтры: базовые вопросы, резюме и пет-проекты
Перед первой беседой HR-менеджер согласовывает с заказчиком вакансии входной опросник. Обычно он касается опыта, но последние три года я выдаю также и «фильтрационные» вопросы.
Простой пример входного вопроса: «Что такое массив, что такое список, и чем они отличаются?». Мы помогли рекрутерам самим понять разницу, чтобы они сразу распознали, когда кандидат выдает ерунду.
В ходе опроса базовой теории отпадает до 90% бесперспективных кандидатов, особенно «senior’ы с годовым опытом».
Когда резюме попадает ко мне, прежде всего я смотрю на ответы по базе. Потом — на образование. Потом — на опыт. Скажем, кандидат работал в банке, потом полгода занимался QA, после чего стал программистом. Здесь будет много вопросов. Или, например, написано «10 лет С++, 15 лет Python», но при этом человек был сисадмином. Обязательно переспрошу рекрутера о профессиональном пути кандидата и сделаю себе пометку.
Также прошу примеры работ и петы. Если есть ссылка на GitHub, даже просто с тестовыми или университетскими лабами, — супер. Бывает, что человек не хочет светиться в поисковиках или работает под жесткими NDA. Тогда можно прислать примеры напрямую.
Независимо от типа кода, мне интересно, как человек пишет. Обращаю внимание на структуру, аккуратность, названия. Типичный маркер новичка — отсутствие своего стандарта: здесь с большой буквы, там с маленькой, здесь начинается с подчеркивания, там с двух. Копипасты со Stack Overflow тоже видно сразу. Скорее всего, во время живой встречи человеку будет трудно объяснить, для чего он использовал именно этот кусок.
На GitHub по истории коммитов можно увидеть, как код развивался. Иногда в проекте пара коммитов: первый — Initial, второй — остальной код, сваленный в кучу. То есть человек что-то набросал и больше не возвращался. Вряд ли это пет-проект, говорить о нем будет сложно.
Людей с интересными комбинациями «образование-опыт-примеры» и соответствующей специализацией зовем на встречу.
Блоки вопросов на собеседовании от базового до глубокого (но тоже базового)
Техническое собеседование в среднем длится час. Оно делится на следующие условные блоки.
1. Вопросы об опыте. Знакомимся, устанавливаем контакт. Когда человек рассказывает о прошлом и чем-то, что ему знакомо, он успокаивается. А я читаю резюме, немного погружаюсь в конкретику.
Здесь уместно спросить об увлечениях и предпочтениях. Можно взять специалиста, который ровно в шесть уходит с работы, а в свободное время переключается на совершенно другие проекты. Не всегда, но часто это признак того, что человек через некоторое время уйдет. Не потому что я ценю пустые овертаймы, просто заинтересованность другой работой рано или поздно победит.
Это касается и направлений. Например, если я возьму программиста на C#, который вне работы любит пилить фронтенды, есть риск, что однажды он туда и пойдет. Я так в свое время оставил научную деятельность и ушел в геймдев, где проработал 10 лет.
2. Общие вопросы. Их можно применить к любому языку программирования. Самое элементарное — о массивах и списках: что это, различия, скорость работы, что такое алгоритмическая сложность. Далее переходим к деревьям, хэшам, таблицам. Можно поговорить об алгоритмах сортировки.
Опытный человек прежде всего должен понимать базовые вещи. Где используются списки, а где — массивы. Почему в одном случае сортировать лучше «пузырьком», а в другом — «пирамидой». Необязательно, чтобы специалист умел это все делать руками, но должен знать и понимать, когда и как применить.
3. Более специфические вопросы в зависимости от позиции. Это все еще не о библиотеках, а о базовых принципах, присущих конкретному языку программирования.
В случае С++ и C# мне интересны знания ООП. Человек может на автомате выдать три принципа: полиморфизм, инкапсуляция, наследование. А полиморфизм — это виртуальные функции. Здесь я могу спросить: «А как вообще работают виртуальные функции?». Если человек знает и рассказывает о таблице виртуальных функций, это уже большой плюс. Это означает, что специалист разбирается в механизме, а не просто его использует. Такой подход показывает разработчика более высокого уровня, чем начинающий.
Иногда С++ разработчикам могу задать вроде бы глупые вопросы вроде «как минус один будет представлен в двоичной или шестнадцатеричной форме?» или «сколько будет 2 в 8-й степени?», «а почему именно так?», «что там с прямыми и дополнительными кодами?». Это позволит увидеть, насколько человек ориентируется в «битовой магии», которая для C ++ актуальна и сегодня.
Также на этом этапе, когда мы разговорились, могут хорошо сработать диагностические вопросы. Они показывают, насколько человек погрузился в тему.
Например, кандидата-джуна на C# можно спросить об утечках памяти. Есть сборщик мусора, который автоматически очищает память, и якобы последняя никуда утечь не может. Но на самом деле есть много кейсов, в которых это может произойти. Если человек объясняет несколько вариантов, это свидетельствует сразу о нескольких вещах. Первое — он вообще знает, что такое утечка памяти. Второе — знает, как ее получить. Третье — знает, как с ней бороться.
Опытного специалиста спрашиваю по тому же принципу, только глубже по каждому параметру. По Python-Django можно поинтересоваться, как человек работает с Object Relations Model. После нескольких вопросов видно, знает ли человек, в каком случае генерируется мегазапрос к базе, а в каком все быстро проработается с кэшированием данных.
Мой коллега практикует еще один подход. После нескольких стандартных вопросов он задает такой, на который человек, скорее всего, не знает ответа. Но сам ответ вторичен. Важно, как специалист будет мыслить и двигаться к решению, что будет вспоминать, на что опираться. И вообще возьмется ли. Например, как Python-программист сориентируется в задании об управлении памятью, которое больше свойственно для С++?
Технологии и языки изменяются, а вот способ решения проблем — вещь универсальная. И если брать в процентах, то знание технических тонкостей — это максимум 40% оценки кандидата. 60% — способ мышления и решения задач.
Благодаря тому, как человек ведет себя во время интервью, формируется понимание, кто передо мной: опытный человек или случайный кандидат. Одни думают и отвечают. Другие пытаются изменить тему разговора или переходят в атаку: «Не знаю, никогда не думал, кто этим вообще сейчас пользуется?». Для меня это плохая реакция.
Если же человек может объяснить или хотя бы понимает, куда копать, это уже хорошо. Даже если говорит, что пойдет в Google или на Stack Overflow, это уже активность. Есть у меня приятель, который на собеседованиях так и отвечал, не помня детали «пузырьков» или деревьев. И его нанимателя это устроило. Человек успел поработать в Lukas Arts, а сейчас — на senior-позиции в Microsoft.
Здесь можно спросить — а где же предел погружения в нюансы?
Зависит от специфики продукта и будущих задач человека. На собеседовании в геймдев меня спрашивали о виртуальных функциях, ортогональном базисе, векторном и скалярном умножении. Если вы ищете человека делать формы, необязательно его мучить битами и тонкостями памяти. Но тогда стоит спросить о массивах и таблицах, понять, насколько специалист может что-то сложить и посчитать.
Что лишнее на собеседовании
Есть несколько неписаных «НЕ», которыми я пользуюсь во время разговора с кандидатом.
1. Не устраиваю дополнительный стресс. Собеседование — и так неспокойная процедура для всех. Я не сижу с видом инквизитора, вбивая в кандидата вопросы, как гвозди. Важно, чтобы получился разговор двух специалистов. Нервозность затрудняет дискуссию для обеих сторон.
Часто выглядит так. Рекрутер дает вступительное слово и просит кандидата рассказать о профессиональном или личный опыт. Пока человек говорит и привыкает к нам и пространству, я ищу, где зацепиться за нужную мне тему, чтобы аккуратно вступить в диалог.
Вы делали игры? А как работали с персонажами? Как использовали модели? Ага, то есть у вас была общая модель, а из нее наследовали людей, лошадей, кошек?
Использовали список? А почему? Если бы вместо списка взяли дерево, что было бы?
Запрос из базы? Как организовывали саму базу? Какие критерии по времени обработки у вас были?
Как бы между прочим можно многое узнать о практическом опыте кандидата и глубине его знаний. Это лучший вариант — правда, сложноватый в реализации.
Бывает, человек теряется при ответе. Если это нервы, то после пары моих подсказок он подхватывает и развивает мысль. Если же не помогают и подсказки, скорее всего, кандидат ответа не знает.
2. Не прошу написать код на листочке. Собеседование и так многие воспринимают как экзамен, и я не хочу это усиливать.
Обсуждаем мы, скажем, принципы ООП, и я могу спросить: «Представьте, что у нас есть геометрическая фигура — квадрат или треугольник. Как будет выглядеть полиморфизм, наследование, инкапсуляция?». Стараюсь все разбирать устно, буквально на пальцах. Разве что человеку проще нарисовать. Мне важно не вылавливать блох в виде забытой скобки или лишней запятой, а понять глубину знаний. Синтаксисом пусть занимается машина.
Если для позиции важно посмотреть, как человек пишет, могу попросить сделать небольшой тест за пределами собеседования. Время для него кандидат выбирает сам — и тогда получает задание.
3. Не погружаюсь в знания очень специфической технологии. Мне не интересно, пользовался ли кандидат какой-то мелочью по обновлению PHP. Особенно, если шатается база.
Говорят, есть три степени познания: не умею пользоваться; умею пользоваться; умею не пользоваться. Нас интересует вторая категория, а также то, насколько человек быстро и самостоятельно учится новому.
Если вам кажется, что я очень много пишу о базовых знаниях, вам не кажется :) Возможно, это субъективизм. Но он совсем не мешает.
Несколько раз я экспериментировал: принимал людей, которые на верхнем уровне могли что-то рассказать, но фундаментальных знаний не имели. Впоследствии команда от этого только страдала. Человеку приходилось постоянно что-то глубже объяснять, доделывать за него или вообще переделывать.
Мой опыт показывает, что без базы человек не сможет решить даже немного сложную задачу — просто не будет знать, куда копать.
База, в частности, помогает проводить собеседования по разным специализациям. Например, на старте SENET мы искали бэкенд-программиста на Python Django, а фронтенд — на Angular. У меня нет опыта ни в том, ни в другом. Но, проверяя базовые знания, могу сделать вывод: человек понимает основы, которые можно применить абсолютно ко всему, следовательно, дальше он разберется.
4. Не обращаю внимания на особенности личности, если они не навредят команде. На собеседовании мы в частности согласовываем ценности, анализируем софтскилы человека, мысленно примеряем, впишется ли он в команду.
Но никаких оценок по типу активности. У меня в команде работал интровертный интроверт. Он тихо приходил на работу, тихо уходил домой. Не любил корпоративы, ни с кем не обсуждал свою личную жизнь. Лишь иногда удавалось на несколько минут его разговорить. Ему было комфортно, окружающим тоже — чего еще желать?
Однако это не касается собеседования. На него обе стороны приходят не меряться характерами.
Даже самые глубокие интроверты или умные умники заинтересованы отвечать на вопросы. Если мне отвечают сквозь зубы или говорят «всем и так известно, как эта штука работает, зачем вы это спрашиваете?», возможно, в этот момент мне забивают баки. Стараюсь максимально вывести на конкретику: и все же, как это работает, почему, для чего используется?
Для меня действует маркер — «как на собеседовании, так и в работе».
Человек не может знать все, но диалог есть, я вижу опору на предыдущий опыт и желание разобраться. Скорее всего, в работе будет комфортно.
А бывает, что начинается торговля с собой. Будто бы все хорошо, но... что-то не то. Здесь я стараюсь доверять себе. Опыт показывает, что поверхностность и ощущение работы спустя рукава переползет в каждодневное взаимодействие.
Коллеги иногда спрашивают: «Что делать с теми, кто сумел произвести впечатление, а в работе оказался почти нулевым?»
В моей практике таких не было. Собеседование — прекрасный лакмус. Конечно, можно вместо знаний зубрить ответы на каверзные вопросы и тренировать мегаскилы по забиванию баков. Но такие хитрецы мне не попадались. А если вдруг они и пролезут на должность, может, не все так плохо? В конце концов они что-то умеют, просто направляют свои усилия не туда.
Что делать в случае несовпадения
Часто говорю, что мне везло, потому что многих специалистов я брал с первого раза. Но случается, что позицию не удается закрыть ни после второго, ни после шестого собеседования. Тогда смотрю на текущую ситуацию.
Например, кандидат не тянет на нашу должность, но на джуна — вполне. Лет пять назад можно было бы внести его в шортлист и искать дальше. Сейчас людей везде не хватает. Если мы знаем, что все равно будем искать дальше и набирать команду, почему бы не взять талантливого специалиста, который через некоторое время вырастет до нужного уровня? Но этот вопрос нужно согласовать с ответственными за финансы и развитие компании.
Понятно, что в таком случае во время оценки кандидата приоритетными будут его желание учиться и интерес к продукту. Тогда и мы будем мотивировать и помогать. Если же человек ищет временный «запасной аэродром», нет смысла договариваться — на специалиста нельзя будет положиться в работе.
Отказывая, я стараюсь пройтись по компетенциям и вспомнить «слепые зоны» с собеседования. Четко сказать, каких знаний в какой сфере не хватает. Например, что нужно освежить понимание работы с памятью или битовую логику. Моя ответственность здесь — дать полезный фидбек, который поможет специалисту.
Таков мой опыт поиска опытных :) Он точно не аксиома — скорее, возможность обсудить подходы. А соискателям хочу пожелать сосредоточиться на базе — она поможет вам собрать в кучу разрозненные знания и выстроить нормальную компетенцию, с которой вы станете желанным кандидатом.
Оригинал статьи на
