Проблемы в собеседовании на позицию программиста
Мне так сильно понравилось ваша вакансия и ваша компания и ваши идеалы корпоративной культуры, что я решил предложить вам мою скромную кандидатуру. Вот моё супер-уникальное резюме, пришлите тестовое, а еще мы можем пообщаться час-два для того чтобы мы примерно поняли хотим ли мы друг друга.
Преамбула
Я работаю программистом давно. Так сложилось что мне довелось оказаться по обе стороны «баррикад»: я проходил не менее сотни собеседований, чаще получая отказ и проводил не менее пятидесяти собеседований, чаще отказывая.
Обычно меня собеседовали два человека: менеджер\босс и программист\технарь. Реже — один, еще реже — трое и более. Задают вопросы они, как правило, из совершенно разных областей, поэтому разделим условно собеседование на тестовое задание, инспектирование софт скиллов и инспектирование технических скиллов.
Тестовое задание
Вряд ли я отправлю обратно решение к тестовому заданию, если не проверю что оно рабочее и выполняет поставленную задачу. Соответственно на проверку другому программисту приходят, в основном, только рабочие решения, среди которых он должен выбрать те, которые по его оценке (мнению) являются достаточно подходящими. Поработав со множеством программистов в команде я не по наслышке знаю об их лютой нетерпимости к чужому коду, к чужому ходу мысли. Поэтому даже если вы предложите им решение лучшее, чем могло бы созреть у них в голове, вы сильно рискуете нарваться на непонимание и отказ. При этом на просьбу расписать причины, можно получить как совершенно левую ахинею (однажды мне в укор поставили то что я выслал задание в архиве, а не опубликовал его на своём гитхабе, конечно, буду я пачкать своё пространство), так и полный игнор. Поэтому игра в тестовое задание это на самом деле игра в «понравься другому технарю, о котором ты не знаешь ничего», то есть великий рандом.
Кстати, по очередности тестового задания и собеседования вы можете уловить отношения в фирме между менеджером и программистом. Если вам предлагают решать тестовое задание до собеседования, значит менеджер себя считает более загруженным, чем своих подчиненных, пытается сэкономить своё время по максимуму, делегируя базовую проверку. Если же тестовое задание вам предлагают решить уже после собеседования, значит у программистов в фирме в текущее время настолько большая нагрузка, что их даже не отвлекают на проверку тестовых заданий случайных людей. Еще больше отношений вы можете уловить, если собеседование проходит поэтапно, сперва с одними людьми, затем с другими. Надеюсь вы уцепились за суть.
Проверка софт скиллов
«Расскажите о себе?» — вопрос, вводящий в ступор человека с глубоко-техническим складом ума (будем в дальнейшем называть его конструктор). Конструктор может немного покопавшись в памяти вывалить своё имя, возраст, рост и вес, национальность и цвет глаз, но при этом не поймет какое это все имеет отношение к делу, ведь он пришел продавать свой технический скилл, а не себя. «Что конкретно вы хотите обо мне узнать?» — обычно отвечаю я и наблюдаю разочарование в глазах босса, босс редко любит когда ему отвечают вопросом на вопрос, ведь теперь мячик на его стороне и думать приходится ему. Если бы я мыслил по другому, то конечно, я бы вывалил на него заранее подготовленную смачную историю меня любимого с детальными подробностями того насколько я клёвый, классный и, что самое главное, лучше чем остальные. Но если бы я мыслил по другому, я вряд ли стал бы программистом. Поэтому на ответ «что хотите то и рассказывайте» я начинаю тупо перечислять где я работал и какими проектами занимался, плюс какие технологии использовал, чем совершаю очередную ошибку, поскольку всё это уже расписано в резюме и не вызывает ничего кроме скуки. Ведь словами невозможно донести тот объем, вес и значимость, которые я ощущаю в своей голове.
И здесь я делаю допущение: допустим, что программист НЕ ДОЛЖЕН обладать сильными софт-скиллами.
Пойдем от обратного: допустим, что программист ДОЛЖЕН обладать сильными софт-скиллами, тогда — зачем нужен менеджер? Зачем тогда вообще нужна фирма, если я могу пойти на биржу фриланса и найти себе там самостоятельно заказчика? Господин Форд — великий изобретатель прошлого века, он изобрел конвеер, невероятно эффективную вещь, которую, видимо, еще не все научились использовать. В некоторых фирмах просекли эту фишку и вставили между программистами и заказчиками особое звено — менеджеров, по сути являющихся переводчиками с «человеческого» на «программисткий». Задача менеджера — договориться с программистом и заказчиком, задача программиста — «договориться» с кодом. Ожидая от программиста дополнительного повышенного скилла договариваться и коммуницировать, вы отсекаете тех программистов, которые за счет отсутствия этих софт-скиллов освободили в своей голове достаточно места чтобы прокачать скилл разработки гораздо глубже.
Представим себе что мы попали на собеседование в фирму, которая понимает эту идею. Тем не менее оценить общую коммуникабельность она всё равно желает, просто для того чтобы отсеять совершенно неспособных к командной работе людей. Каким образом это можно сделать эффективно за 1-2 часа разговора? Никаким. Я не видел ни одного человека на собеседовании, который вел бы себя распутно, неуважительно или неприемлемо выражался, и это естественно, ведь на собеседовании мы все максимально открыты, дружелюбны и адекватны. Поэтому, пропустив через себя тысячи собеседующихся, собеседующий начинает больше обращать внимание на другие детали: как человек одет, какая у него прическа, как от него пахнет, какие гримасы строит, какие эмоции проявляет, какие жесты использует, как долго смотрит в глаза, как часто отводит взгляд, как быстро отвечает на вопросы. И формирует своё заключительное «экспертное» решение, по сути, на голой интуиции. Ведь перед ним стоит задача «выбрать лучшего на текущий момент», а не «отсеять подходящих от неподходящих», и он не может пойти против этой задачи.
Оценка быстроты реакции — отдельная ошибка. Мгновенно отвечающие люди на самом деле даже не успевают подумать. Люди же тормозящие с ответом, напротив, погружаются в чертоги разума, тщательно взвешивая все возможные варианты, пока чувствуют что было бы уместно еще немного подумать. Даже если у них сразу появляется подходящий ответ.
Проверка технических скиллов
Казалось бы что техническая подкованность на порядки более значима, чем способности к коммуникации, но по факту редко какая фирма устраивает собеседование таким образом, что техническая часть превосходит социальную. Бывают, конечно, исключения, однажды мне довелось 4 часа общаться с очень дружелюбным технарём, от которого я узнал множество интересных, но бесполезных в моей реальной жизни фишек.
Так что же, реально за 1-2 часа разговоров оценить человека достаточно хорошо чтобы принять правильное решение? Конечно же нет. Самая главная ошибка здесь — точно такая же как и в предыдущей части — задача найти лучшего, а не отсеять подходящих от неподходящих. В результате собеседование превращается из поиска знаний в поиск пробелов, ведь чем больше пробелов найдет собеседующий, тем менее подходит кандидат и тем проще сложить-вычесть-посчитать виртуальные очки. Дополнительная ошибка в том что мы проверяем у кандидата наличие лишь тех знаний, которые знаем сами, полностью упуская из виду те знания, которых не знаем, которые могли бы быть намного более полезными в фирме, чем очередная копия меня.
Особенно скользкое в происходящем то, что превращенное в экзамен инспектирование проверяет не способность кандидата программировать, а его способность объяснить, донести, научить, то есть по сути та же самая проверка коммуникативных способностей в иной плоскости. Я, например, могу быстро и качественно спроектировать нормализованную структуру базы данных или нормализовать уже имеющуюся, но совершенно не в состоянии объяснить словами другому человеку как это делать, потому что когда я нормализую, я не использую русские слова, я использую внутренние знания, приобретенные не на парах в университете, а на «боевом» опыте. Эту разницу скиллов между исполнителем и учителем понимают не все. Другой каноничный пример — путаница в шаблонах проектирования. Я быть может и знаю тот шаблон что вы у меня спрашиваете, но в моей голове он называется по другому и его реализация может немного отличаться.
Особенно мной нелюбимое — инспектирование очень мелких и сверх-специфичных деталей, место которым в Гугле, а не в моей голове. За что отвечает третий параметр в функции пузырьковой сортировки? Организуйте очередь двумя стеками. Как сделать выборку так чтобы не так, а вот так? Конечно, хорошо когда эти детали находятся в голове, программист экономит время, а фирма экономит деньги. Но чего вы никогда не узнаете задавая подобные вопросы — это что лежит у кандидата в голове ВМЕСТО этих знаний, знаний такой низкой ценности. Быть может там глубокое понимание асинхронности, а может навык подката к девочкам на вечеринках, но вопрос задан, время потрачено, собеседование на очередной шаг приблизилось к своему завершению, а вы разведали мало значимого.
Про просьбы скомпилировать с бумаги код в голове даже говорить не хочется. Вы на позицию ищите программиста или компилятор\интерпретатор? В повседневной рабочей рутине программист привык полагаться на среду, использовать ее возможности по максимуму, экономя своё «процессорное» время там, где это возможно. Поэтому неудивительно что такого рода задания выполняются медленно и часто не правильно. Вместо них было бы лучше спросить какими средами он пользуется и что ему в них нравится, быть может найдете для себя что-то новое, вкусное.
Есть ли выход?
Если вы вознамерились экономить на мозгах, извините, вы будете продолжать пропускать нужные кадры в погоне за лучшими. Могу лишь обратить ваше внимание на то, что хорошие мозги почти постоянно находятся в поиске места лучше, чем их текущее, поэтому потерять «лучший» мозг так же легко как и «найти».
Если же у вас достаточно бюджета, вы можете попробовать следующий трюк: предложите 1 испытательный месяц работы всем желающим за пол ставки и принимайте решение по результатам работы. Его можно скомбинировать с предварительными собеседованиями, если задачу переключить с поиска лучшего на поиск подходящих, но стоит помнить о том что собеседования такого рода практически бесполезны и лишь отнимают время.
Собеседование на позицию разработчика, как оно есть
Доброго времени суток. На данный момент я занимаю должность Senior/Team Lead IOS Developer. Так вышло, что за последний год мне довелось побывать на огромном количестве собеседований, так сказать, по обе стороны баррикад. Поэтому мне бы хотелось поделиться своим опытом и поговорить о том, как, на мой взгляд, надо проводить собеседование, ведь в общей суматохе можно упустить ряд важных моментов, что, впоследствии, может негативно отразиться на качестве собеседования.
Данная статья будет полезна людям, которые волею судьбы вынуждены проводить собеседования, но при этом не имеют необходимого опыта и плана, как и я когда-то. Все, что описано ниже, является выводами из большого количества проведенных собеседований. Но, как говорится, любое совпадение имен или событий с реальными являются случайностью.
Заповеди
Заповедь номер раз
Ваша задача – определить, что человек знает, а не показать, что вы знаете больше.
С этим сталкивается любой человек, который проводит собеседование впервые. Он воспринимает его как некоторого рода соревнование, где он должен, как и собеседуемый, показать класс. Это не так. Нет сомнений, что Вы, как человек задающий вопросы, сможете изыскать в глубинах интернета и на тайных страницах мануалов вопрос, на который собеседуемый ответить не сможет. Но ведь Ваша задача состоит не в этом.
Заповедь номер два
Ваша задача – выяснить, что данный человек может сделать для Вашей фирмы сейчас и через три месяца, а не то, что он мог сделать год назад.
Мне не раз приходилось проводить собеседование с людьми, которые имели больший опыт, чем я. В первый раз меня это ввело в ступор, было как-то неловко задавать вопросы человеку, который старше тебя, да и в области программирования работает дольше. Но вся неловкость улетучилась, как только он не смог дать внятный ответ на элементарные принципы работы с многопоточностью. Хотя портфолио было внушительным, реальные знания оказались неглубокими. Вы нанимаете человека, который будет работать с вами в будущем, а не того, кем он был 2 года назад.
Заповедь номер три
Ваша задача – определить сможет ли человек влиться в команду.
Вне зависимости от уровня собеседуемого попытайтесь определить для себя, сможете ли вы работать с этим человеком в команде, даже если вы знаете, что делать этого не придется. Однажды на собеседование приходил товарищ, который в течение первых 5 минут умудрился съязвить HR-менеджеру и на протяжении всего собеседования был далек от делового тона, хотя некоторыми знаниями обладал. После собеседования его кандидатура более не рассматривалась, так как никто работать с ним в одной команде не хотел. В свою очередь Вы, как бы вам не нравился человек, должны быть сдержаны и приветливы, так как Вы представляете всю фирму, а он только себя.
То, на что надо обратить внимание
Я работаю на небольшой фирме, и у меня нет в распоряжении толпы HR менеджеров, которые организуют все на высшем уровне, поэтому я опишу некоторые моменты, за которыми необходимо следить.
Собеседование на junior программиста
Цель – выяснить обучаемость собеседуемого.
Для начала выясните, где человек учился или учится (я сторонник того, что для работы программистом необходимо иметь инженерное образование, так как это позволит вам говорить на одном языке). Бог свидетель, ко мне на собеседование приходили люди из музыкальной консерватории, которые прошли 2-месячные курсы по программированию.
Обучаемость может частично компенсироваться усердием. И тут на помощь приходит система образования. Выясните какой у претендента средний балл, учится он платно или бесплатно. Квадратный зад в программировании пригодится.
Для меня наибольшую сложность представляло формирование списка вопросов, так как многие за исключением создания класса или массива вообще ничего не знают.
Вот к чему я пришел в результате экспериментов. Можно пройтись по стандартным вопросам: ООП с примерами, области видимости переменных, переопределение и перегрузка методов, виртуальные функции. Это позволит соискателю понять, что его планируют взять программистом, а не преподавателем младших классов для решения задач про переправу волка и зайчика через мост.
Собеседование на middle/senior программиста
Тут дела обстоят лучше. Перед вами человек с опытом и вам есть о чем поговорить. Если у вас достаточно опыта, вы можете использовать то, что изложено ниже, если нет, то заготовленный список интересных вопросов — отличный вариант. Спустя два десятка собеседований я понял, что вытягивать из человека информацию посредством сухого допроса сложно и скучно. Пусть лучше он расскажет сам.
Начните собеседование издалека. Выясните, чем человек занимался на прошлой работе, какую роль в команде он занимал, доводилось ли ему участвовать в проектировании ПО. Все любят говорить о себе, а еще больше любят, когда их слушают, таким образом, вы превращаете допрос в беседу и снимаете некоторую напряженность с собеседуемого.
Спокойно выслушайте его до тех пор, пока он не упомянёт технологию, которая вас интересует. И вот тут вы начинаете задавать вопросы, даже лучше сказать интересоваться, как бы он, как весьма серьёзный инженер, решил бы некоторую задачу.
Разумеется, надо иметь в голове список вопросов, которых вы бы хотели коснуться, чтобы направлять беседу в нужное русло. Такой тип собеседования позволит проверить очень важное качество человека – его честность. Был следующий случай. Пришел на собеседование человек, который рассказал, что работал на проекте на ведущих ролях, а также что в его проекте было более 50 таблиц в базе данных, не один десяток миграций и обращения к базе идут в разных потоках и много чего еще. Однако при вопросе, как была организована работа с базой из многих потоков, внятного ответа не последовало (см. заповедь 2). Думаю, всем понятно, что место в нашей компании этот человек не получил.
После беседы переходим в наступление. Больше всего я люблю задачи типа «а если». Начинаются такие задачи очень просто, например, «переопределить сеттер для свойства». После чего задача обрастает разного рода дополнительными условиями, классами и ограничениями.
Для сеттера следующим этапом может быть возможность обращения к свойству из многих потоков. Заодно будет повод поговорить о многопоточности в целом, если это не было сделано по «воле» собеседуемого в самом начале.
Во что бы-то ни стало избегайте вопросов типа «знаю/не знаю», ответ на которые можно дать, только если читал об этом. Примером такого плохого вопроса может служить вопрос о внутреннем устройстве узкоспециализированного класса.
Вы должны найти границу знаний собеседуемого, если пробел обнаружен не стоит тратить 10 минут на добивание, лучше двигайтесь дальше. Такой вариант будет приятнее для собеседуемого и продуктивнее для вас. (см заповедь 1).
Если в результате собеседования были даны ответы на все вопросы – грош цена такому собеседованию. Вы не дали собеседуемому в полной мере раскрыть свой потенциал.
Напоследок, коснусь спорного для многих вопроса.«Стоит ли объяснять правильный ответ на вопрос?». На мой взгляд, если человек был близок к решению задачи, ответ может быть оглашен. Однако, если к решению задачи человек не приблизился ни на йоту – смысла что-то ему объяснять я не вижу.
Как вести себя на собеседовании
Заключение
Помните: даже самое хорошо организованное собеседование может провалиться из-за полной бездарности собеседуемого ровно, как и кандидатура лучшего претендента может быть отметена из-за недостаточного опыта собеседующего.
Всем удачный поисков и высококлассных специалистов.
Как проходит собеседование у программистов, что спрашивают
Конкретные знания и способность показать их на интервью – две совершенно разные вещи. Первое собеседование на должность программиста – источник постоянного стресса независимо от возраста. Во время собеседования начинают забываться элементарные вещи, а некоторые вопросы ставят в тупик.
Совсем убрать волнение невозможно, но подготовка к интервью может его уменьшить. В этом гайде мы разберем как лучше готовиться к собеседованию.
Учтите, что само интервью может длиться не один час. В некоторые компании нужно пройти 2 и более раундов. Иногда они идут подряд, превращаясь в многочасовой марафон, иногда разбиты на несколько дней.
Двух одинаковых интервью не бывает. Одни и те же люди, проводят каждое собеседование немного по разному. Очень многое зависит от того, в какую сторону пойдет диалог, какие ошибки совершит собеседующийся и куда приведут его размышления. Более того, даже в рамках одной специализации, разные компании могут спрашивать абсолютно разные вещи. Чем сильнее компания, тем больше фундаментальных вопросов и меньше прикладных. И наоборот. В совсем простых ситуациях, интересуются исключительно прикладными навыками, которые нужны конкретно на этой должности.
Процесс собеседования зависит от вашего предыдущего опыта. Если с вами можно поговорить о прошлых проектах, то, скорее всего, вас начнут расспрашивать про них. Если нет, то тогда пойдут в ход тесты на общую сообразительность.
Ключевые темы
О себе. Прошлый опыт.
Обычно собеседование начинается со знакомства. На этом этапе к вам присматриваются, оценивают общую адекватность и ищут зацепки для дальнейшего разговора. В идеале нужно иметь за плечами реальные проекты с вашим участием. Подойдут и учебные проекты, код которых выложен на гитхабе.
На этом этапе будьте готовы ответить на следующие вопросы:
Задачи
Задачки на эврику или воображение
Существует категория задач, которые было модным задавать на собеседованиях раньше. Первыми, такое стали спрашивать в Microsoft, затем подтянулись и многие другие. Вот несколько примеров:
Сами по себе вопросы интересные. Над ними стоит поломать голову в кругу друзей. Проблема в том, что они слабо коррелируют с уровнем разработчика. Эти вопросы не являются логическими в строгом смысле, они больше опираются на воображение и “эврику”, такое состояние, когда вы внезапно догадались до ответа. Правда ответов обычно больше чем один.
Считается что сам процесс рассуждения над этими вопросами, показывает как у человека работает мозг. С одной стороны показывает, но с другой, состояние стресса и внезапность таких вопросов обескураживает. Более того, интервьюируемый скорее всего не поймет что от него хотят услышать.
Крупные компании отказались от этих вопросов, но никто не застрахован. Всегда есть вероятность, что вас спросят про люки. Поэтому имеет смысл подготовиться заранее. Посмотреть список наиболее распространенных и порассуждать над ними в домашнем кругу или, например, в сообществе Хекслета.
Задачки на логику
Это другой тип задач. Они имеют вполне конкретные ответы и опираются на формальную логику. Например:
Последняя задачка очень сильная и ее часто задают. Хотя она и выглядит мультяшно, внутри нее классная алгоритмическая задача.
Периодическое решение таких задач прокачивает алгоритмические навыки, работу с системами счисления, логическими операциями и математикой.
Алгоритмы и структуры данных
На этом этапе могут попросить реализовать переворот односвязного списка или выполнить сортировку пузырьком. Более сложные вещи писать не просят, их могут спросить устно. Например:
Этого раздела не стоит пугаться, никто не требует от вас глубокого знания алгоритмов и всего прочитанного Кнута. Достаточно прочитать одну книгу и немного попрактиковаться. В любом случае этот опыт не будет лишним, правильно выбранная структура данных в коде, сделает вашу жизнь значительно легче.
Операционные системы и сети
Сюда входит огромный перечень тем, например, владение командной строкой, понимание tcp/ip, http, dns, event loop и многое другое.
Как правило, эти вопросы не задают напрямую. В основном придумывают различные истории или ситуации. Примеры вопросов:
Операции с числами
Популярные задачи на системы счисления и битовые операции.
Problem-Solving задачи
Самый интересный тип задач. В этих задача моделируется реальная ситуация. Вам предстоит придумать способ решения в рамках каких-то ограничений. Например:
Написание кода
Чем меньше у вас опыта, тем выше вероятность того, что вас попросят написать код. Обычно просят написать его на листочке или в среде подобной repl.it. На задачу дают 10-20 минут. Пара примеров:
Во время решения могут попросить рассуждать над задачей вслух. Собеседующий хочет проследить за вашим ходом мыслей.
Эти задачи показывают насколько у интервьюируемого хорошо с логикой, алгоритмическим мышлением, как он владеет базовыми конструкциями языка. Они позволяют отсеять слабых кандидатов, но не помогают определить сильных.
В интернете созданы десятки сервисов, специализирующихся на подобных задачах. Обязательно включите их в свой список для подготовки. Научитесь проходить задачи уровня easy с закрытыми глазами. Этот навык поможет не только для прохождения собеседований, но и в реальном программировании.
Прикладные знания
Сюда входит большая группа вопросов, по тем технологиям с которыми вам придется работать.
Общие
Специфичные
Здесь проверяется знание библиотек, фреймворков, каких-то особенностей языков. В интернете, особенно на гитхабе, созданы списки по каждому возможному стеку.
Как собеседовать инженеров-программистов
Мы в компании Triplebyte проводим много собеседований. В реальности за последние два года я собеседовал более 900 инженеров. Насколько это эффективное использование моего времени — здесь можно спорить (иногда я просыпаюсь в холодном поту и сомневаюсь в этом). Но независимо от моих ощущений, главное, что мы стараемся улучшить процедуру собеседований. Для этого мы проводим собеседования без просмотра резюме (background-blind inrterview), определяем навыки программирования, а не оцениваем заслуги и рекомендации. После того, как инженеры прошли наше собеседование, они направляются для финального интервью напрямую в компании, с которыми мы работаем (включая Apple, Facebook, Dropbox и Stripe). Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.
В этой статье я собираюсь показать, что нам удалось понять к настоящему моменту. Технические собеседования во многом неправильно организованы. Это легко сказать, и во многих статьях об этом говорится. Сложнее исправить эти недостатки. Моя задача в этой статье — справиться с этой задачей и изложить конкретные советы для найма менеджеров и технических директоров. Собеседование — сложная вещь. Но я думаю, что многие проблемы можно решить, если тщательно продумать процесс. Здесь я пишу об оценке технических навыков. В будущих статьях мы поговорим о культурном соответствии, поведенческих интервью и оценке нетехнических качеств.
Статус-кво
Большинство собеседований включает в себя два основных этапа:
Многие финальные интервью расширяют стандартный формат и сильно отличаются друг от друга.
39% компаний, с которыми мы работаем, используют доску с маркером.
52% позволяют работать за собственным компьютером (оставшиеся 9% непоследовательны в выборе доски или компьютера).
55% позволяют интервьюеру самому выбрать вопрос (оставшиеся 45% используют стандартный банк вопросов).
40% хотят видеть академические знания по компьютерным наукам, чтобы сделать предложение кандидату.
15% компаний не хотят видеть академические знания по компьютерным наукам (и думают, что академические разговоры о компьютерных науках — признак того, что кандидат будет работать неэффективно).
80% позволяют использовать любой язык программирования на собеседовании (оставшиеся 20% требуют использовать конкретный язык).
5% подробно оценивают каждую мелочь в использовании языка программирования во время собеседования.
Ложноотрицательные и ложноположительные результаты
Так что не так с текущим положением вещей? По крайней мере, доля уволенных не кажется существенной. Чтобы понять проблему, нужно учесть, что собеседование считается неудачным по двум причинам. Или наймут плохого инженера, которого позже придётся уволить (ложноположительный результат). Или интервью дисквалифицирует кандидата, который мог бы хорошо выполнять работу (ложноотрицательный результат). Неудачный найм хорошо заметен и дорого обходится компании (зарплата, расходы на управление и мораль всей команды). Неудачный найм высасывает энергию из команды. А вот кандидаты, которые могли хорошо выполнять работу, но им не дали шанса, наоборот, остаются незаметными. Каждый случай всегда неоднозначный. Из-за такой асимметрии в спорных ситуациях компании сильно склоняются к отказу.
Этот эффект усугубляется из-за «шума» в процедуре собеседования. Оценить навыки программирования за один час исключительно сложно. Добавьте к этому принцип сопоставления с образцом и субъективные «инстинктивные» чувства, а также сложную смесь особенностей каждой компании, которые обсуждались выше — и вы получите сильно зашумлённый сигнал.
Чтобы удержать уровень ложноположительных срабатываний на низком уровне при столь зашумлённом сигнале, компаниям приходится ещё больше склоняться к отказу кандидатам. В результате они лишаются хороших инженеров, по-прежнему выше ценят заслуги, чем реальные навыки, и часто кажутся своенравными и вызывают разочарование у тех, кто участвует в собеседованиях. Если каждый в вашей компании должен будет пройти повторное собеседование на текущую должность, какой процент его пройдёт? Это пугающий вопрос. Ответом однозначно будет цифра гораздо меньше 100%. Кандидаты страдают от того, что их отвергают компании, где они могли бы отлично работать, а компании страдают от того, что не могут найти таланты.
Чтобы внести ясность, я не агитирую за то, чтобы снизить планку на собеседованиях. Отказ — это суть собеседования! Я даже не говорю, что компании зря боятся ложноположительных результатов намного сильнее, чем ложноотрицательных. Неудачный найм обходится дорого. Я только привожу доводы, что зашумлённый сигнал вкупе со страхом неудачных наймов приводят к действительно высокому уровню ложноотрицательных результатов, и это плохо для всех. Решение в том, чтобы улучшить качество сигнала.
Конкретные способы снижения шума при собеседовании
1. Определите, какие навыки вы ищете.
Нет единого набора навыков, которые определяют хорошего программиста. Наоборот, существует целый океан разнообразных наборов навыков. Никакой инженер не может быть силён сразу во всех областях. На самом деле, мы в Triplebyte часто видим отличных, успешных программистов с абсолютно несвязными наборами навыков. Таким образом, первый шаг к проведению хорошего интервью — определить, какой именно набор навыков подходит для данной должности. Рекомендую задать себе несколько вопросов (это вопросы, которые мы задаём, когда принимаем новую компанию на обслуживание в Triplebyte).
Вам нужны быстрые, итеративные программисты или внимательные и скрупулёзные?
Вам нужен тот, кто мотивирован к решению технических проблем или к созданию продукта?
Вам нужны навыки в конкретной технологии или умный программист, который обучится в ходе работы?
Являются ли важными академические знания компьютерных наук, математики, алгоритмов?
Является ли важным знание параллелизма, модели памяти C или HTTP?
На эти вопросы нет правильных ответов. Мы работаем с успешными компаниями, которые выбирают разные варианты в каждом случае. Но самое главное — сделать сознательный выбор на основании ваших потребностей. Нужно избегать случайного выбора вопросов на интервью (или позволяя самому кандидату выбирать). Когда такое происходит, культура программирования в компании может скатиться в направлении, где всё больше и больше разработчиков обладают определённым навыком или подходом к разработке, который не особенно важен для компании, а инженеры без этого навыка (но с другими важными навыками) отвергаются.
2. Задавайте вопросы, максимально приближённые к реальной работе
Профессиональных программистов нанимают для решения больших, разрастающихся проблем на протяжении недель и месяцев. Но у интервьюеров нет недель или месяцев для оценки кандидатов. У каждого из них есть обычно 1 час. А интервьюеры проверяют, насколько быстро кандидаты решают маленькие проблемы, находясь под принуждением. Это другой навык. Да, он имеет отношение к делу (интервью всё-таки не полностью рандомные). Но он не идеально коррелирует с тем, что нужно. Минимизация этой разницы — вот цель разработки вопросов для собеседования.
Этого можно достичь, если вопросы на собеседовании будут максимально приближены к той работе, выполнения которой вы ожидаете от кандидата (или к навыку, который вы пытаетесь оценить). Например, если вы ищете программиста для бэкенда, попросите кандидата разработать конечную точку API и добавить функциональность к ней — это почти наверняка будет лучше, чем решение проблемы обхода графа путём поиска в ширину. Если вас волнует знание алгоритмов, то попросите применить алгоритм к решению конкретной проблемы (например, построить простой поисковый индекс, возможно, с поддержкой BST и HashMap для лучшей производительности при удалении) — это почти наверняка лучше, чем задача на определение, принадлежит ли данная точка вогнутому полигону. А в задачах на отладку почти всегда лучше дать кандидату поработать с реальной кодовой базой, чем просить его решить маленькую проблему на доске.
При этом есть довод и в пользу использования доски с маркером. Как интервьюеру мне не важно, что кандидат помнит наизусть все итераторы из набора itertools в Python. Мне важно, способен ли он найти способ применить эти итераторы для решения проблемы. Когда кандидат чертит на доске, он свободен от ограничений точного синтаксиса и может сконцентрироваться на логике. Но в конечном итоге я думаю, что это неудачный довод, просто потому что не хватает обоснований для использования другого формата. На самом деле вы можете получить все те же преимущества, разрешив кандидату работать на собственном компьютере, но сняв условие на обязательный запуск этого кода (или ещё лучше, проведя собеседование open book, то есть с возможностью искать справочную информацию в Google).
Есть важное предостережение при разработке вопросов, которые отражают реальную работу. Важно, чтобы вопрос был свободен от внешних зависимостей. Например, просьба написать простой веб-скрапер на Ruby кажется хорошей проблемой из реального мира. Однако если кандидату требуется установить Nokogiri (библиотека парсинга на Ruby, которую может быть непросто установить) и ему придётся 30 минут потратить на борьбу с нативными расширениями, то это ужасное собеседование. Не только теряется время, но и уровень стресса у кандидата зашкаливает выше крыши.
3. Задавайте составные вопросы, на которые нельзя быстро ответить
Ещё одно хорошее правило для вопросов на собеседовании — избегать вопросов, на которые существует краткий и полный ответ, то есть существует некий магический фрагмент информации, который кандидат мог заранее прочитать на Glassdoor — и это позволит ему легко ответить на вопрос. Очевидно, это сразу же исключает из числа вопросов головоломки или любые вопросы, требующие озарения. Более того, вопросы должны состоять из нескольких шагов, где каждый последующий шаг основан на предыдущем, а не однократными вопросами о центральной проблеме. Почему ещё это полезно — спросите себя, как вы можете помочь кандидату, который производит общее хорошее впечатление, но застрял на каком-то вопросе. В случае с однократными вопросами, если вы оказываете значительную помощь кандидату, то собеседование провалено. В составной задаче из нескольких частей вы можете помочь на одном этапе, а кандидат успешно пройдёт остальные шаги самостоятельно.
Это важно не только потому что ваши вопросы могут попасть на Glassdoor. Более важно, что составные вопросы снижают уровень шума. Хорошие кандидаты могут из-за стресса застрять на каком-то этапе. Возможность помочь им и наблюдать процесс восстановления — очень существенна. Присутствует значительный шум в том, насколько хорошо кандидат справляется с конкретным кусочком программистской логики, в зависимости от того, сталкивался ли он в последнее время с похожей проблемой, это просто случайная вероятность. Составные задачи из нескольких частей устраняют часть этого шума. Они также дают возможность кандидатам наблюдать, как нарастает эффект. Усилия на одном этапе часто помогают решить задачу на следующем этапе. Это важная динамика реальных процессов разработки, а её изучение во время собеседования уменьшает уровень шума.
Если нужны примеры, то просьба к кандидату реализовать игру «Четыре в ряд» в терминале (серия из многократных шагов), вероятно, будет лучшим заданием, чем просьба повернуть матрицу (единственный шаг, с некоторыми приёмами, которые предельно упрощают задачу). А кластеризация методом k-средних (несколько операций, основанных друг на друге), вероятно, будет лучшим заданием, чем определение крупнейшего прямоугольника, который помещается под гистограммой.
4. Избегайте сложных вопросов
Если кандидат действительно хорошо решил сложную проблему, это много говорит о его способностях. Но поскольку вопрос сложный, большинство кандидатов не смогут хорошо на него ответить. В этом случае ожидаемое количество информации, полученное от вопроса, напрямую зависит от его сложности. Мы пришли к выводу, что оптимальный уровень сложности значительно ниже, чем полагает большинство интервьеров.
Эффект усиливается за счёт того факта, что при собеседовании кандидата есть два источника информации: 1) даёт ли он «правильный» ответ на вопрос и 2) процесс размышления, то есть насколько легко он додумался до этого ответа. Мы в Triplebyte собираем эти показатели (оценка за правильность ответа и оценка за количество усилий, которые ему понадобились для этого, а затем делаем прогноз, какие оценки коррелируют с успехом сотрудника в разных компаниях). То, что мы нашли, — это своеобразный компромисс. Если кандидат отвечает на более сложные вопросы, то мы получаем более сильный сигнал непосредственно от ответа. Для более простых вопросов, наоборот, важнее процесс и то, как сильно мучился кандидат. С учётом обоих источников сигнала оптимум находится ближе к простым вопросам.
На практике выработалось такое правило: сам интервьюер должен решить задачу за 25% того времени, которое он ожидает от кандидата для решения этой задачи. Так что если я разрабатываю новое задание для часового интервью, то мои коллеги (без предупреждения) должны дать правильный ответ за 15 минут. Учитывая факт, что мы предлагаем решать многоступенчатые проблемы из реального мира, оптимальная задача на интервью действительно должна быть довольно понятной и простой.
Чтобы внести ясность, я не агитирую за снижение планки в смысле понижения проходного балла. Я только привожу доводы в пользу простых вопросов и дальнейшей оценки, как кандидаты на них отвечают. Я выступаю за простые вопросы и очень строгую оценку ответов. Вот что лучше всего оптимизирует сигнал, по нашему опыту. Здесь есть и дополнительная польза в снижении уровня стресса для большинства кандидатов.
Приведу примеры. Попросить кандидата создать простой интерфейс командной строки с командами для помещения в хранилище и извлечения оттуда пар ключ-значение (и добавления дополнительной функциональности, если кандидат хорошо справляется), вероятно, будет лучше, чем попросить сделать парсер для арифметических выражений. А вопрос о самых обычных структурах данных (списки, хэши, может быть, деревья), вероятно, лучше, чем вопрос о списках с пропусками, дучах (дерево+куча) или других малоизвестных структурах.
5. Задавайте одинаковые вопросы каждому кандидату
Суть интервью в сравнении кандидатов. Цель — отсортировать кандидатов на тех, кто способен помочь компании и на тех, кто не способен (а в случае заполнения единственной вакансии — выбрать самого лучшего). Учитывая это, совершенно нелогично задавать разные вопросы разным кандидатам. Если вы оцениваете разными способами кандидатов на одну и ту же работу, вы добавляете лишний шум.
Думаю, причина того, что интервьюеры часто выбирают разные вопросы для разных кандидатов — в личных предпочтениях интервьюера. Инженеры в IT-комипаниях обычно не любят проводить собеседования. Это нечто такое, что они делают лишь эпизодически, и это отвлекает от основной работы. Чтобы стандартизировать вопросы для каждого кандидата, интервьюерам придётся потратить больше времени на изучение этих вопросов, усвоить систему оценок и отчётности. И им придётся заново проходить эту процедуру при каждой смене вопроса. И ещё задавать всегда один и тот же вопрос немного более скучно.
К сожалению, единственным выходом для интервьюеров здесь будет приложить больше усилий. Единообразие — ключевой элемент проведения хороших собеседований, а это означает задавать каждому кандидату один и тот же вопрос и стандартизировать отчёты. Здесь просто нет другого варианта.
6. Рассмотрите возможность нескольких путей
Хотя это противоречит предыдущему пункту, но рассмотрите возможность нескольких совершенно разных версий собеседования. С самого начала при разработке интервью подумайте, какие навыки кандидата имеют значение. Но некоторые из ответов могут противоречить друг другу! Например, вполне нормальная ситуация, если компании нужны хорошо разбирающиеся в математике инженеры, но при этом нужны ещё и очень продуктивные/итеративные инженеры (может быть, даже на одну и ту же должность). Для таких случаев рассмотрите несколько путей проведения интервью. Здесь ключевым фактором является то, что масштаб задачи должен позволить полностью стандартизировать каждый из путей. Вот что мы делаем в Triplebyte. Мы пришли к выводу, что можно просто спросить кандидата, какой вариант интервью он предпочитает.
7. Не позволяйте резюме кандидата влиять на вас
Резюме не совсем бессмысленно. Выпускники Массачусетского технологического института и Стэнфорда или с опытом работы в Google и Apple действительно лучше, как группа, чем остальные. Проблема в том, что абсолютное большинство инженеров (включая меня) не принадлежат к этой группе. Так что если компания слишком сильно полагается на эти сигналы, то большинство квалифицированных кандидатов пройдут мимо неё. Учитывать резюме в какой-то степени на этапе предварительной степени может иметь какой-то смысл. Мы в Triplebyte такого не делаем (все наши оценки в «слепых тестах» делаются совершенно без учёта опыта и заслуг человека). Но дать какой-то вес резюме на этапе предварительного отбора имеет смысл.
Но учитывать резюме на этапе собеседования уже совершенно не имеет смысла. А у нас есть данные, что так оно происходит на самом деле. При одинаковых оценках в наших «слепых тестах» кандидаты с дипломом топового университета успешно проходят собеседования в компаниях на 30% чаще, чем кандидаты без брендового названия в резюме. Если интервьюеры знают, что у кандидата есть диплом Массачусетского технологического института, они более склонны закрывать глаза на недочёты во время собеседования.
Это шум, и его следует избегать. Самый простой способ — просто удалить названия университетов и компаний из резюме перед тем, как давать их интервьюерам. Некоторые кандидаты могут упомянуть вуз или компанию во время разговора, но мы всегда проводим интервью, не учитывая эту информацию, и кандидаты очень редко обращают внимание на эти факты в процессе технических тестов.
8. Не издевайтесь над кандидатами
Один из самых мерзких способов провала на собеседовании — когда оно заканчивается издевательским способом. Интервьюеры уже не только оценивают способности кандидата, они также превращаются в участников группы или команды, которая принимает нового члена в свою группу. В этом втором качестве они проводят нечто вроде обряда посвящения. Да, интервью само по себе вызывает стресс, но все мы прошли через этот стресс, так что и кандидатам придётся пройти через него. Ситуация усугубляется, когда кандидат никак не справляется с заданием. В качестве интервьюера вы можете испытать сильное разочарование, наблюдая, как кандидат бьётся головой о стену, решая задачу, где ответ настолько очевиден! Вы можете вспылить и сорваться. Конечно, это только увеличивает стресс для кандидата — и ему становится ещё труднее решить задачу.
Таких ситуаций лучше не допускать ни в коем случае. Решением будет обсудить проблему и обучить интервьюеров, как её преодолеть. Здесь мы используем одну хитрость: когда кандидат вообще не справляется, нужно переключиться из режима оценки, где цель — оценить человека, в режим обучения, где цель — заставить кандидата понять ответ на вопрос. Ментальное переключение из одного режима в другой очень сильно помогает. Когда вы находитесь в режиме обучения, то нет причин скрывать информацию или проявлять какие-то другие эмоции кроме дружелюбия.
9. Принимайте решения на основе максимального навыка, а не среднего или минимального
До сих пор я говорил только об отдельных вопросах, а не о решении на финальном интервью. Здесь мой совет — принимать решение на основании максимального навыка, который продемонстрировал кандидат (среди всех навыков, которые для вас важны), а не на среднем уровне или минимальном.
Вероятно, вы уже поступаете таким образом, умышленно или нет! Окончательное решение принимается на общем собрании всех, кто проводил собеседования, и предложение кандидату делают, если хотя бы один интервьюер настоятельно рекомендует это сделать, а остальные не сильно возражают. Чтобы впечатлился один интервьюер, кандидату достаточно блеснуть на одной секции интервью. Судя по нашим данным, максимальный навык — это атрибут, который сильно коррелирует с тем, чтобы хорошо проявить себя хотя бы на одной секции интервью в компании. Однако, чтобы получить предложение о работе, кандидату также нужно не настроить против себя никого из остальных интервьюеров. Категоричные возражения от них могут появиться, если кандидат выглядел реально глупо при ответе на вопрос.
Здесь мы имеем дело просто с большим уровнем шума. Существует так много областей деятельности высококвалифицированного инженера, что почти ни один человек не способен достичь совершенства во всех областях сразу. Это значит, что если вы зададите правильный (или неправильный) вопрос, то любой инженер может выглядеть глупо. После этого кандидаты получают предложения в том случае, если хотя бы одно собеседование затронуло зону прочных знаний (максимальный навык) и ни одно не затронуло области значительной слабости. Проблема в том, что это увеличивает уровень шума. Один и тот же инженер, проваливший одно интервью, потому что выглядел глупо после вопроса о сетевых технологиях, блестяще проходит остальные интервью, где эта тема не затрагивалась.
По-моему, лучше всего компаниям сконцентрироваться на максимальном навыке и не так сопротивляться найму сотрудников, которые плохо проявили себя в отдельных секциях собеседования. То есть искать сильные аргументы в пользу кандидата и не беспокоиться так сильно о технических областях, где он слаб. Здесь я не хочу быть однозначно категоричным. Конечно, есть технические обалсти, которые просто очень важны для компании. И ваше решение, что все сотрудники должны иметь определённый уровень знаний в этих областях, вполне имеет смысл. Но концентрация именно на максимальных навыках кандидата реально уменьшает шум на собеседовании.
Зачем вообще проводить собеседования?
Последний вопрос, который я хотел бы задать — зачем вообще проводить собеседования? Уверен, что многие читатели уже скрипели зубами, приговаривая: «Какой смысл так подробно обсуждать неэффективную систему? Просто используйте домашние задания! Или просто берите людей на испытательный срок!» В конце концов, некоторые очень успешные компании действительно применяют испытательный срок (где кандидат работает с командой в течение недели) или полностью заменяют личные собеседования домашними заданиями. Испытательный срок во многом имеет смысл. Провести неделю бок о бок с новым сотрудником (или смотреть, как команда с ним выполняет важный проект) почти всегда даёт лучшую оценку навыков кандидата, чем наблюдение в течение всего лишь одного часа, как он решает задачи. Однако есть две проблемы, которые не дают испытательному сроку заменить стандартные собеседования:
Обсуждения опыта работы над прошлыми проектами тоже часто рассматривают как замену техническим собеседованиям. Логика такая: чтобы убедиться, что кандидат успешно выполнит работу в будущем, просто посмотрим, что он делал в прошлом. Мы в Triplebyte пробовали такую методику. К сожалению, она не показала хороших результатов. Выяснилось, что коммуникативная способность (способность продавать себя) оказалась более сильным сигналом, чем технические способности кандидата. Просто слишком часто возникает ситуация, когда умеющий красиво говорить кандидат преувеличивает свою роль (присваивает результат всей команды) или когда скромный человек преуменьшает свои заслуги. При наличии достаточного времени и достаточном количестве вопросов можно докопаться до сути. Однако мы выяснили, что при стандартном ограничении по времени обсуждение прошлого опыта не является универсальной заменой собеседованию. Это хороший способ растопить лёд в начале разговора, понять смысл интересов человека (также оценить коммуникационные способности и культурное соответствие). Но обсуждение прошлого опыта не подходит в качестве полной замены собеседованию.
Кое-что хорошее о программистских собеседованиях!
Хочу закончить эту статью на более приятной ноте. Наряду со всеми недостатками собеседований, они всё-таки приносят большую пользу.
Собеседования — это прямая оценка способностей. У меня есть друзья, которые работают учителями. Они говорят, что интервью учителей — это, в основном, оценка коммуникативной способности (умения продавать себя) и резюме/рекомендации. Судя по всему, такая ситуация во многих, многих профессиях. Кремниевая долина — не идеальная меритократия. Но мы по крайней мере пытаемся напрямую измерить навыки, которые имеют значение, и придерживаемся идеи, что любой человек с такими навыками может стать хорошим профессионалом, независимо от его образования и опыта работы. Оценка резюме часто этому мешает. Но мы в Triplebyte сумели во многом преодолеть эту проблему и помогаем большому количеству людей с нестандартными резюме получить отличную работу в IT. Сомневаюсь, что компания вроде Triplebyte смогла бы работать, например, в юридической сфере. Там слишком сильно полагаются на резюме и рекомендации.
Программисты тоже предпочитают собеседования. Хотя это очень спорная тема (наверняка найдутся программисты с иной точкой зрения), но когда мы проводили эксперименты с альтернативными методами оценки кандидатов, большинство программистов по-прежнему выбирали стандартные собеседования. И мы обнаружили, что только небольшую часть программистов интересуют компании, которые предлагают испытательный срок или домашнее задание. Хорошо это или плохо, но судя по всему, собеседования для программистов никуда не денутся. Другие способы — это хорошее дополнение, но вряд ли они заменят интервью как основной способ оценки программистов. Если неправильно процитировать Черчилля: «Собеседование — самый худший способ оценить инженера, если не считать остальных способов, которые мы иногда пробуем».
Заключение
Собеседование — непростая штука. Человеческие существа безнадёжно сложны. В каком-то смысле попытка оценить возможности человека за 4 часа собеседований кажется дурацкой. Думаю, здесь важно сохранять скромность. Любой процесс собеседования обречён на частые неудачи. Люди просто слишком сложные.
[1] Конечно, здесь есть разные варианты. На противоположных конца спектра находятся компании, которые требуют единогласного положительного решения от каждого интервьюера, и компании, где HR-менеджер единолично принимает решение. ↑
[2] Это цифры из внутренней статистики самих компаний об их собственных кандидатах. И они сильно отличаются в разных компаниях (например, доля уволенных, варьируется от 1% до 30%). У кандидатов Triplebyte цифры значительно лучше. К настоящему моменту наши кандидаты получают предложения о работе после 53% собеседований, а уровень уволенных составляет 2%. ↑