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

Мы в компании 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 часа собеседований кажется дурацкой. Думаю, здесь важно сохранять скромность. Любой процесс собеседования обречён на частые неудачи. Люди просто слишком сложные.

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

Автор: m1rko

Источник