* наверное
Диспозиция
Маленькая продуктовая команда (30-40 человек) внутри крупной компании (несколько тысяч человек). В команду входят все, кто занимается проектом: фуллстек разработчики и фронтедеры, дизайнеры и интерфейсологи, тестировщики, спецы по пиару, аналитики, авторы текстов и т.п. В общем, мы стараемся поменьше аутсорсить профильную работу в другие проекты, и мобильная разработка — не исключение.
Мобильное приложение у нас кроссплатформенное, написано на Xamarin Native под iOS и Android. При этом мы полностью готовы брать в меру опытного разработчика, писавшего только под одну платформу, при условии, что он готов изучать разработку под вторую ОС.
Этап 0 — встретились два одиночества
Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.
Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет. За последний месяц я посмотрел пару десятков резюме, и понятия не имею, что должен написать и ответить кандидат, чтобы мне пришлось сказать «нет» уже на этом этапе. Написать на вакансию Android-разработчика «пишу только под iOS, потому что Android – полный отстой»?
Этап 1 — тестовое задание или пример кода
Тестовое задание даётся без ограничений по времени, хотя на практике должно занять не больше одного вечера. В рамках тестового приложения будет:
- три экрана: два связанных списка + форма ввода данных, которую при желании можно заменить на модальное окно
- работа с сетью
- работа с хранилищем данных (задание подразумевает БД, если разработчик сможет обосновать другой вывод — милости просим)
Впрочем, не все разработчики готовы писать тестовое, поэтому мы сразу предлагаем альтернативу — прислать код какого-нибудь готового приложения, где будет такой же набор (сеть, БД, навигация по экранам, пользовательский ввод). Ну а дальше возможны варианты:
- приложение слишком маленькое, код не показателен или вызывает слишком много вопросов просим таки сделать наше тестовое
- приложение подходящее, но есть нюансы — просим сделать небольшие доработки (меньше чем на вечер)
По результатам тестового мы или зовём разработчика на собеседование, или даём отказ, но во втором случае будет дан подробнейший отзыв — что сделано хорошо, что спорно, какие возникают вопросы, что стоит почитать и так далее. В результате выигрывают все:
- кандидат получает код, который потом можно переиспользовать на другом собеседовании с подобными принципами, а также обратную связь для работы над собой. Работает ли оно? Ну, как минимум к нам присылали тестовые задания, изначально написанные для других компаний, так что похоже, что работает;
- работодатель экономит время на опросниках и прочей фигне. А уж как радуется собеседующий-интроверт, которому не нужно проводить по 1-2 собеседованию в неделю, если б вы только знали!
Этап 2 — собеседование
На собеседовании обязательно будут не только разговоры за жисть и о предыдущем месте работе, но и вопросы по тестовому заданию. На этом этапе довольно просто понять, сам ли человек писал тестовое, понимает, ли что там написано, может ли обосновать то или иное решение, какой у него кругозор и так далее. Вопросы задаются не в воздухе, а с возможностью взять клавиатуру и потыкать этот самый код. Иногда просим что-то чуток переписать на ходу или подправить, задаём вопросы вида «а если бы было ещё вот такое требование...»
Далее будет 1-2 небольшие практические задачки, они зависят от тестового задания. Опять таки даём в руки клавиатуру (подключенную к компьютеру, компьютер с монитором!) и просим что-нибудь написать или отредактировать. Одна из моих любимых вещей — дать рабочую, но плохо написанную функцию строчек на 10-20 и предложить её отрефакторить. Сразу становится понятно, есть ли у кандидата чуйка на «плохой код», что он знает о конструкциях языка, умеет ли читать чужой код и далее по списку.
И это в общем-то всё. Максимум через пару-тройку дней мы дадим кандидату ответ. Впрочем, чаще всего ответ даётся в тот же день). И в случае отказа опять таки будет адекватное обоснование. Ну, а если его будет недостаточно, то кандидат всегда может попросить контакты разработчиков с собеседования для уточнения каких-то моментов, и ему их с высокой долей вероятности дадут.
Но ведь кандидат мог и обмануть
Воистину. Мог даже близнеца прислать. Ну а мог и не обманывать, просто мы на собеседовании ошиблись. На такой случай есть замечательная вещь под названием «испытательный срок». Плюс работы в крупной компании (как минимум в нашем случае) — непрохождение испытательного срока не означает стопроцентное расставание с компанией. В конце концов, разработчик мог оказаться неплох, но не прижился в конкретной команде — на этот случай всегда есть альтернативные проекты.
Так, стоп! Я узнал команду, о которой идёт речь, собеседовался в неё пару лет назад, и там схема сильно отличалась
Да, каюсь, тогда я грешил небольшими опросами и собеседованиями без тестового. Много времени потратил, и своего, и чужого. Так что когда речь зашла о новых поисках разработчика, то я решил попробовать иной подход. Разработчики пишут код? Отлично! Покажи мне свой код, и я скажу, стоит ли нам собеседоваться.
Но я и в компанию узнал! Устраивался в другой проект, и там тоже всё не так!
А вот тут ситуация с хитринкой. К нам в компанию идёт приличный поток бэкендеров/фулл-стек разработчиков, и таких разработчиков в компании несколько сотен. Поэтому процесс их набора уже достаточно устаканился и стандартизировался. Мобильных же разработчиков в компании пока что мало, так что нам легче экспериментировать с подходами к собеседованиею.
У описанного подхода есть и другие недостатки!
Жду вас в комментариях. Подискутируем ;-)
Комментарии (29)
Necessitudo
12.10.2018 18:24+1А как происходит собеседование джунов?
Видео про Xbox кстати было шикарным))Newbilius Автор
12.10.2018 18:33Спасибо)
Про джунов надо узнать, ни разу не набирал. Для нашей команды именно мобильный джун разработчик пойдёт по тому же пути, но требования к нему будут пониже.
pipyakin
12.10.2018 20:33Тестовое задание должно оплачиваться.
Newbilius Автор
12.10.2018 21:00+2Если тестовое занимает больше 1 вечера — пожалуй, со скрипом могу согласиться, но тут надо уже обсуждать детали.
Если компания потом явно может использовать результат тестового как коммерческий продукт — опять же соглашусь.
В противном случае — не согласен. Тестовое, как и собеседование — это обоюдное вложение сил как со стороны кандидата (сделать задание), так и со стороны работодателя (качественно и осмысленно проверить тестовое и дать качественную же обратную связь требует времени).pipyakin
12.10.2018 23:14У меня есть гит, пусть оценивают, а проверяют единицы, обычно любят не перезванивать.
Ad_xname
12.10.2018 20:33+1Смотрел с двух сторон )
Со стороны соискателя. (Технологии для примера)
1. В резюме «Разработчик Android», присылают вакансию «разработчик iOS». Пишу вакансия интересная, но с iOS не работал. Отвечают — это не важно, приходите. Нам главное, чтобы вы знали javascript. )
2. Дается тестовое задание. Это не страшно, если у тебя только одно предложение. Интересно, как бы отнесся работодатель, если бы я предложил ему заплатить за него? Почему-то каждый уверен, что его вакансия настолько интересна, что кандидат готов на все ради нее. Увы, это не всегда так.
Ради «работы мечты» многие готовы и попотеть, возможно впустую, а вот ради рядового предложения…
Допустим, у Вас 3-4 собеседования в неделю, плюс работа, плюс домашние дела.
И нужно найти 4 свободных вечера.
3. Идея «покажи свой код» интересная, если у разработчика есть личные проекты. А если нет, и он все время разрабатывал коммерческий код? «Украсть» его? Я уж не говорю о том, что серьезные проекты не пишутся одним человеком.
Со стороны работодателя.
1. Составьте список вопросов в соответствии с необходимыми знаниями кандидата. А не один на все виды вакансий.
2. Подготовьте тестовое задание( в идеале каркас приложения на компьютере), чтобы после интервью можно было проверить навыки кандидата.
3. Задание не должно проверять все на свете, только ключевые для вас вещи и иметь разумное время выполнения.
4. Собеседовать должен не «разработчик-интроверт», а team-lead. Который сможет оценить и знания кандидата, и способность работы в команде.
5. На собеседовании прекрасно видно, кто знает, а кто нет, если сами хорошо разбираетесь в теме. Намного лучше, чем тестовое задание, как это не странно. Впрочем его все равно лучше дать, это дополнит интервью.eugene_bb
12.10.2018 20:49+1Я обычно прошу оценить знание технологий перечисленных в резюме по пятибалльной системе и разговариваю только по пунктам которые они оцениваю в наибольшее количество балов.
Выполнить тестовое задание не прошу. Также не говорю «покажи/напиши код», а говорю «посмотри код».
Даю код содержащий заведомо много проблем (из нашего легаси проекта) и разговариваем по поводу того что ему кажется неправильным. На каждый пункт, задаю три вопроса: Что? Почему? Как правильно?
Всё проходит гладко и не вооружённым глазом видно в первые 10 минут что за человек и как глубоко знает предмет.
Плюс, в моей практике еще не было такого что «нанимаем в проект, который стартует в три месяца», а всегда было «Проект уже в стадии разработки/поддержки, нужно влиться в команду». Поэтому собеседование в стиле «сделай что нибудь с нуля» не были актуальны.
А новые проекты обычно стартуют с группы разработчиков уже работающих в компании. Они делают PoC/MVP и если всё удачно то в течении какого-то времени они плывут сами и только потом нанимают дополнительных гребцов.
Newbilius Автор
12.10.2018 20:56Со стороны соискателя.
1) Чертовски забавная иллюстрация) Но я бы предположил, что в компании используется какая-нибудь кроссплатформа на базе JS, например React Native. Мы вот например сразу предупреждаем, что у нас Xamarin и сразу под две платформы, но если нет опыта именно в нём, но есть в нативной разработке — для нас это не критично.
2-3) Вот именно для такого и даётся выбор — пример своего кода или тестовое. Если у человека нет первого и не хочет делать второго, то да, в этом случае наше решение работает как фильтр на входе. И это осознанное решение — оно кажется меньшим злом, чем всевозможные квизы. Мы рассчитываем на такую (вроде бы немалую) вероятность, что разработчик докачавшийся до миддла разрабатывал не только в рабочее время, но и сам, для своего удовольствия копался в этой области, а значит у него есть какие-то наработки. А если и нет — вот тестовое в качестве альтернативы.
Ну мне кажется 3-4 собеседования за неделю это перебор. Лучше же максимум по одному в неделю, чтобы иметь время проанализировать результаты, отрефлексировать, обдумать вопросы, что-то покопать… Но опять таки, согласен — всякое в жизни бывает, не всегда есть возможность искать работу в комфортном темпе.
Со стороны работодателя.
Со всем согласен! И тимлид на нашем собеседовании обязательно участвует) Но обычно с тимлидом идёт и кто-нибудь из разработки, потому что это:
1) дополнительное мнение о кандидате
2) прокачка других разработчиков, в том числе в софтскиллах
third112
12.10.2018 20:57+1Либо разработчик натыкается на вакансию и высылает резюме, после чего HR отправляет ему несколько уточняющих вопросов, либо HR натыкается на резюме разработчика, после чего высылает ему примерно тот же самый ряд вопросов.
А можно взглянуть на конкретный пример таких вопросов?
Эти вопросы — минимальный фильтр на адекватность, никаких технических вопросов не будет. Дальше резюме и ответы передаются уже разработчику со стороны нанимателя, и тот принимает решение, идём дальше или нет.
На собеседовании обязательно будут не только разговоры за жисть
А можно конкретнее? Какие «разговоры за жисть»? Зачем это нужно?Newbilius Автор
12.10.2018 21:101) Сюда могут попасть и уточнение каких-нибудь деталей, например «занимался таким то приложением» может вызывать вопросы «писал один или в команде», «если в команде, то кто отвечал за архитектуру», «пришёл на готовый проект или писал с нуля» и т.п. Если из резюме видно несколько разработанных продуктов — это наведёт на вопрос о том, какой из проектов показался интереснее всего и почему и т.п.
2) Это я так назвал вводную «не техническую» часть беседы, которая с одной стороны призваны помочь расслабиться кандидату, а с другой — узнать его бэкграунд. Например почему человек пошёл именно в мобильную разработку и именно под такую то платформу, как был построен процесс разработки на предыдущем месте, чем ему этот процесс нравился или не нравился и подобное.
Tdr
13.10.2018 13:56разговоры «за жизнь» — очень важная часть собеса. Если человек «э слыш, иди сюда!» то, скорее всего, с ним сложно будет работать. Работа в команде подразумевает не только техническое общение, но и «привет как дела» за чаем.
evseev
13.10.2018 08:20+1Приятно читать, что бывают и адекватные работодатели.
Я бы к вашей методике добавил вот что. Тестовый проект должен быть предоставлен в виде ссылки на Git (или на то, что обычно использует соискатель). По логу очень хорошо видно как работает человек. Или все последовательно закомичено и видны все этапы или комит только один. К тому-же точно убедитесь, что человек умеет пользоваться Git-ом ;) А то случаи разные бывают.
В тестовом задании или на втором этапе соискателю можно предложить применить ту технологию, которую он не знает. Это покажет как быстро он учится и умеет-ли вообще это делать. На самом деле это куда более важно чем то, что человек знает.
И я бы не стал делать упор на технической части собеседования. Я же не думаю, что в вашей команде все работают исключительно под давлением, интернета у вас нет, а использование документации карается штрафами. Обычно на собеседовании человек расскажет вам примерно половину, а то и треть от того, что он знает в обычной ситуации. А я сильно сомневаюсь, что вам нужен человек, который очень хорошо проходит собеседования ;) А то я знаю такой случай. Взяли человека. Блестяще прошел собеседование. На него возлагали большие надежды. Но по факту оказалось, что он ни рыба ни мясо и вообще ноль без палочки. Но собеседования он проходит великолепно.Tdr
13.10.2018 13:52Всегда специально удаляю git. Могу оставить, если специально попросят, но такого еще не случалось :). В таком логе нельзя увидеть, как человек решает возникающие конфликты и как он ребейзит.
pushthebutton
13.10.2018 14:52+1Статья тронула, спасибо.
Расскажу про свой случай, из последних.
Собеседовался на позицию senior .net fullstack в компанию-аггрегатора рекламных/медиа платформ с мировым именем. На собеседовании мне не задали ни одного конкретного тех. вопроса. Все вопросы в духе «а делали вот это? а работали с этим? как относитесь к тестовому заданию ?».
Ближе к вечеру прислали тестовое задание: нужно было написать клиента для гитхаба, производящего поиск по репозиториям согласно поисковому запросу. Результаты сохранять в бд, должна быть сортировка по куче полей с гитхаба. Плюс каждый репозиторий, из результата поиска, должно быть возможным обновить (для получения дифа по звездам, коммитам и т.д). Итого: бд + бек с орм + ui. В итоге тянет на готовый продукт. Срок реализации, по условиям, 2-3 дня.
Лично мне, для выполнения задачи, пришлось бы потратить порядка двух дней на изучение апи гитхаба и, собственно, реализацию. И таки да — это с полным погружением (~6-8 часов в день).
Передав свою оценку трудозатрат и рентабельности траты времени на реализацию мне ответили — наш джун сделает это меньшем, чем за день. Немного подгорело, но ладно.
Мое видение тестовых заданий — максимум пара часов дома, без потенциала готового продукта.Gesper
13.10.2018 19:08+1Но ведь все правильно получилось. Вы поняли, что эта фирма не для вас, фирма поняла, что вы им не подходите. Никто не потерял времени. Как по мне, так вин-вин ситуация.
pushthebutton
14.10.2018 11:01Абсолютно не правильно: три специалиста компании потеряли по часу. Я потерял три часа. Результата нет.
Я мог отказаться от вакансии на этапе 0, когда мне прислали ТЗ на тестовое задание.
Newbilius Автор
13.10.2018 19:17Присоединяюсь к @Gespear, плюс добавлю такой момент «что-то показать с GitHub» тоже встречается как типовое мобильное задание, но там обычно нет фильтров или есть какой-то один очень простой. Т.е., написав один раз такое тестовое можно пересылать его потом ещё минимум дюжине других компаний.
Krizai
13.10.2018 17:55+1Учитывая что вы предполагаете один вечер на такого рода задание, что вы предполагаете в нем увидеть? Большинство людей работают на готовых проектах и даже при идеальном понимании архитектуры, вдумчиво воссоздать ее с нуля — дело требующее некоторого времени на обдумывание.
Накидать «абы как» лишь бы работало — да, можно и за вечер. Вдумчиво подойти к архитектуре, учесть корнер кейсы, написать хоть пару тестов — нуууу, я бы сказал дня 3 точно займет.pushthebutton
13.10.2018 19:08+1например решение некоторого кол-ва задач, вырванных из контекста, на время. Без вариантов ответа — нужно писать код. Возможно с мат. уклоном, алгоритмических, архитектурных и или просто на знание платформы.
Желающих тратить даже один полный день для выполнения подобного рода задач будет полтора человека: соискатель либо активно ищет и работает или просто по три собеседования в день. И тут выбор — не ходить на работу или на собеседования пару дней ради работы над тестовым заданием, с крайне туманным профитом.
Newbilius Автор
13.10.2018 19:41Тесты в нашем случае совсем не обязательны, а смотреть будем на многое: как автор работает с базой (и какой базой), как перемещается между экранами (и что выбрал в качестве экранов — например на android можно выбрать activity или fragment), как валидирует ввод, использует ли IoC контейнер и т.п. Интересно, какие из типовых решений выберет кандидат, а потом на собеседование — послушать аргументацию, пообсуждать, почему не выбрать другое решение и так далее. И аргументация не менее важна, чем само решение.
Krizai
14.10.2018 10:47Вы не совсем поняли мой поинт. Да, все это можно проверить, но кроме того вы наверняка будете ожидать увидеть зачатки тестируемой, расширяемой архитектуры, грамотно разбитой по слоям. И эта задача сильно отличается от повседневной работы 99% разработчиков, а потому потребует достаточно много времени. Если же вы этого не ожидаете, то как прелагали выше — почему бы не проделать всю эту работу за кандидата, предоставив ему готовое приложение в котором нужно доработать какую-то часть?
Newbilius Автор
14.10.2018 12:48А это ещё один момент, который можно проверить: насколько кандидат умеет не оверинженерить без лишней необходимости ;-)
eugene_bb
Для «Этап 1» — сделайте базовое тестовое приложение и просите доработать до ваших требований. т.е. всю никому не интересную, первоначальную рутину которая занимает 80% времени сделаете сами. Сэкономите время соискателям и в реальной работе это делается один раз для приложения и скорее всего разработчику может даже и не посчастливиться заняться этим в вашем проекте.
Плюс будет возможность сравнивать решения созданных с одинаковых начальных условий.
Можно даже пару более-менее работоспособных экранов создать с использованием плохих практик и попросить поправить на хорошие.
Newbilius Автор
Вообще мне нравится идея базового тестового, но у нас сейчас соль в том, что нам интересно узнать, как именно разработчик решит задание с нуля. Какие библиотеки использует для упрощения своей работы и т.п. Мы же ищем миддла, у него должен быть наработан какой-то опыт ;-)
А вот подготовить не просто пример плохого кода, а прямо работоспособные экраны — мысль интересная, спасибо!
eugene_bb
Ну тогда я бы посоветовал дать задание трём вашим мидлам (того уровня который вы ищете), пройти подобное тестовое задание, попросить их задокументировать временные затраты и вопросы возникшие при выполнении задания. Только попросить их всё предельно честно и не занижать потраченное время. А то они чтобы не казаться туповатыми, могут сказать три часа перед сном, а в реальности потратить все выходные.
Используйте это как baseline и по результатам отчетов, составьте FAQ в помощь соискателям.
turlir
Подход с тестовым заданием оправдан, если одно и то же задание (а зачастую они похожи) принимают несколько потенциальных работодателей. Домашний проект может стать хорошей отрывной точкой, при необходимости его можно дорабатывать под требования разных команд. История в Git покажет как у разработчика менялись подходы к решению проблем.
evseev
А я за написание с нуля. Верстка займет не так уж много времени. Требования к дизайну-же никто не предлагает. Накидал элементы и пошел дальше. Но сама по себе она то же может много сказать о кандидате. Скажем есть разница если в XML Linear, Relative или Constraint. Поля для всех элементов идут в одном порядке или в разнобой. Кто-то скажет, что и так ведь работает, а кто-то заметит, что сопровождать легче если есть система. Можно просто накидать абы работало, а можно более-менее разложить. Все-таки для разработчика системность, аккуратность и последовательность достаточно важные качества.
А дальше, если говорить о мидле, у каждого свой подход и предрасположенность к инструментам. Кто-то любит Butter Knife, а кто-то AnroidAnnotation, кто-то использует Room, а кто-то только GreenDAO. Зачем ограничивать? Тем более, что со знакомыми инструментами соискатель задачу выполнит быстрее.
К тому-же базовый проект нужно будет все время держать в актуальном стоянии. Я думаю ни для кого не секрет, что обновление библиотек может привести к многочасовой потере времени. А это мало похоже на заботу о соискателе.
И по поводу плохих практик. Бывает проекты приходят к нам уже готовыми и нужно что-то в них добавить или переделать. И делаем мы это за деньги. Если в каждом таком проекте исправлять все, что плохо, а не просто сделать свою работу, то это затягивается до бесконечности. А хорошие практики соискатель и так покажет в своем коде. А вот дать почитать чужой код- полезно. Причем не с закидонами, а самый обычный. Мы же все нормальные люди и пишем так, что бы потом это можно было сопровождать? ;)
eugene_bb
Да кто же спорит что для работодателя как будто бы лучше. Позволяет взглянуть на кандидата ширше и глыбже.
Но на самом деле, скорее всего будет хуже. Особенно если имя работодателя не Google, а Р&К.
Возьмём для примера что на позицию в Р&К обратилось 20 человек. Позиция привлекательная, с зарплатой выше рыночной и т.п.
У 5-ти есть собственный проект который они не стыдятся (или не осознают что надо бы стыдиться) показать потенциальному работодателю. Может они в целом выше среднего из этих 20-ти, а может прочитали что не плохо бы иметь ссылку на гитхаб и пытаются хакнуть процесс устройства на работу, накопировав чужой код или потратив гораздо больше усилий, по сравнению с тем как обычно работают.
Остальным 15-ти предложили пройти тестовое задание. Если у нас рынок работодателя, то он на коне, ну а если работника (как сейчас в IT), то не очень.
Из оставшихся пятеро сразу скажут — у меня правило, кто просит сделать тестовое задание забесплатно, идёт по маршруту.
А наиболее адекватные из оставшихся 10-ти, скажут: «ну у меня уже три потенциальных предложения в кармане, Р&К конечно предлагают условия получше, но не в разы. Стоит ли тратить время на тестовое задание?»
Половина из них может и решит посмотреть на условия тестового задания. Вот тут и вступает в роль что за задание и на сколько легко ему начать его делать. Бросают то обычно в самом начале, потом уже жалко потраченных сил.
Что получается в итоге? Выиграл работодатель? Не думаю.
Из тех кого следовало бы взять, до следующего шага добралась лишь небольшая часть. И чем муторней процесс старта в тестовом задании, тем их меньше.
Поэтому я и говорю, если уж так хочется тестовое задание, сделайте процесс как можно проще. Предоставьте хорошее описание задания, ответы на часто задаваемые вопросы по заданию, дайте тестовые/демонстрационные данные, полуфабрикат проекта, сделайте это задание сами (для оценки его адекватности).
Я сам уже давно не устраивался на работу (мне никогда тестовое задание не предлагали, может тогда ещё не модно было), но в последние пару лет проинтервьюировал человек двадцать. По моему опыту и тестовое задание не надо, такой шлак идёт что сразу отсеиваются. Из них реально человек пять нормальных было, троих взяли. Не потому что хорошие, а потому что люди нужны, а выбирать особо не из чего.