Идеальное (наверное) собеседование мобильного разработчика-мидла
За последнее время на хабре вышло столько рассказов о плохих собеседования, что порой закрадывается сомнение, а бывают ли в природе собеседования хорошие? Так что разнообразия ради в этом мы рассмотрим пример хорошего* подхода. Рассказ будет идти с точки зрения разработчика работодателя, который напрямую участвует в процессе найма.
* наверное
Диспозиция
Маленькая продуктовая команда (30–40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.
Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.
Этап 0 — встретились два одиночества
Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.
Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android — полный отстой»?
Этап 1 — тестовое задание или пример кода
Тестовое задание даётся без ограничений по времени, хотя на практике должно занять не больше одного вечера. В рамках тестового приложения будет:
- три экрана: два связанных списка + форма ввода данных, которую при желании можно заменить на модальное окно
- работа с сетью
- работа с хранилищем данных (задание подразумевает БД, если разработчик сможет обосновать другой вывод — милости просим)
Впрочем, не все разработчики готовы писать тестовое, поэтому мы сразу предлагаем альтернативу — прислать код какого-нибудь готового приложения, где будет такой же набор (сеть, БД, навигация по экранам, пользовательский ввод). Ну, а дальше возможны варианты:
- приложение слишком маленькое, код не показателен или вызывает слишком много вопросов просим таки сделать наше тестовое
- приложение подходящее, но есть нюансы — просим сделать небольшие доработки (меньше чем на вечер)
По результатам тестового мы или зовём разработчика на собеседование, или даём отказ, но во втором случае будет дан подробнейший отзыв — что сделано хорошо, что спорно, какие возникают вопросы, что стоит почитать и так далее. В результате выигрывают все:
- кандидат получает код, который потом можно переиспользовать на другом собеседовании с подобными принципами, а также обратную связь для работы над собой. Работает ли оно? Ну, как минимум к нам присылали тестовые задания, изначально написанные для других компаний, так что похоже, что работает;
- работодатель экономит время на опросниках и прочей фигне. А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1–2 собеседованию в неделю, если б вы только знали!
Этап 2 — собеседование
На собеседовании обязательно будут не только разговоры за жисть и о предыдущем месте работе, но и вопросы по тестовому заданию. На этом этапе довольно просто понять, сам ли человек писал тестовое, понимает, ли что там написано, может ли обосновать то или иное решение, какой у него кругозор и так далее. Вопросы задаются не в воздухе, а с возможностью взять клавиатуру и потыкать этот самый код. Иногда просим что-то чуток переписать на ходу или подправить, задаём вопросы вида «а если бы было ещё вот такое требование…»
Далее будет 1–2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10–20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.
И это в общем-то всё. Максимум через пару-тройку дней мы дадим кандидату ответ. Впрочем, чаще всего ответ даётся в тот же день). И в случае отказа опять таки будет адекватное обоснование. Ну, а если его будет недостаточно, то кандидат всегда может попросить контакты разработчиков с собеседования для уточнения каких-то моментов, и ему их с высокой долей вероятности дадут.
Но ведь кандидат мог и обмануть
Воистину. Мог даже близнеца прислать. Ну, а мог и не обманывать, просто мы на собеседовании ошиблись. На такой случай есть замечательная вещь под названием «испытательный срок». Плюс работы в крупной компании (как минимум в нашем случае) — непрохождение испытательного срока не означает стопроцентное расставание с компанией. В конце концов, разработчик мог оказаться неплох, но не прижился в конкретной команде — на этот случай всегда есть альтернативные проекты.
Так, стоп! Я узнал команду, о которой идёт речь, собеседовался в неё пару лет назад, и там схема сильно отличалась
Да, каюсь, тогда я грешил небольшими опросами и собеседованиями без тестового. Много времени потратил, и своего, и чужого. Так что когда речь зашла о новых поисках разработчика, то я решил попробовать иной подход. Разработчики пишут код? Отлично! Покажи мне свой код, и я скажу, стоит ли нам собеседоваться.
Но я и в компанию узнал! Устраивался в другой проект, и там тоже всё не так!
А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.
У описанного подхода есть и другие недостатки!
Жду вас в комментариях. Подискутируем ;-)
