О том, можно ли нанять мобильного разработчика без тестового задания, надо ли проводить ему «экзамен» на знание всех ключевых слов из резюме и какие ошибки не стоит совершать, мы поговорили с Александром Черным, одним из спикеров нашей AppsConf.
Александр Черный — руководитель мобильной разработки в Pandao — одном из проектов электронной коммерции Mail.ru. В его подчинении команда из 15 человек: часть в штате и часть - на подряде. Подбором персонала всегда занимался сам.
— Какую роль ты играешь в собеседованиях мобильных разработчиков?
Первые официальные деньги за программирование я получил в 2006 году. Следующие 5 лет я выступал только в роли того, кто проходит собеседования. Потом была закономерная ступень в виде лида по одному из направлений — по iOS, тогда, если не считать несколько разовых эпизодов, я и начал подбирать людей в свою и смежные команды на регулярной основе. Так что я довольно давно участвую в собеседованиях с разных сторон. В роли нанимателя я провел сотни интервью, на одну только последнюю позицию я посмотрел чуть больше 50 человек.
— Есть ли какое-то отличие найма именно в мобильной разработке?
В разработке в принципе есть дефицит кадров. Могу поверхностно утверждать, что в мобильной разработке этот дефицит выше, чем в среднем по отрасли.
— В целом не хватает специалистов или именно квалифицированных?
Оба варианта. Причем если речь идет о нехватке навыков, то «хромает» в большей степени техническая часть.
— А на какого рода специалистов ты ориентируешься при поиске?
В найме мы по большей части ориентируемся на специалистов уровня мидл и выше.
В принципе, джунов мы тоже берем. Вот, последнего взяли около 1,5 месяцев назад — и для него это первое место работы. Но в целом наш фокус — мидл+.
— Какие ошибки совершают наниматели в этой сфере в процессе поиска сотрудников?
Первая проблема, которую я вижу, заключается в том, что компании плохо формулируют требования к кандидату, не до конца отдавая себе отчет, зачем вообще нанимается новый человек. Как правило, все стараются нанять специалиста по самой верхней границе — крутого настолько, насколько это возможно, не пытаясь подобрать сотрудника для решения конкретно своих задач. Или пытаются найти разработчика «на вырост», не имея достаточно подтверждений тому, что этот рост действительно будет.
Вторая проблема: банальное несоблюдение договоренностей (и список этих нарушений огромен). Самое популярное — несоблюдение срока ответа. Вам говорят, что перезвонят, и не перезванивают. Или перезванивают, но спустя большой промежуток времени. Еще пример — дефицит информации. Вам говорят, что что-то не так, но не сообщают, что конкретно и можете ли вы с этим что-то сделать.
— Есть ли очевидный источник у этих проблем?
Готового ответа нет. С каждым случаем надо разбираться отдельно. Как правило, сотрудник отдела персонала уже после собеседования выполняет некую связующую функцию. У него нет квалификации, чтобы оценить, что конкретно в техническом плане кандидат сделал неправильно, т.е. он не может ответить на запросы кандидата, если тот, кто проводил техническую часть собеседования, не предоставил ему необходимую информацию. А эту информацию редко кто предоставляет — по самым разным причинам. Одни опасаются, что она может быть как-то неаккуратно использована против компании, и поэтому лучше отделаться нейтральной формулировкой. Но чаще это просто эффект свершившегося действия: мы уже знаем, что этот человек нам не подойдет, зачем тратить на него какие-то дополнительные силы, составляя список его ответов, указывая ему на ошибки и предлагая какой-то план развития? Подробнее на этом моменте я буду останавливаться в своем докладе.
— Кто вообще должен участвовать в собеседованиях мобильных разработчиков, а кто не должен?
На мой взгляд, принимать участие в интервью могут любые люди, наличие которых вы можете обосновать себе и кандидату. Теоретически вы можете пригнать в переговорку и толпу в 60 человек, если сможете сделать так, чтобы это не повлияло на результат собеседования в худшую сторону.
— А кто должен влиять на решение о найме?
Тот, кто заинтересован в этом найме. Как минимум, это три человека: кандидат, который пришел (хочется верить, что ему не все равно), руководитель, который ищет себе сотрудника, и, возможно, сотрудник отдела персонала, потому что у него тоже есть своя личная цель.
— Различается ли процесс найма специалистов разного уровня?
В интервью, которые провожу я, такой разницы нет. Мы разговариваем со всеми приблизительно одинаково: отличается глубина вопросов. Вне зависимости от уровня специалиста, мы начинаем с какой-то «верхушки». А дальше проверяем, насколько глубоко человек может с этим вопросом разобраться. У джуниора это будет один уровень погружения, у сеньора — другой.
— Есть ли у Pandao опыт взаимодействия с удаленными сотрудниками? Нужно ли в интервью учитывать такой формат работы?
У меня прямо сейчас в команде есть удаленные сотрудники. Часть из них сидит в московском офисе Mail.ru, чать — в Петербурге, а еще сотрудник в Иркутске. Даже было несколько полностью удаленных команд, распределенных в разных часовых поясах со сдвигом во времени до пяти часов. И по моему опыту, никаких специальных фишек по собеседованию удаленных разработчиков нет. У нас есть список общих договоренностей, которые соблюдают все, и в том числе удаленные разработчики. Поэтому по сути нет никакой разницы. Есть особенности работы, например, как предоставить доступ к тестовым устройствам, но это уже не этап собеседования.
— Используешь ли какие-то механизмы переманивания сотрудников у других технологических компаний? И есть ли вообще в этой «охоте за головами» смысл?
Лично я этим никогда не занимался. Единственный более-менее приемлемый с этической точки зрения вариант, который я вижу — если ты знаком с человеком лично и знаешь, что у него есть недовольство текущей работой, ты можешь предложить ему какие-то альтернативы. К примеру, ты можешь рекомендовать ему поговорить со своим работодателем на тему этого недовольства. И если он не найдет там понимания, предложить прийти в свою команду, отметив, что здесь с этой проблемой уже умеют работать.
Иными словами, я в свою команду не переманиваю, хотя держу в голове, что к любому из моих сотрудников будут приходить с предложениями подобного рода как минимум несколько раз в неделю.
— На собеседовании оцениваются только знания кандидата или, наряду с ними, внешний вид, поведение и т.п.? Могут ли тебя насторожить какие-то вещи, не касающиеся технической квалификации — например, футболка наизнанку?
Я думаю, что люди, которые говорят, что оценивают только технические качества, мотивируя это тем, что человек разыскивается для выполнения работы, не до конца отдают себе отчет в том, как именно в итоге они сами принимают решение. Имеет значение буквально все. Но мне кажется странным отказ кандидату, потому что у него неправильная футболка. Хотелось бы понимать про эту футболку нечто большее: что конкретно с ней не так, какие опасения она вызывает. Быть может, на ней какая-то оскорбительная для потенциальных коллег надпись, которую он считает своим манифестом? Наверное, надо просто обсудить, в чем суть истории — поинтересоваться происхождением футболки, надписью и любыми другими сомнительными факторами (в частности, что сам кандидат думает по этому поводу). Настолько прямо, насколько можно.
В целом среднее собеседование длится около двух часов и за это время нужно что-то понять про человека. Это сложно. Но никакого другого механизма, кроме обсуждения, у вас нет.
— Иногда компании фильтруют кандидатов, например, по внешнему виду (дескать, кандидат идет на собеседование, мог бы и подготовиться). Есть ли в этом смысл?
Не думаю. Мы таких требований не ставим. Но по секрету скажу, что конкретно в моей команде частенько смотрим страницы в соцсетях, просто чтобы понять, чем интересуется человек.
— Должен ли кандидат как-то готовиться к собеседованию? Распечатать резюме?
По-моему, мы на это только зря бумагу потратим. Мне достаточно ссылки на резюме — я почитаю, посмотрю проекты, перейду в AppStore и т.п. Но вот работоспособность ссылок можно и проверить — часто сталкиваюсь с тем, что человек дает ссылку на какой-то свой труд, а там ничего нет. Вижу это примерно так же часто, как указание в резюме ключевых слов, о которых кандидаты ничего не знают. Странно выглядит, когда кандидат не может описать основные принципы работы проекта, которым, по его словам, занимался последние несколько лет.
— Такие «пробелы» можно считать поводом проверить все остальное резюме?
Безусловно. Но мы стараемся проверять и без таких поводов. У нас с коллегами даже была такая практика — когда все основные вопросы заданы, мы прямо говорили: «У вас в резюме очень много ключевых слов, мы бы хотели быстро про них поговорить». И далее тыкаем в какое-то слово и спрашиваем: «Вот SQL. А что именно вы вкладываете в знание SQL?». И так далее. Эдакий блиц по ключевым словам.
— Алгоритм этой проверки как-то связан с тем, что указано в вакансии в разделе обязательных требований?
Нет. Все зависит от того, как человек показал себя до этого. В принципе, если он все делает прекрасно, до этой точки мы можем и не дойти.
— Как ты относишься к тестовому заданию? Какова должна быть длительность?
Это холиварная тема. У меня самого есть болезненный опыт на этот счет. Когда, например, я несколько дней делал тестовое задание, а потом две недели ждал по нему ответа, но получил только: «Не подходит». Очень информативно для двух дней работы и двух недель ожидания.
Подходов к тестовым заданиям я знаю много. Я даже сам формулировал тестовые задания, в том числе те, с которыми кандидат мог бы справиться за один вечер. Единственная сложность с такими короткими заданиями для меня лично в том, что всегда хочется сделать больше. Ты садишься программировать и через четыре часа понимаешь, что еще можно сделать вот это и вот тут додумать. В подобных случаях я так и пишу в сопроводительном письме: «Понимаю, что еще можно сделать это и это, но в четыре часа не успею; поэтому мной охвачен такой-то фронт работ, а вот эти вопросы отложены: список».
На свои вакансиях я тестовое задание выдаю редко. Предварительные тесты тоже не прошу проводить. Но в задании HR указываю просьбу запросить у кандидата любой пример кода. Нанимая разработчика, мы хотим посмотреть его код.
— NDA этому не помеха?
Хочется верить, что если человек провел за программированием какое-то количество лет, у него найдется в загашнике хотя бы несколько примеров, которые он может показать. Кандидаты действительно ссылаются на NDA. Мы таким людям в собеседовании не отказываем. Но в целом не так много людей, кто за 10 лет программирования не реализовал ничего открытого хотя бы для себя лично. А мне достаточно ссылки на GitHub, zip-архив или просто несколько связанных файлов.
И на собеседовании мы тоже что-то пишем.
— О чем будешь рассказывать на AppsConf?
Мой доклад фокусируется именно на собеседованиях. Как выстроить партнерские отношения с hr, как составить правильные требования к кандидату, как дать hr-у на вооружение ответы на все типовые вопросы, которые могут повлиять на решение человека прийти на собеседование, как провести само интервью и что нужно делать после его завершения. Я подробно рассмотрю только этот ограниченный кусочек времени. Процесс поиска кандидатов сотрудником отдела персонала — за рамками нашего разговора, как и все, что происходит с человеком после того, как он принял оффер.
— На кого ориентирован этот рассказ?
На любых людей, которые занимаются непосредственно наймом мобильных разработчиков. Желательно, чтобы это были технические специалисты — либо разработчик, который выступает в роли собеседующего от лица команды, либо руководитель этих разработчиков, нанимающий сотрудника, потому что у нас будут некоторые сугубо технические вкрапления. Но и hr сможет послушать. Процентов 60 сотрудникам отдела персонала будет понятно и, надеюсь, полезно.
Александр Черный — руководитель мобильной разработки в Pandao — одном из проектов электронной коммерции Mail.ru. В его подчинении команда из 15 человек: часть в штате и часть - на подряде. Подбором персонала всегда занимался сам. — Какую роль ты играешь в собеседованиях мобильных разработчиков?
Первые официальные деньги за программирование я получил в 2006 году. Следующие 5 лет я выступал только в роли того, кто проходит собеседования. Потом была закономерная ступень в виде лида по одному из направлений — по iOS, тогда, если не считать несколько разовых эпизодов, я и начал подбирать людей в свою и смежные команды на регулярной основе. Так что я довольно давно участвую в собеседованиях с разных сторон. В роли нанимателя я провел сотни интервью, на одну только последнюю позицию я посмотрел чуть больше 50 человек.
— Есть ли какое-то отличие найма именно в мобильной разработке?
В разработке в принципе есть дефицит кадров. Могу поверхностно утверждать, что в мобильной разработке этот дефицит выше, чем в среднем по отрасли.
— В целом не хватает специалистов или именно квалифицированных?
Оба варианта. Причем если речь идет о нехватке навыков, то «хромает» в большей степени техническая часть.
— А на какого рода специалистов ты ориентируешься при поиске?
В найме мы по большей части ориентируемся на специалистов уровня мидл и выше.
В принципе, джунов мы тоже берем. Вот, последнего взяли около 1,5 месяцев назад — и для него это первое место работы. Но в целом наш фокус — мидл+.
— Какие ошибки совершают наниматели в этой сфере в процессе поиска сотрудников?
Первая проблема, которую я вижу, заключается в том, что компании плохо формулируют требования к кандидату, не до конца отдавая себе отчет, зачем вообще нанимается новый человек. Как правило, все стараются нанять специалиста по самой верхней границе — крутого настолько, насколько это возможно, не пытаясь подобрать сотрудника для решения конкретно своих задач. Или пытаются найти разработчика «на вырост», не имея достаточно подтверждений тому, что этот рост действительно будет.
Вторая проблема: банальное несоблюдение договоренностей (и список этих нарушений огромен). Самое популярное — несоблюдение срока ответа. Вам говорят, что перезвонят, и не перезванивают. Или перезванивают, но спустя большой промежуток времени. Еще пример — дефицит информации. Вам говорят, что что-то не так, но не сообщают, что конкретно и можете ли вы с этим что-то сделать.
— Есть ли очевидный источник у этих проблем?
Готового ответа нет. С каждым случаем надо разбираться отдельно. Как правило, сотрудник отдела персонала уже после собеседования выполняет некую связующую функцию. У него нет квалификации, чтобы оценить, что конкретно в техническом плане кандидат сделал неправильно, т.е. он не может ответить на запросы кандидата, если тот, кто проводил техническую часть собеседования, не предоставил ему необходимую информацию. А эту информацию редко кто предоставляет — по самым разным причинам. Одни опасаются, что она может быть как-то неаккуратно использована против компании, и поэтому лучше отделаться нейтральной формулировкой. Но чаще это просто эффект свершившегося действия: мы уже знаем, что этот человек нам не подойдет, зачем тратить на него какие-то дополнительные силы, составляя список его ответов, указывая ему на ошибки и предлагая какой-то план развития? Подробнее на этом моменте я буду останавливаться в своем докладе.
— Кто вообще должен участвовать в собеседованиях мобильных разработчиков, а кто не должен?
На мой взгляд, принимать участие в интервью могут любые люди, наличие которых вы можете обосновать себе и кандидату. Теоретически вы можете пригнать в переговорку и толпу в 60 человек, если сможете сделать так, чтобы это не повлияло на результат собеседования в худшую сторону.
— А кто должен влиять на решение о найме?
Тот, кто заинтересован в этом найме. Как минимум, это три человека: кандидат, который пришел (хочется верить, что ему не все равно), руководитель, который ищет себе сотрудника, и, возможно, сотрудник отдела персонала, потому что у него тоже есть своя личная цель.
— Различается ли процесс найма специалистов разного уровня?
В интервью, которые провожу я, такой разницы нет. Мы разговариваем со всеми приблизительно одинаково: отличается глубина вопросов. Вне зависимости от уровня специалиста, мы начинаем с какой-то «верхушки». А дальше проверяем, насколько глубоко человек может с этим вопросом разобраться. У джуниора это будет один уровень погружения, у сеньора — другой.
— Есть ли у Pandao опыт взаимодействия с удаленными сотрудниками? Нужно ли в интервью учитывать такой формат работы?
У меня прямо сейчас в команде есть удаленные сотрудники. Часть из них сидит в московском офисе Mail.ru, чать — в Петербурге, а еще сотрудник в Иркутске. Даже было несколько полностью удаленных команд, распределенных в разных часовых поясах со сдвигом во времени до пяти часов. И по моему опыту, никаких специальных фишек по собеседованию удаленных разработчиков нет. У нас есть список общих договоренностей, которые соблюдают все, и в том числе удаленные разработчики. Поэтому по сути нет никакой разницы. Есть особенности работы, например, как предоставить доступ к тестовым устройствам, но это уже не этап собеседования.
— Используешь ли какие-то механизмы переманивания сотрудников у других технологических компаний? И есть ли вообще в этой «охоте за головами» смысл?
Лично я этим никогда не занимался. Единственный более-менее приемлемый с этической точки зрения вариант, который я вижу — если ты знаком с человеком лично и знаешь, что у него есть недовольство текущей работой, ты можешь предложить ему какие-то альтернативы. К примеру, ты можешь рекомендовать ему поговорить со своим работодателем на тему этого недовольства. И если он не найдет там понимания, предложить прийти в свою команду, отметив, что здесь с этой проблемой уже умеют работать.
Иными словами, я в свою команду не переманиваю, хотя держу в голове, что к любому из моих сотрудников будут приходить с предложениями подобного рода как минимум несколько раз в неделю.
— На собеседовании оцениваются только знания кандидата или, наряду с ними, внешний вид, поведение и т.п.? Могут ли тебя насторожить какие-то вещи, не касающиеся технической квалификации — например, футболка наизнанку?
Я думаю, что люди, которые говорят, что оценивают только технические качества, мотивируя это тем, что человек разыскивается для выполнения работы, не до конца отдают себе отчет в том, как именно в итоге они сами принимают решение. Имеет значение буквально все. Но мне кажется странным отказ кандидату, потому что у него неправильная футболка. Хотелось бы понимать про эту футболку нечто большее: что конкретно с ней не так, какие опасения она вызывает. Быть может, на ней какая-то оскорбительная для потенциальных коллег надпись, которую он считает своим манифестом? Наверное, надо просто обсудить, в чем суть истории — поинтересоваться происхождением футболки, надписью и любыми другими сомнительными факторами (в частности, что сам кандидат думает по этому поводу). Настолько прямо, насколько можно.
В целом среднее собеседование длится около двух часов и за это время нужно что-то понять про человека. Это сложно. Но никакого другого механизма, кроме обсуждения, у вас нет.
— Иногда компании фильтруют кандидатов, например, по внешнему виду (дескать, кандидат идет на собеседование, мог бы и подготовиться). Есть ли в этом смысл?
Не думаю. Мы таких требований не ставим. Но по секрету скажу, что конкретно в моей команде частенько смотрим страницы в соцсетях, просто чтобы понять, чем интересуется человек.
— Должен ли кандидат как-то готовиться к собеседованию? Распечатать резюме?
По-моему, мы на это только зря бумагу потратим. Мне достаточно ссылки на резюме — я почитаю, посмотрю проекты, перейду в AppStore и т.п. Но вот работоспособность ссылок можно и проверить — часто сталкиваюсь с тем, что человек дает ссылку на какой-то свой труд, а там ничего нет. Вижу это примерно так же часто, как указание в резюме ключевых слов, о которых кандидаты ничего не знают. Странно выглядит, когда кандидат не может описать основные принципы работы проекта, которым, по его словам, занимался последние несколько лет.
— Такие «пробелы» можно считать поводом проверить все остальное резюме?
Безусловно. Но мы стараемся проверять и без таких поводов. У нас с коллегами даже была такая практика — когда все основные вопросы заданы, мы прямо говорили: «У вас в резюме очень много ключевых слов, мы бы хотели быстро про них поговорить». И далее тыкаем в какое-то слово и спрашиваем: «Вот SQL. А что именно вы вкладываете в знание SQL?». И так далее. Эдакий блиц по ключевым словам.
— Алгоритм этой проверки как-то связан с тем, что указано в вакансии в разделе обязательных требований?
Нет. Все зависит от того, как человек показал себя до этого. В принципе, если он все делает прекрасно, до этой точки мы можем и не дойти.
— Как ты относишься к тестовому заданию? Какова должна быть длительность?
Это холиварная тема. У меня самого есть болезненный опыт на этот счет. Когда, например, я несколько дней делал тестовое задание, а потом две недели ждал по нему ответа, но получил только: «Не подходит». Очень информативно для двух дней работы и двух недель ожидания.
Подходов к тестовым заданиям я знаю много. Я даже сам формулировал тестовые задания, в том числе те, с которыми кандидат мог бы справиться за один вечер. Единственная сложность с такими короткими заданиями для меня лично в том, что всегда хочется сделать больше. Ты садишься программировать и через четыре часа понимаешь, что еще можно сделать вот это и вот тут додумать. В подобных случаях я так и пишу в сопроводительном письме: «Понимаю, что еще можно сделать это и это, но в четыре часа не успею; поэтому мной охвачен такой-то фронт работ, а вот эти вопросы отложены: список».
На свои вакансиях я тестовое задание выдаю редко. Предварительные тесты тоже не прошу проводить. Но в задании HR указываю просьбу запросить у кандидата любой пример кода. Нанимая разработчика, мы хотим посмотреть его код.
— NDA этому не помеха?
Хочется верить, что если человек провел за программированием какое-то количество лет, у него найдется в загашнике хотя бы несколько примеров, которые он может показать. Кандидаты действительно ссылаются на NDA. Мы таким людям в собеседовании не отказываем. Но в целом не так много людей, кто за 10 лет программирования не реализовал ничего открытого хотя бы для себя лично. А мне достаточно ссылки на GitHub, zip-архив или просто несколько связанных файлов.
И на собеседовании мы тоже что-то пишем.
— О чем будешь рассказывать на AppsConf?
Мой доклад фокусируется именно на собеседованиях. Как выстроить партнерские отношения с hr, как составить правильные требования к кандидату, как дать hr-у на вооружение ответы на все типовые вопросы, которые могут повлиять на решение человека прийти на собеседование, как провести само интервью и что нужно делать после его завершения. Я подробно рассмотрю только этот ограниченный кусочек времени. Процесс поиска кандидатов сотрудником отдела персонала — за рамками нашего разговора, как и все, что происходит с человеком после того, как он принял оффер.
— На кого ориентирован этот рассказ?
На любых людей, которые занимаются непосредственно наймом мобильных разработчиков. Желательно, чтобы это были технические специалисты — либо разработчик, который выступает в роли собеседующего от лица команды, либо руководитель этих разработчиков, нанимающий сотрудника, потому что у нас будут некоторые сугубо технические вкрапления. Но и hr сможет послушать. Процентов 60 сотрудникам отдела персонала будет понятно и, надеюсь, полезно.
