- PVSM.RU - https://www.pvsm.ru -
За последнее время на хабре вышло столько рассказов о плохих собеседования, что порой закрадывается сомнение, а бывают ли в природе собеседования хорошие? Так что разнообразия ради в этом мы рассмотрим пример хорошего* подхода. Рассказ будет идти с точки зрения разработчика работодателя, который напрямую участвует в процессе найма.
* наверное
Маленькая продуктовая команда (30-40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.
Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.
Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.
Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android – полный отстой»?
Тестовое задание даётся без ограничений по времени, хотя на практике должно занять не больше одного вечера. В рамках тестового приложения будет:
Впрочем, не все разработчики готовы писать тестовое, поэтому мы сразу предлагаем альтернативу — прислать код какого-нибудь готового приложения, где будет такой же набор (сеть, БД, навигация по экранам, пользовательский ввод). Ну а дальше возможны варианты:
По результатам тестового мы или зовём разработчика на собеседование, или даём отказ, но во втором случае будет дан подробнейший отзыв — что сделано хорошо, что спорно, какие возникают вопросы, что стоит почитать и так далее. В результате выигрывают все:
На собеседовании обязательно будут не только разговоры за жисть и о предыдущем месте работе, но и вопросы по тестовому заданию. На этом этапе довольно просто понять, сам ли человек писал тестовое, понимает, ли что там написано, может ли обосновать то или иное решение, какой у него кругозор и так далее. Вопросы задаются не в воздухе, а с возможностью взять клавиатуру и потыкать этот самый код. Иногда просим что-то чуток переписать на ходу или подправить, задаём вопросы вида «а если бы было ещё вот такое требование...»
Далее будет 1-2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10-20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.
И это в общем-то всё. Максимум через пару-тройку дней мы дадим кандидату ответ. Впрочем, чаще всего ответ даётся в тот же день). И в случае отказа опять таки будет адекватное обоснование. Ну, а если его будет недостаточно, то кандидат всегда может попросить контакты разработчиков с собеседования для уточнения каких-то моментов, и ему их с высокой долей вероятности дадут.
Воистину. Мог даже близнеца прислать [1]. Ну а мог и не обманывать, просто мы на собеседовании ошиблись. На такой случай есть замечательная вещь под названием «испытательный срок». Плюс работы в крупной компании (как минимум в нашем случае) — непрохождение испытательного срока не означает стопроцентное расставание с компанией. В конце концов, разработчик мог оказаться неплох, но не прижился в конкретной команде — на этот случай всегда есть альтернативные проекты.
Да, каюсь, тогда я грешил небольшими опросами и собеседованиями без тестового. Много времени потратил, и своего, и чужого. Так что когда речь зашла о новых поисках разработчика, то я решил попробовать иной подход. Разработчики пишут код? Отлично! Покажи мне свой код, и я скажу, стоит ли нам собеседоваться.
А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.
Жду вас в комментариях. Подискутируем ;-)
Автор: Newbilius
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sobesedovanie/295547
Ссылки в тексте:
[1] близнеца прислать: https://habr.com/company/crossover/blog/424701/
[2] Источник: https://habr.com/post/425293/?utm_campaign=425293
Нажмите здесь для печати.