Главная » Хабрахабр » С обоих баррикад: про найм разработчиков мобильных приложений

С обоих баррикад: про найм разработчиков мобильных приложений

О том, можно ли нанять мобильного разработчика без тестового задания, надо ли проводить ему «экзамен» на знание всех ключевых слов из резюме и какие ошибки не стоит совершать, мы поговорили с Александром Черным, одним из спикеров нашей AppsConf.

В его подчинении команда из 15 человек: часть в штате и часть  - на подряде.
Александр Черный — руководитель мобильной разработки в Pandao — одном из проектов электронной коммерции Mail.ru. Подбором персонала всегда занимался сам.

— Какую роль ты играешь в собеседованиях мобильных разработчиков?

Следующие 5 лет я выступал только в роли того, кто проходит собеседования. Первые официальные деньги за программирование я получил в 2006 году. Так что я довольно давно участвую в собеседованиях с разных сторон. Потом была закономерная ступень в виде лида по одному из направлений — по iOS, тогда, если не считать несколько разовых эпизодов, я и начал подбирать людей в свою и смежные команды на регулярной основе. В роли нанимателя я провел сотни интервью, на одну только последнюю позицию я посмотрел чуть больше 50 человек.

— Есть ли какое-то отличие найма именно в мобильной разработке?

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

— В целом не хватает специалистов или именно квалифицированных?

Причем если речь идет о нехватке навыков, то «хромает» в большей степени техническая часть. Оба варианта.

— А на какого рода специалистов ты ориентируешься при поиске?

Вот, последнего взяли около 1,5 месяцев назад — и для него это первое место работы. В найме мы по большей части ориентируемся на специалистов уровня мидл и выше.
В принципе, джунов мы тоже берем. Но в целом наш фокус — мидл+.

— Какие ошибки совершают наниматели в этой сфере в процессе поиска сотрудников?

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

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

— Есть ли очевидный источник у этих проблем?

С каждым случаем надо разбираться отдельно. Готового ответа нет. У него нет квалификации, чтобы оценить, что конкретно в техническом плане кандидат сделал неправильно, т.е. Как правило, сотрудник отдела персонала уже после собеседования выполняет некую связующую функцию. А эту информацию редко кто предоставляет — по самым разным причинам. он не может ответить на запросы кандидата, если тот, кто проводил техническую часть собеседования, не предоставил ему необходимую информацию. Но чаще это просто эффект свершившегося действия: мы уже знаем, что этот человек нам не подойдет, зачем тратить на него какие-то дополнительные силы, составляя список его ответов, указывая ему на ошибки и предлагая какой-то план развития? Одни опасаются, что она может быть как-то неаккуратно использована против компании, и поэтому лучше отделаться нейтральной формулировкой. Подробнее на этом моменте я буду останавливаться в своем докладе.

— Кто вообще должен участвовать в собеседованиях мобильных разработчиков, а кто не должен?

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

— А кто должен влиять на решение о найме?

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

— Различается ли процесс найма специалистов разного уровня?

Мы разговариваем со всеми приблизительно одинаково: отличается глубина вопросов. В интервью, которые провожу я, такой разницы нет. А дальше проверяем, насколько глубоко человек может с этим вопросом разобраться. Вне зависимости от уровня специалиста, мы начинаем с какой-то «верхушки». У джуниора это будет один уровень погружения, у сеньора — другой.

Нужно ли в интервью учитывать такой формат работы? — Есть ли у Pandao опыт взаимодействия с удаленными сотрудниками?

Часть из них сидит в московском офисе Mail.ru, чать — в Петербурге, а еще сотрудник в Иркутске. У меня прямо сейчас в команде есть удаленные сотрудники. И по моему опыту, никаких специальных фишек по собеседованию удаленных разработчиков нет. Даже было несколько полностью удаленных команд, распределенных в разных часовых поясах со сдвигом во времени до пяти часов. Поэтому по сути нет никакой разницы. У нас есть список общих договоренностей, которые соблюдают все, и в том числе удаленные разработчики. Есть особенности работы, например, как предоставить доступ к тестовым устройствам, но это уже не этап собеседования.

И есть ли вообще в этой «охоте за головами» смысл? — Используешь ли какие-то механизмы переманивания сотрудников у других технологических компаний?

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

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

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

Имеет значение буквально все. Я думаю, что люди, которые говорят, что оценивают только технические качества, мотивируя это тем, что человек разыскивается для выполнения работы, не до конца отдают себе отчет в том, как именно в итоге они сами принимают решение. Хотелось бы понимать про эту футболку нечто большее: что конкретно с ней не так, какие опасения она вызывает. Но мне кажется странным отказ кандидату, потому что у него неправильная футболка. Наверное, надо просто обсудить, в чем суть истории — поинтересоваться происхождением футболки, надписью и любыми другими сомнительными факторами (в частности, что сам кандидат думает по этому поводу). Быть может, на ней какая-то оскорбительная для потенциальных коллег надпись, которую он считает своим манифестом? Настолько прямо, насколько можно.

Это сложно. В целом среднее собеседование длится около двух часов и за это время нужно что-то понять про человека. Но никакого другого механизма, кроме обсуждения, у вас нет.

Есть ли в этом смысл? — Иногда компании фильтруют кандидатов, например, по внешнему виду (дескать, кандидат идет на собеседование, мог бы и подготовиться).

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

Распечатать резюме? — Должен ли кандидат как-то готовиться к собеседованию?

Мне достаточно ссылки на резюме — я почитаю, посмотрю проекты, перейду в AppStore и т.п. По-моему, мы на это только зря бумагу потратим. Вижу это примерно так же часто, как указание в резюме ключевых слов, о которых кандидаты ничего не знают. Но вот работоспособность ссылок можно и проверить — часто сталкиваюсь с тем, что человек дает ссылку на какой-то свой труд, а там ничего нет. Странно выглядит, когда кандидат не может описать основные принципы работы проекта, которым, по его словам, занимался последние несколько лет.

— Такие «пробелы» можно считать поводом проверить все остальное резюме?

Но мы стараемся проверять и без таких поводов. Безусловно. И далее тыкаем в какое-то слово и спрашиваем: «Вот SQL. У нас с коллегами даже была такая практика — когда все основные вопросы заданы, мы прямо говорили: «У вас в резюме очень много ключевых слов, мы бы хотели быстро про них поговорить». И так далее. А что именно вы вкладываете в знание SQL?». Эдакий блиц по ключевым словам.

— Алгоритм этой проверки как-то связан с тем, что указано в вакансии в разделе обязательных требований?

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

Какова должна быть длительность? — Как ты относишься к тестовому заданию?

У меня самого есть болезненный опыт на этот счет. Это холиварная тема. Очень информативно для двух дней работы и двух недель ожидания. Когда, например, я несколько дней делал тестовое задание, а потом две недели ждал по нему ответа, но получил только: «Не подходит».

Я даже сам формулировал тестовые задания, в том числе те, с которыми кандидат мог бы справиться за один вечер. Подходов к тестовым заданиям я знаю много. Ты садишься программировать и через четыре часа понимаешь, что еще можно сделать вот это и вот тут додумать. Единственная сложность с такими короткими заданиями для меня лично в том, что всегда хочется сделать больше. В подобных случаях я так и пишу в сопроводительном письме: «Понимаю, что еще можно сделать это и это, но в четыре часа не успею; поэтому мной охвачен такой-то фронт работ, а вот эти вопросы отложены: список».

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

— NDA этому не помеха?

Кандидаты действительно ссылаются на NDA. Хочется верить, что если человек провел за программированием какое-то количество лет, у него найдется в загашнике хотя бы несколько примеров, которые он может показать. Но в целом не так много людей, кто за 10 лет программирования не реализовал ничего открытого хотя бы для себя лично. Мы таким людям в собеседовании не отказываем. А мне достаточно ссылки на GitHub, zip-архив или просто несколько связанных файлов.

И на собеседовании мы тоже что-то пишем.

— О чем будешь рассказывать на AppsConf?

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

— На кого ориентирован этот рассказ?

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] Решаем проблемы типов данных в Ruby или Make data reliable again

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

SamsPcbGuide, часть 8: Как получить правильную осциллограмму

Наверно, все умеют пользоваться осциллографом. Это очень легко – цепляешь «крокодил» к земле, остриё щупа – в необходимую точку измерения, регулируешь масштаб по вертикальной и горизонтальной осям и получаешь временную развёртку напряжения в этой точке. Да, так можно делать, но ...