Как один вопрос стал способом провести самое успешное интерв
От: Пирожочек  
Дата: 07.10.15 03:14
Оценка: 93 (18) +3
----- от переводчика -------
Disclaimer: перевёл just for fun, перевод местами вольный, готов к конструктивной критике по качеству перевода
Кому понравилось — ставьте лайк, кому очень понравилось — подписывайтесь

Приятного чтения,
Пирожочек.
------------------------------

Как один вопрос стал способом провести самое успешное техническое интервью.

(оригинал: How I ended up conducting the most successful technical interviews with a single question из блога Nicolas Bize )


Процесс найма

Значительную часть моей предыдущей работы занимал процесс найма и проведение технического интервью. Этот процесс был достаточно прямолинеен:

1) Интервью, проводимое HR-менеджером, определяло, является ли кандидат психопатом/серийным убийцей

2) Интервью, проводимое техническим специалистом, определяло, является ли кандидат хорошим разработчиком

3) Интервью, проводимое Большим Боссом, определяло, насколько много кандидат хочет денег

Я проводил интервью для двух типов людей: интернов и будущих сотрудников. Интерны проходили только интервью из пункта #2, в то время как остальные проходили через все три этапа. За более чем два года, что я работал в компании, я провёл должно быть более двухсот технических интервью. Это был поучительный процесс для меня и я осознал это шаг за шагом. Сейчас для вас важно отметить, что это происходило во Франции, где вы просто не можете увольнять людей. Нанимаете плохого парня и вы с ним остаётесь навсегда. Поэтому очень критично пропустить через фильтр только лучших кандидатов и не ошибиться с выбором. Это был утомительный процесс и я любил каждую его часть.


Очень специализированые вопросы

Я провёл моё первое техническое интервью в 2008-м. В то время в компании уже был рабочий процесс которому я следовал: интервью занимало 1 час, кандидатам давалось 30 минут для ответа на 15 вопросов, затем мы тратили 15 минут обсуждая их ответы и ещё 15 минут, отвечая на их вопросы о работе. Я быстро осознал, насколько ужасен был список вопросов. Имею ввиду, что если бы вы сами его состовляли, врятли бы у вас получилось придумать что-либо более ужасное. Около 50% проектов компании были на Java, поэтому вопросы были очень java-центричны. Пять из вопросов были тривиальными, оставшиеся десять были очень сложными вопросами, специфичными для основных используемых нами java-фреймворков:

Это начиналось с:

- В чём разница между классом и объектом?


и заканчивалось

- Какое назначение имеет обработчик execAndwait в фреймворке struts 2 ?



Чёрт, даже я не смог бы объяснить или рассказать половину вещей, о которых я спрашивал... Каждый раз я молился, чтобы они не стали расспрашивать меня о вопросах! Достаточно иронично для интервьювера... Как бы там ни было, я довольно быстро (2-5 минут) просматривал их ответы и тратил остаток времини, обсуждая резюме. Это занимало много времени и я хотел улучшить процесс. Поэтому я пошёл в интернет и просмотрел сотни вопросов для интервью. В то время я верил в формат "список вопросов". Он должен был всего лишь содержать правильные вопросы для определения, насколько хорош народ. Правильный опросник для правильных людей.


Очень обобщённые вопросы

После почти месяца поисков я остановился на пятидесяти вопросах, которые я смог найти онлайн. Я чувствовал что это были хорошие вопросы, потому что для ответа на них не требовалось знания определённого языка, и они были в порядке постепенного нарастания сложности. Я разбросал 50 вопросов и составил пять наборов по 10 классных вопросов, которые я мог бы раздавать в случайном порядке.

Например:

Что такое синглтон и когда вы бы могли его использовать/не использовать?


Это было намного лучше. Или просто я так думал... Вопросы были хороши, и я хотел бы, как правило, получать на них хорошие ответы. Несколько последующих недель я задавал эти вопросы, но всё равно чувствовал что что-то не так. Я не мог избавиться от ощущения, что даже если то, что я сделал — сделано хорошо, это всё ещё не было сделано на отлично. Да, я тестировал человека на знание теории программирования, но в результате я оставался без малейшего понятия, умеет человек программировать или нет. В конечном итоге я не уверен, что мы наняли кого-то лучше, используя этот метод, нежели используя древний "struts 2" список вопросов. Чем больше я думал об этом, тем больше я осозновал, что у этих пяти наборов было два больших недостатка.

1) Вопросы были слишком абстрактные. Преследуя цель не привязываться к языку, я не мог говорить об SQL, фронт-енд специфике и т.д.

2) Вопросов было мало. Десять вопросов общего характера просто недостаточно. У меня не было возможности понять, кто был хорошим разработчиком, кто нет.

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


Менеджер вопросов 3000

Здесь всё пошло немного на перекосяк. Я ломанулся и создал ( с помощью интерна ) полностью автоматизированную систему генерации вопросов. Менеджер Вопросов (МВ). Система делала процесс найма идеальным. HR мог выбрать три темы, относящиеся к вакансии, инструмент затем автоматически создавал тест с 3*20=60 случайными, но специфичными вопросами и сложностью, зависящую от опыта соискателя.

Например:

(javascript)
var i = 0;
function a(){
  var i = 2; 
  i++;
} 
a(); 
alert(i);    =>    0 ? 2 ? 3 ?


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

Что ж... Обнаружилось что многие из наших лучших разработчиков набирали столько же очков, как и некоторые люди, которым я отказал. Всё верно, бесполезность МВ доказана математически! Я потратил так много времени на разработку этой системы, что мне понадобилось немало времени для осознания того, насколько сильно я ошибся: наше желание автоматизировать результаты ограничило мой выбор вопросов только такими вопросами, где нужно выбрать верный ответ из предложенных. Человек мог выбрать только один ответ, а вопросы в конце концов были в основном о программерских "трюках". Результатом было то, что мы не тестировали умение грамотно инженерить софт абсолютно! Мне было тяжело проглотить горькую пилюлю для своей гордыни, но всё же я признал в итоге контрпродуктивность Менеджера Вопросов, который отражал скиллы разработчиков ещё хуже чем всё остальное.


Просто пусть напишут код

Прошло 8 месяцев с начала моей работы. Я провёл ещё немного исследований и отметил, как некоторые компании в США проводили отбор кандидатов. Именно в тот момент я решил пойти другим путём: просто дать им покодить. Это ведь то, за что они получают деньги, так почему бы им сразу не показать, насколько они хороши в этом. Довольно логично, если подумать... Кое-чему научившись за первые месяцы работы, тест с вопросами стал довольно прост: я давал три алгоритма и 30 минут на их решение. Кандидаты могли выбрать удобный для себя язык программирования и им предоставлялся компьютер ( без доступа в интернет ). Это были классические алгоритмы, найденные в интернете. Один алгоритм обычно был связан с обработкой строк ( навроде "поменять порядок слов в предложении" ), другой был завязан на рекурсию ( навроде "найти элемент в последовательности Фибоначчи" ), и последний алгоритм был связан с коллекциями ( навроде "упорядочите элементы списка" ).

Пример одного из вопросов:

выведите на печать числа от 1 до 100.
для чисел, делящихся на 3, выведите "foo".
для чисел, делящихся на 5, выведите "bar".
для чисел, делящихся на 3 и на 5, выведите "foobar".


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

Поначалу я был доволен результатами, и это ощущение продлилось несколько месяцев. Но затем я снова стал чувствовать, что я что-то упускаю... Что-то я делал неправильно... Да, это правда, я мог легко отличить тех кто мог решить алгоритмы от тех кто не мог. Но были ли они в действительности теми классными разработчиками, которых я искал? Когда задумываешься об этом... Действительно ли качество разработчика определят то, как он умеет решать математические проблемы? Или то, умеет он или нет сортировать список за O(n log n), а не за O(n^2) ?


Один вопрос, который стоит всех остальных

Я точно помню, когда я начал программировать. QBasic поставлялся вместе с MSDOS 5.0 задолго до выхода Windows 3.1. Он содержал собственную справочную систему с описанием всех функций и ключевых слов языка, словно идеальная оффлайновая man-страница. До сих пор я отчётливо помню то чувство, которое охватывало меня каждый раз когда я жал F5 и видел как моя программа исполняется прямо на моих глазах. Вывод строки, запрос имени, игра с цветами, ребус... Я был счастлив. Я помню как я вписывал номера строк перед каждой командой, наполнял код ужасными GOTO, с восторгом и очарованием изучал что-нибудь новое каждый день. Я любил программирование. Я мог тратить час за часом создавая игры, решая задачи, показывая всякую всячину своим родителям и друзьям. Шли годы, я прошёл путь от qbasic до pascal, до vb, написал игры для нашей бибиэски "Атомная BBS", которые мы запускали из дома по телефонной линии через модем на 2400 бод. Я не был хорош. Что ж, по-факту я был сосунком и мой код был ужасен! Но послушайте, я любил это! Я просто не мог без этого жить... Я думаю некоторые люди чувствуют подобное когда они в первый раз полетели на самолёте, вышли в море на лодке, покурили травку, съели супербургер "in-n-out"... Для всего этого мне заменой было программирование, компилирование, запуск. Я приобрёл это чувство 25 лет назад, и с тех пор оно всегда со мной. Я был рождён для этого. Я всегда был программистом.

Я всегда был уверен, что те, кто любят программирование, не ограничивают себя только работой. Они несут эту любовь домой и продолжают создавать программы для души, как хобби. Сколько раз я чувствовал себя разочарованным на работе из-за глючащего эклипса, находя утешение и радость только когда пишу на ruby on rails дома!

В итоге, после почти года проб и ошибок, я полностью перестал обращаться к техническим тестам. Мы садились с кандидатом, я читал и комментировал его резюме не спрашивая у него ни единого вопроса, так продолжалось добрые 5-10 минут. Затем я переварачивал резюме, смотрел кандидату в глаза и задавал вопрос: "у нас осталось около получаса, расскажите пожалуйста о лучшем проекте, который вы создали?"

Этот единственный, уникальный и не требующий оценки вопрос был ключом. Некоторые смутно рассказывали об их предыдущей работе или школьном проекте, в то время как другие внезапно оживали и становились воодушевлёнными, даже те, кто сперва показался стеснительным. Они страстно рассказывали мне об играх, которые они создавали, веб-страницах, опенсорс-проектах, в которых учавствовали, утилитах, которые они сделали когда застревали в местах где в округе не было ни души, не говоря уже о доступе в интернет. Они были горды, рассказывая это. И я всегда был очарован тем что слышал, и спрашивал о каждой детали проекта, который для них был драгоценностью. Люди раскрывали себя и рассказывали о технических сложностях, которые им пришлось преодолевать, о вкладе частички себя в проект. Это был их ребёнок. И то, как они рассказывают о нём невозможно не заметить: я мог видеть свет в их глазах, детский восторг ребёнка который собрал и запустил свой первый hello world. И тогда я знал, что у нас есть что-то общее. Они тоже были программистами.

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

Они были программистами в сердце.

Ведь в конце концов, это единственное, что действительно имеет значение.
Отредактировано 07.10.2015 5:38 Пирожочек . Предыдущая версия . Еще …
Отредактировано 07.10.2015 5:37 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 5:15 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 5:11 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 3:17 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 3:17 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 3:17 Пирожочек . Предыдущая версия .
Отредактировано 07.10.2015 3:16 Пирожочек . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.