Как собеседовать инженеров-программистов

https://triplebyte.com/blog/how-to-interview-engineers
  • Перевод
Мы в компании Triplebyte проводим много собеседований. В реальности за последние два года я собеседовал более 900 инженеров. Насколько это эффективное использование моего времени — здесь можно спорить (иногда я просыпаюсь в холодном поту и сомневаюсь в этом). Но независимо от моих ощущений, главное, что мы стараемся улучшить процедуру собеседований. Для этого мы проводим собеседования без просмотра резюме (background-blind inrterview), определяем навыки программирования, а не оцениваем заслуги и рекомендации. После того, как инженеры прошли наше собеседование, они направляются для финального интервью напрямую в компании, с которыми мы работаем (включая Apple, Facebook, Dropbox и Stripe). Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.

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

Статус-кво


Большинство собеседований включает в себя два основных этапа:

  • Отбор кандидатов.
  • Личное финальное интервью.

Цель отбора — отфильтровать кандидатов на первом этапе и сэкономить время инженеров на интервью. В процессе отбора рекрутер обычно сканирует резюме кандидата (примерно за 10 секунд), после чего беседует с ним по телефону от 30 минут до часа. 80% компаний, с которыми мы работаем, дают кандидату ещё и домашнее задание (или вместо телефонного интервью, или вдобавок к нему). Интересно, что на этапе отбора отсеивается подавляющее большинство кандидатов. В самом деле, среди всех компаний, с которыми мы работаем, более 50% кандидатов отсеивается уже после сканирования резюме, а ещё 30% отсеиваются после телефонного собеседования и домашнего задания. Предварительный отсев — тот этап, где процедура найма особенно капризна. Рекрутеры подавлены огромным количеством резюме, им приходится принимать мгновенные решения. Здесь вступают в силу заслуги кандидатов и принцип сопоставления с образцом.

Личные финальные интервью почти всегда состоят из серии 45-60-минутных сессий, каждая с новым интервьюером. Это, в основном, технические сессии (плюс одна или две для каждой компании на культурное соответствие и личные качества). Окончательное решение о найме кандидата принимают на общем совещании после ухода кандидата, с участием HR-менеджера и всех, кто проводил собеседования с кандидатом. По сути, для положительного решения нужно, чтобы кто-то один настаивал на нём, а у остальных не было особых возражений [1].

Многие финальные интервью расширяют стандартный формат и сильно отличаются друг от друга.

39% компаний, с которыми мы работаем, используют доску с маркером.

52% позволяют работать за собственным компьютером (оставшиеся 9% непоследовательны в выборе доски или компьютера).

55% позволяют интервьюеру самому выбрать вопрос (оставшиеся 45% используют стандартный банк вопросов).

40% хотят видеть академические знания по компьютерным наукам, чтобы сделать предложение кандидату.

15% компаний не хотят видеть академические знания по компьютерным наукам (и думают, что академические разговоры о компьютерных науках — признак того, что кандидат будет работать неэффективно).

80% позволяют использовать любой язык программирования на собеседовании (оставшиеся 20% требуют использовать конкретный язык).

5% подробно оценивают каждую мелочь в использовании языка программирования во время собеседования.



Среди всех компаний, с которыми мы работаем, 22% финальных интервью заканчиваются положительным решением о найме. (Эта цифра получена по внутренней статистике самих компаний исходя из их собственной процедура отбора кандидатов. Для кандидатов, которые проходят через Triplebyte, положительное решение принимают в 53% случаев). Около 65% предложений принимаются кандидатами (и они получают работу). После одного года работы компании выражают удовлетворение относительно примерно 30% новых сотрудников и увольняют около 5% [2].

Ложноотрицательные и ложноположительные результаты


Так что не так с текущим положением вещей? По крайней мере, доля уволенных не кажется существенной. Чтобы понять проблему, нужно учесть, что собеседование считается неудачным по двум причинам. Или наймут плохого инженера, которого позже придётся уволить (ложноположительный результат). Или интервью дисквалифицирует кандидата, который мог бы хорошо выполнять работу (ложноотрицательный результат). Неудачный найм хорошо заметен и дорого обходится компании (зарплата, расходы на управление и мораль всей команды). Неудачный найм высасывает энергию из команды. А вот кандидаты, которые могли хорошо выполнять работу, но им не дали шанса, наоборот, остаются незаметными. Каждый случай всегда неоднозначный. Из-за такой асимметрии в спорных ситуациях компании сильно склоняются к отказу.

Этот эффект усугубляется из-за «шума» в процедуре собеседования. Оценить навыки программирования за один час исключительно сложно. Добавьте к этому принцип сопоставления с образцом и субъективные «инстинктивные» чувства, а также сложную смесь особенностей каждой компании, которые обсуждались выше — и вы получите сильно зашумлённый сигнал.

Чтобы удержать уровень ложноположительных срабатываний на низком уровне при столь зашумлённом сигнале, компаниям приходится ещё больше склоняться к отказу кандидатам. В результате они лишаются хороших инженеров, по-прежнему выше ценят заслуги, чем реальные навыки, и часто кажутся своенравными и вызывают разочарование у тех, кто участвует в собеседованиях. Если каждый в вашей компании должен будет пройти повторное собеседование на текущую должность, какой процент его пройдёт? Это пугающий вопрос. Ответом однозначно будет цифра гораздо меньше 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. Принимайте решения на основе максимального навыка, а не среднего или минимального


До сих пор я говорил только об отдельных вопросах, а не о решении на финальном интервью. Здесь мой совет — принимать решение на основании максимального навыка, который продемонстрировал кандидат (среди всех навыков, которые для вас важны), а не на среднем уровне или минимальном.

Вероятно, вы уже поступаете таким образом, умышленно или нет! Окончательное решение принимается на общем собрании всех, кто проводил собеседования, и предложение кандидату делают, если хотя бы один интервьюер настоятельно рекомендует это сделать, а остальные не сильно возражают. Чтобы впечатлился один интервьюер, кандидату достаточно блеснуть на одной секции интервью. Судя по нашим данным, максимальный навык — это атрибут, который сильно коррелирует с тем, чтобы хорошо проявить себя хотя бы на одной секции интервью в компании. Однако, чтобы получить предложение о работе, кандидату также нужно не настроить против себя никого из остальных интервьюеров. Категоричные возражения от них могут появиться, если кандидат выглядел реально глупо при ответе на вопрос.

Здесь мы имеем дело просто с большим уровнем шума. Существует так много областей деятельности высококвалифицированного инженера, что почти ни один человек не способен достичь совершенства во всех областях сразу. Это значит, что если вы зададите правильный (или неправильный) вопрос, то любой инженер может выглядеть глупо. После этого кандидаты получают предложения в том случае, если хотя бы одно собеседование затронуло зону прочных знаний (максимальный навык) и ни одно не затронуло области значительной слабости. Проблема в том, что это увеличивает уровень шума. Один и тот же инженер, проваливший одно интервью, потому что выглядел глупо после вопроса о сетевых технологиях, блестяще проходит остальные интервью, где эта тема не затрагивалась.

По-моему, лучше всего компаниям сконцентрироваться на максимальном навыке и не так сопротивляться найму сотрудников, которые плохо проявили себя в отдельных секциях собеседования. То есть искать сильные аргументы в пользу кандидата и не беспокоиться так сильно о технических областях, где он слаб. Здесь я не хочу быть однозначно категоричным. Конечно, есть технические обалсти, которые просто очень важны для компании. И ваше решение, что все сотрудники должны иметь определённый уровень знаний в этих областях, вполне имеет смысл. Но концентрация именно на максимальных навыках кандидата реально уменьшает шум на собеседовании.

Зачем вообще проводить собеседования?


Последний вопрос, который я хотел бы задать — зачем вообще проводить собеседования? Уверен, что многие читатели уже скрипели зубами, приговаривая: «Какой смысл так подробно обсуждать неэффективную систему? Просто используйте домашние задания! Или просто берите людей на испытательный срок!» В конце концов, некоторые очень успешные компании действительно применяют испытательный срок (где кандидат работает с командой в течение недели) или полностью заменяют личные собеседования домашними заданиями. Испытательный срок во многом имеет смысл. Провести неделю бок о бок с новым сотрудником (или смотреть, как команда с ним выполняет важный проект) почти всегда даёт лучшую оценку навыков кандидата, чем наблюдение в течение всего лишь одного часа, как он решает задачи. Однако есть две проблемы, которые не дают испытательному сроку заменить стандартные собеседования:

  1. Испытательный срок дорого обходится компании. Ни одна компания не может взять на неделю каждого, кто хочет трудоустроиться. Чтобы решить, кого взять на испытательный срок, придётся проводить собеседования.
  2. Испытательный срок (и крупные проекты для домашнего выполнения) дорого обходятся кандидату. Даже если работа оплачивается, не у всех есть время. Например, если инженер работает полный рабочий день и у него нет возможности взять отгул. И даже если есть возможность, многие не хотят его брать. Если у инженера уже есть работа, то он не так настроен принимать неопределённость испытательного срока. Мы хорошо видим это на примере кандидатов Triplebyte. Многие из самых лучших кандидатов (уже имеющих предложения от других фирм) просто не будут выполнять крупные проекты и не согласятся на испытательный срок.

Получается, что испытательный срок — отличный вариант для некоторых кандидатов. Думаю, если масштаб позволяет использовать разные пути собеседования, то добавить к ним испытательный срок — отличная мысль. Однако нецелесообразно полностью заменять им собеседования.

Обсуждения опыта работы над прошлыми проектами тоже часто рассматривают как замену техническим собеседованиям. Логика такая: чтобы убедиться, что кандидат успешно выполнит работу в будущем, просто посмотрим, что он делал в прошлом. Мы в Triplebyte пробовали такую методику. К сожалению, она не показала хороших результатов. Выяснилось, что коммуникативная способность (способность продавать себя) оказалась более сильным сигналом, чем технические способности кандидата. Просто слишком часто возникает ситуация, когда умеющий красиво говорить кандидат преувеличивает свою роль (присваивает результат всей команды) или когда скромный человек преуменьшает свои заслуги. При наличии достаточного времени и достаточном количестве вопросов можно докопаться до сути. Однако мы выяснили, что при стандартном ограничении по времени обсуждение прошлого опыта не является универсальной заменой собеседованию. Это хороший способ растопить лёд в начале разговора, понять смысл интересов человека (также оценить коммуникационные способности и культурное соответствие). Но обсуждение прошлого опыта не подходит в качестве полной замены собеседованию.

Кое-что хорошее о программистских собеседованиях!


Хочу закончить эту статью на более приятной ноте. Наряду со всеми недостатками собеседований, они всё-таки приносят большую пользу.

Собеседования — это прямая оценка способностей. У меня есть друзья, которые работают учителями. Они говорят, что интервью учителей — это, в основном, оценка коммуникативной способности (умения продавать себя) и резюме/рекомендации. Судя по всему, такая ситуация во многих, многих профессиях. Кремниевая долина — не идеальная меритократия. Но мы по крайней мере пытаемся напрямую измерить навыки, которые имеют значение, и придерживаемся идеи, что любой человек с такими навыками может стать хорошим профессионалом, независимо от его образования и опыта работы. Оценка резюме часто этому мешает. Но мы в Triplebyte сумели во многом преодолеть эту проблему и помогаем большому количеству людей с нестандартными резюме получить отличную работу в IT. Сомневаюсь, что компания вроде Triplebyte смогла бы работать, например, в юридической сфере. Там слишком сильно полагаются на резюме и рекомендации.

Программисты тоже предпочитают собеседования. Хотя это очень спорная тема (наверняка найдутся программисты с иной точкой зрения), но когда мы проводили эксперименты с альтернативными методами оценки кандидатов, большинство программистов по-прежнему выбирали стандартные собеседования. И мы обнаружили, что только небольшую часть программистов интересуют компании, которые предлагают испытательный срок или домашнее задание. Хорошо это или плохо, но судя по всему, собеседования для программистов никуда не денутся. Другие способы — это хорошее дополнение, но вряд ли они заменят интервью как основной способ оценки программистов. Если неправильно процитировать Черчилля: «Собеседование — самый худший способ оценить инженера, если не считать остальных способов, которые мы иногда пробуем».

Заключение


Собеседование — непростая штука. Человеческие существа безнадёжно сложны. В каком-то смысле попытка оценить возможности человека за 4 часа собеседований кажется дурацкой. Думаю, здесь важно сохранять скромность. Любой процесс собеседования обречён на частые неудачи. Люди просто слишком сложные.



[1] Конечно, здесь есть разные варианты. На противоположных конца спектра находятся компании, которые требуют единогласного положительного решения от каждого интервьюера, и компании, где HR-менеджер единолично принимает решение.

[2] Это цифры из внутренней статистики самих компаний об их собственных кандидатах. И они сильно отличаются в разных компаниях (например, доля уволенных, варьируется от 1% до 30%). У кандидатов Triplebyte цифры значительно лучше. К настоящему моменту наши кандидаты получают предложения о работе после 53% собеседований, а уровень уволенных составляет 2%.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 44
  • –1
    Какая скучная статья!
    • +10
      Да ну! Очень крутые советы. Собеседования в кое-каких крупных российских компаниях, например, прямо противоречат ряду пунктов, и, как следствие, репутация у них так себе.
      • 0
        По своему опыту могу сказать, что чем крупнее компания тем хуже будет собеседование. Не правило, но корреляция прослеживается.
        • 0
          «Это большая честь — работать в нашем банке!» (При завышенных требованиях и зарплате ниже рынка.)
    • +3
      В реальности за последние два года я собеседовал более 9000 инженеров
      – опечатка. В оригинальной статье речь о 900 собеседований. Сразу бросилось в глаза своей нереальностью.
      • 0
        Чёрт, спасибо большое!
        • 0
          То есть 900 собеседований за 2 года это реалистично?
          2 года это 365х2=730 дней, то есть примерно 1 собеседование в день, если человек в своей жизни вообще не имеет выходных.
          В реальности же в 2016 году (нагуглил) было 247 рабочих дней. То есть 900 собеседований за 494 дня, то есть почти по 2 собеседования каждый рабочий день.
          • +2

            Это ж рекрутинговое агентство или что-то подобное, собеседования — их основная работа.

            • 0
              Всё равно как-то нереально, на одного специалиста по 2 соискателя в день.
              Судя по ФБ — компания «Создана в Май 2015 г.», то есть это не может быть компания с 10к сотрудников, но даже если допустить что там 30 таких специалистов сидит, то это уже 60 инженеров/день.
        • +2

          Испытательный срок — крайне плохая идея, если в начале надо уволиться из текущей компании, продать дом, и переехать на другой континент.
          Я, например, стараюсь заворачивать кандидата при малейшем намеке на то, что он может не пройти.

          • 0
            не боитесь зашкаливающего % ложноотрицательных результатов?
            • +1
              А по факту он работает. ИС позволяет отсечь людей с несовпадением по ценностям. Это важнее, чем недостаток хард скиллов. К сожалению, выявлять ценности человека на собесе почти никто не умеет (есть много тех, кто думает, что умеет).
              • 0

                Испытательный срок 6 месяцев, который в Австралии прям на законодательном уровне, никто не отменял.

              • 0
                Но зачем же дом продавать?
                • 0
                  Бывает испытательный срок на нормальных условиях. Например, оклад один и тот же, но премии только после успешного прохождения.
                • 0
                  Исправьте заголовок!
                  Я надеялся прочитать хоть что-то интересное, новое и важное, а как только дочитал до:
                  Нет единого набора навыков, которые определяют хорошего программиста. Наоборот, существует целый океан разнообразных наборов навыков. Никакой инженер не может быть силён сразу во всех областях.

                  — сразу стало ТОЧНО понятно, что реально это 100500 по счёту статья, «Как собеседовать программистов».
                  Почему на всех технических ресурсах есть подобного рода статьи, и только про программистов? Только программисты везде работают? Или только они проходят собеседования? а остальные получается, прямо сразу на работу идут, мимо отдела кадров.
                  • +3
                    Вот и я думала, что статья про инженеров (а при собеседовании оных есть свои нюансы), а тут опять… =(
                    • +2
                      Об одинаковых вопросах для всех кандидатов не согласен в корне. Цель компании — не составить рейтинг (для этого есть спортивное программирование), а найти человека, который будет создавать ценность. И если будет небольшая погрешность, это не страшно.
                      А вот то, что одинаковые вопросы позволяют геймить систему, это важнее. Потом вопросы начинают передаваться из уст в уста. Я сам был в ситуации интервьювера со списком вопросов, когда пришел человек мгновенно отвечающий на вопросы, и я не мог понять, человек действительно крут, или просто его друг собеседовался ранее. Мне тогда помог именно десяток вопросов, которые я держал в голове, и задавал 2-3 из них в добавок к вопросам их списка.
                      PS некоторые компании вообще устраивают письменное групповое тестирование для джуниоров, и там выигрывают люди со свежим опытом списывания и хорошим зрением.
                      • 0

                        Все зависит от количества кандидатов. Если есть хотя бы три кандидата на место, а интервьюеров несколько — одинаковые вопросы позволяют проще прийти к общему решению о выборе конкретного кандидата.

                        • +1
                          Ситуация описанная в комментарии хорошо решится, если критерий крайне простой — каждый ответ вырождается в + или — в отчете. Такой критерий отлично зайдет при наборе формошлепов и знатоков конкретного набора фреймворков. А вот даже для набора перспективных трейни я бы так не делал.

                          При выборе человека, которому придется создавать что-то новое (таких принято называть инженерами), важнее ход мысли, а не конечный ответ. Сравнить ход мысли даже на одинаковых вопросах не так то просто.

                          PS: количество да, чем больше кандидатов, тем скорее пойдет народная молва о вопросах
                      • +1
                        Глубоко задумался после фрагмента статьи про «пугающий вопрос». Потом попытался быстро придумать решение задачи с гистограммой. Дальнейшая цепочка мыслей привела меня к мысли, что независимо от того, хорошо это или плохо, сильный программист сегодня — это тот, который умеет быстро находить (гуглить), обрабатывать и запоминать (хотя даже запоминать уже не так нужно) информацию. Конечно, вы скажете, что новичок без какого-либо опыта хуже справится с построением архитектуры хоть сколько-либо сложного приложения с нуля, и, наверное, будете правы. Но, во-первых, архитектурой занимаются архитекторы, это все же отдельная профессия, а во-вторых, значительная часть архитектур уже реализована и описана. Причем, взять готовое решение и немного подточить его для своих нужд выходит очевидно быстрее, вполне вероятно надежнее и скорее всего дешевле для бизнеса, чем велосипедить что-то свое. Я говорю о профессии в целом, конечно, есть и исследовательская работа и потребность в ультрапроизводительности в определенных областях, но субъективно мне кажется, что подавляющее большинство программистов сегодня в первую очередь лезут в интернет за документаций, примерами, обзорами и прочим по любой задаче, которую они решают. И в зависимости от умения искать и переваривать эту информацию они и разделяются на хороших программистов и плохих. Но это все мое личное мнение.
                        • 0
                          То, что пригодится в течение года и больше — учить серьезно. Случайные задачи\разовые интеграции решать гуглежкой\примерами\обзорами.
                          • 0
                            Всё таки опыт важен, решение более-менее сложной задачи (комплексной) вы вряд ли найдёте в интернете. Да, найдёте описание эффективных алгоритмов, библиотек и систем, решающих конкретные простые задачи… А вот когда надо совместить несколько алгоритмов, несколько специализированных систем, когда нужно отойти чуть в сторону от стандартов, вот тут и начинается веселуха, о которой ни чего не написано в инете и вот тут и будет заметна разница между опытным и неопытным программистом…
                          • +4

                            Читаю: Мы собеседуем инженеров, ничего не зная об их биографии, а затем смотрим, как они проявляют себя в разных крупнейших IT-компаниях. На мой взгляд, это самая лучшая проверка эффективности интервью.
                            То есть, на взгляд автора, лучший рекрутинг:


                            1. Не знать кандидата вообще
                            2. Отправить сразу в крупные компании с серьёзными проектами
                            3. Посмотреть, что получилось
                            4. ?????
                            5. Получить премию!
                            • 0
                              Между первым и вторым пунктом есть еще собеседование. Автор пытается сказать, что они не придают значения резюме, делая упор на интервью. В итоге фраза «смотрим, как они проявляют себя в разных крупнейших IT-компаниях» выглядит как получение фидбека и подтверждение/опровержение примененных техник на собеседовании.
                            • –3
                              Что бы собеседовать программистов, нужно думать как программист… думаю дальше не стоит продолжать… Статья о чем?
                              • –2
                                > Логика такая: чтобы убедиться, что кандидат успешно выполнит работу в будущем, просто посмотрим, что он делал в прошлом.

                                А почему нельзя просто описать как можно более подробно будущие задачи и спросить у человека, справится он или нет?
                                • +2
                                  Вот кстати да, на многих собеседованиях расспрашивают про ООП, паттерны, SVN и прочие крутые фичи, которые в их компании не используются, и мало кто рассказывает о планах на будущее. Было бы куда проще, если бы сразу спрашивали: «Чувак, нам надо говносайтики клепать один за другим, не заморачиваясь с качеством — ты справишься?»

                                  Честно говоря, когда мне приходилось собеседовать айтишников, я тоже спрашивал всякий бред. Потому что я не HR и когда меня отрывали от работы, мол: «Там мальчик пришел, пойди позадавай ему вопросы», я вопросы выдумывал по пути в переговорку и в не самом лучшем настроении. Мог бы упростить себе жизнь, если бы честно спрашивал: «Дружище, ты согласен чихать в пыльные тазики за те деньги, что ты просишь, без всякой надежды на карьерный рост?»
                                  • –1
                                    Хотелось бы, чтобы кто-то из поставивших минус все же ответил на вопрос (ведь вы ответ, видимо, знаете?). Потому что мне это действительно интересно — зачем люди тратят время на многочасовые собеседования, если можно просто спросить и получить заведомо более достоверный результат? Более достоверный, чем даже оценка по результатам испытательного срока в несколько месяцев. Здесь есть какие-то нетривиальные факторы, понятные только профессиональным HR'ам, или же это просто сложившийся исторически карго-культ?
                                      • –1
                                        Никто и не говорит о том, что человек оценит свои навыки абсолютно точно. Но это будет в среднем заведомо более точная оценка, чем оценка любого собеседующего. С любым количеством тестов и проверочных заданий. Кроме того, человек ведь не будет отвечать просто «да» или «нет», ответ всегда будет в виде: «вот с такими задачами я постоянно работал, так что справлюсь легко, с задачами вида Y работал, но немного, могут быть проблемы, а к решению Z у меня просто душа не лежит».
                                        • 0
                                          Почему вы исходите из того, что люди никогда не обманывают?
                                          • 0
                                            Люди обманывают, когда им это выгодно. Какая выгода в том, чтобы вылететь через месяц с волчьим билетом?
                                            В любом случае, если требуется знать, насколько человек порядочен, то вопросы по знанию тех или иных технологий тут нерелевантны.
                                            • 0

                                              Как какая выгода? Зарплата за месяц плюс компенсация за увольнение.

                                              • 0
                                                Человек ставит крест на своей карьере за месячную зарплату (окей, +компенсация). Не вижу здесь никакой выгоды. В любом случае, еще раз — если вы хотите отсеять непорядочных людей, то чем вам помогут технические вопросы?
                                                Если вышеприведенный вариант дополнить в виде: «убедиться в порядочности и спросить, справится или нет», то так нормально?
                                                Можно даже еще дополнить: «убедиться в порядочности, и в том, что человек не совсем уж полный дебил» (что и значительно снизит эффект Даннинга-Крюгера).
                                                • 0

                                                  Почему вы думаете что у него есть какая-то карьера? Если верить всем полностью на слово — то может пролезть случайный человек, который решил месяц побыть программистом, а потом вернуться в дворники. Затем и нужны технические вопросы, чтобы отделить тех у кого есть карьера от случайных прохожих.

                                                  • 0
                                                    > Затем и нужны технические вопросы, чтобы отделить тех у кого есть карьера от случайных прохожих.

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

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

                                                    Отсеивание таких людей не является задачей технического интервью в принципе. У вас, в конце концов, в резюме будет указано, что человек все жизнь работал дворником. Вы его, скорее всего, и на беседу не пригласите. А если пригласите — значит, вас, в принципе, дворник устраивает.
                                                    • 0

                                                      Тут как-то проскакивал переводной пост о "программисте", который учился в специальной летней школе проходить собеседования на программиста.


                                                      Вы уверены, что смогли бы распознать такого человека в обычной беседе?

                                                      • 0
                                                        > Вы уверены, что смогли бы распознать такого человека в обычной беседе?

                                                        Так вам и тесты не помогут его распознать. Смотрите, штука в том, что вы пытаетесь сравнивать два варианта узнать реальный уровень кандидата: либо спросить, либо протестировать/пособеседовать часиков эдак с десять. При этом первый вариант вроде как плох, потому что вдруг соврут, или еще там чего. Но проблема в том, что первый вариант — он на самом деле единственный, и если вам соврали — нету у вас никакого способа узнать, подходит вам кандидат или нет, кроме как с ним проработав хотя бы с месяц-другой. Все, что вы сможете понять в результате тестов — то, что человек не совсем идиот (или совсем), но это будет понятно и так, гораздо быстрее и без тестов.

                                                        Плюс к тому — здесь же мы говорим о статистических оценках, по-этому приводить крайние примеры смысла нет.
                                  • +1
                                    Задавая слишком сложные вопросы и оценивая исключительно техническую составляющую, есть риск подобрать сотрудника, который действительно может все и очень крутой профессионал, но при этом своенравный, нарциссичный, несговорчивый, самодур и далее по списку. В результате получим классного специалиста, обклеенного сертификатами со всех сторон, но выхлопа с него не получим. На любое ваше задание у него есть свое мнение, потому:
                                    1. Я не буду это делать — так делать нельзя! И так тоже.
                                    2. Так просто, как вы хотите, не получится — надо усложнить эту задачу, применив все существующие практики в области безопасности.
                                    3. Это не моя зона ответственности — я учился 10 лет не для того, чтобы заниматься непрофильным трудом.
                                    4. У меня нет времени заниматься этой ерундой, поручите ее кому-то другому.
                                    5. У меня нет времени объяснять, идите в жопу гугл.
                                    • –1
                                      Именно по этому в таких конторах как *ндэкс. *угль и тд. после того как узнаю что вас ждет 6...7… возможно 5 собесов после чего мы предложим вам офер возникает желание ответить вы #$#нулись??? идите в жопу постратить 8 часов времени на всякую мутотень =) С учетом того что офер будет с той же суммой что и в самой неизвестной конторе( а за частую и даже хуже).

                                      З.Ы. Если вы ищете кандидата в свою команду то и собес должен делать тимлид — сотрудник нужен ему а не HR, Директору и не тете Вале. А если Тимлид «очччень занят»" то гоните его в шею — он не справляется с работой =)
                                      • 0
                                        Мне на интервью важно понять может ли человек думать. С этим считаю типовые задачи не слишком помогают. А вот например задания на рефакторинг куска кода уже другое дело. Это менее стрессово для кандидатов, любой сможет хоть что-то да улушить в коде. Можно подобрать такой код что его будет строк 10-15 всего, но при этом он будет напичкан всякими проблемами, в том числе не слишком явными. И вот лучшие кандидаты не просто улучшают код, но пытаются догадаться каково назначение код (что он делает, часть какой системы является), и это ведет к еще более продуктивной беседе.
                                        • 0
                                          следующий степ — такой кусок высылать зарание и просить кодревью на почту.
                                          • 0
                                            Разумеется нет. Код подбирается выразительный и не объемный, то есть такой чтобы управится в час максимум при очной встрече или удаленном общении с код шарингом, но скорее пол часа максимум. Интересует ведь именно как человек рассуждает, а не как кто-то там где-то пишет ответы.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.