Как проводить технические собеседования?

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

Для чего мы проводим собеседование? Мы хотим найти кандидата, который бы подходил под наши требования «подходящего» разработчика. Но поскольку мы не можем взять человека и посадить его на три недели за решение наших текущих задач, мы придумываем некую модель, соответствие которой означает, что кандидат нам подходит.

При этом «модели» используются самые разные. В гугле когда-то считали, что человек, который сможет ответить на вопрос: сколько шариков для гольфа влезет в багажник Lexus LS470 является хорошим программистом и сможет успешно решать их задачи. Майкрософт когда-то использовал похожий подход (вспомните «Чтобы сделал мистер Фейнман» Эрика Липперта), а сейчас они садят кандидата за стол и просят его покодить. Очевидно, что эта модель также не совершенна, ведь она не соответствует реальному миру, ведь мы никогда не кодим на работе, когда от этого зависит наша судьба, а наш начальник при этом заглядывает в код через наше левое плечо.

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

ПРИМЕЧАНИЕ
Помимо отечественного аутсорса подобные тип собеседований активно используется и в некоторых компаниях в США. Например, в Нью Йорке большинство собеседований очень напоминают киевские;)

Кого мы хотим найти?

Прежде чем решить, как же нам подобрать правильных людей (и отсеять «неправильных») нужно определиться с тем, кого же мы ищем.

Проблема здесь в том, что к отечественному аутсорсу (который составляет существенную часть нашего рынка труда) не применимы те же самые критерии, что и к мировым гигантам, типа МС-а, Фейсбука или Гугла. Главное отличие между этими мирами в том, что аусорсу нужно не столько высочайшее качество, сколько большее количество при вменяемом качестве. И хотя требования к разработчикам в аутсорсе может быть и недотягивают до гугловских, тем не менее они достаточно высокие и наши программисты обычно превосходят в техническом плане многих представителей заказчика.

Так что планка в наши компании несколько ниже, ключевые критерии совпадают: нам нужно найти человека, который умеет думать, решать задачи и доводить дело до конца (кстати, именно умение довести дело до конца Бертран Мейер считает самой полезной чертой разработчика, о чем он поведал в своем недавнем интервью).

ПРИМЕЧАНИЕ
Я тут здорово все упростил, поскольку процесс отбора существенно сложнее. Как минимум нужно учитывать человеческие качества, ведь даже rock star разработчику стоит отказать, если из-за него развалится вся команда.

Техническое собеседование

На рынке существует множество способов определения таланта разработчика: начиная от задач на бредологику, типа квадратных и круглых люков, заканчивая решением олимпиадных задач на клочке бумаги.

Отечественный аутсорс при отборе уделяют максимальное внимание конкретным техническим навыкам: знаниям языков программирования, технологий и платформ. Можно сколько угодно спорить, насколько коррелируют знания языка C# с умением решать рабочие задачи и насколько этот подход лучше/хуже альтернативных вариантов. Как по мне, значительно важнее не то, какие вопросы вы задаете и какие знания проверяете, а то, как вы слушаете ответы и каким образом их анализируете.

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

Узнайте, как человек думает

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

Например, вполне нормальным попросить реализовать StringBuilder самостоятельно или спросить о том, как он реализован в .NET. При этом значительно интереснее обсуждать этот вопрос, когда кандидат не знает решения. Тут можно затронуть компромиссы между эффективностью реализации методов Append и ToString, подумать о выборе структуры данных и т.п..

СОВЕТ
Очень полезно обсуждать задачи, суть которых хорошо известна кандидату, но которые он не решал на практике. Это немного выведет кандидата из зоны комфорта и будет показывать не его способность запоминать факты, а его способность думать и принимать решения.

Никаких вопросов из "тестов"

Из первого совета вытекает второй совет о том, чего делать никогда не нужно. Не нужно задавать вопросы, ответы на которые легко гуглятся, и главное, нельзя трактовать ответы по принципу тестов: "ответил/не ответил", без продолжения обсуждения.

Меня всегда очень беспокоит, когда на собеседовании задается вопрос следующего вида: "Скажите, а какой тип возвращаемого значения должен быть у перегруженного оператора = в С++? Ссылка или константная ссылка?". Особенно печально, когда ответ на этот вопрос просто записывается на бумажке и интервьюер переходит к следующему подобному вопросу.

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

Сосредоточьтесь на фундаментальных вещах

Есть некоторые позиции, которые требуют очень глубокой экспертизы в определенной области. Бывает, что команде нужен эксперт по WCF, WPF или ASP.NET, который должен знать технологию очень глубоко и тогда на собеседовании придется гонять кандидата по всем дебрям. Во всех других случаях значительно полезнее сосредоточиться на фундаментальных вопросах, даже если они и привязаны к конкретной технологии.

Обычно под фундаментальными вещами я понимаю ключевые концепции: основы типов в .NET, основы сборки мусора и проблемы управления ресурсами; основы языка C# типа делегатов, событий, замыканий. Фундаментальные вещи из области проектирования, типа cohesion & coupling, проблемы наследования/агрегации, опасностей изменяемости и т.п; паттерны проектирования, отношение к ним и их роль в арсенале разработчика. Основы алгоритмов, можно в привязке к платформе ("Что будет если метод GetHashCode будет всегда возвращать 42?") и т.п.

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

Определите свой уровень по шкале от 1 до 10

Я уже несколько лет пользуюсь подходом, подсмотренным когда-то у Эрика Липперта и в качестве первого вопроса собеседования задаю следующий: "Определите, пожалуйста свой уровень знания языка C# по шкале от 1 до 10, где 1 – это уровень моей мамы, преподавателя математики, а 10 – уровень автора языка C# – Андерса Хейлсберга.".

Это довольно распространенный вопрос, но для меня он не самодостаточен (хотя бывает любопытно услышать от синьера, что его уровень ниже 6 или выше 8). После этого вопроса я всегда задаю второй: "Ок, ваш уровень 8, а какие именно знания перевели вас с уровня 7 на уровень 8?".

Польза такого подхода в том, что можно узнать следующее: (1) чем человек интересуется и интересуется ли чем-то вообще, и (2) можно пропустить ряд простых тем, если кандидат говорит о недавнем изучении каких-то продвинутых вещей. Так, если кандидат говорит, что он узнал о сегментах в GC и Card Table, о реализации обобщений, деревьях выражений, о проблемах изменяемых значимых типах или о генерации IL-кода, то вполне можно пропустить базовые вопросы, типа разницы между ссылочными и значимыми типами и углубиться в более серьезные подробности.

К тому же такой вопрос позволит оценить человеческие качества: насколько кандидат уверен в себе и насколько он адекватно оценивает свои знания, насколько сильно он отстаивает знания в тех областях, в которых он считает себя экспертом и т.п.

ПРИМЕЧАНИЕ
Не так давно на rsdn было обсуждение этого вопроса: "Как вы оцениваете ... по 10ти бальной шкале?", в котором я также принял участие.

Тяните за ниточку

Я очень редко провожу собеседование по бумажке. Обычно происходит следующее: берется несколько ключевых вопросов (таких себе "якорей"), на основе которых строится все обсуждение. Ответ на вопрос n зачастую дает почву для вопроса n+1, который в свою очередь дает почву для следующих вопросов.

Обычно даже невинный вопрос, типа, а зачем нужен интерфейс IDisposable приводик к обсуждению управляемых и неуправляемых ресурсов, Dispose-паттерна, откуда легко перейти к обсуждению стандартов кодирования (поскольку все эти вещи описаны в Framework Design Guideline).

Аналогично, невинный вопрос, типа "А атомарна ли операция i++, где i – это System.Int32?" может послужить хорошим началом разговора, поскольку наверняка даст почву к другим темам, таким как неизменяемость и многопоточность, проблеме гонок, вопросам об атомик операциях и многим другим.

Именно поэтому мне нравится сверх простая задача следующего вида:

class Foo
{
    public event EventHandler MyEvent;
    private readonly int _syncRoot = 42;
 
    public void RaiseMyEvent()
    {
        Monitor.Enter(_syncRoot);
        try
        {
            if (MyEvent != null)
                MyEvent(this, new EventArgs());
        }
        finally
        {
            Monitor.Exit(_syncRoot);
        }
    }
}

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

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

Насколько "технологическое" интервью эффективно?

Есть ли связь между знанием языка C# и умением решать производственные задачи? Тут все не так просто. Можно выделить две крайние ситуации.

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

Во-вторых, есть замечательные практики, которые не сильны в теории. Есть вероятность, что такой кандидат будет отсеян, но опытный интервьюер может постараться перейти из теоретической области в более практическую и определить таланты такого кандидата. Один из моих текущих коллег попадает именно под эту категорию, и на многие продвинутые вопросы во время интервью смело отвечал, что "этой ерунды он не знает". Но его открытость и практичность подкупила с самого начала, поэтому мы уже почти год работаем в одной команде.

В целом, разумный подход на основе технологических интервью показал вполне хорошие результаты. Полноценный синьер не обязан знать про Card Table, но сможет относительно легко ответить о пользе поколений в сборке мусора, и даже не зная о SOLID принципах мы наверняка сможем пообщаться на предмет cohesion и coupling, о роле тестов и паттернах проектирования.

Талантливый разработчик знает свою кухню, как минимум на продвинутом уровне, поэтому "технологический" критерий не хуже любого другого.

Интервью – это двусторонний процесс

Для любого специалиста собеседование является двусторонним процессом: интервьюер оценивает кандидата, а кандидат оценивает компанию посредством оценки интервьюера.

Именно поэтому меня вгоняют в ступор собеседования, на которых практически не проверяются технические знания кандидата или его аналитические способности. Меня пугает как минимум два момента: во-первых, вопросы и обсуждения показывают не только уровень кандидата, но и уровень собеседующего, с которым мне (как кандидату), возможно, придется работать. Во-вторых, слабый отсев кандидатов путем невнятных вопросов вызывает сомнения в среднем уровне команды, поскольку в этом случае в команду может попасть множество "случайных" людей.

Можно подумать, что это лишь мое личное наблюдение, и не каждый интервьюер готов спрашивать C# MVP о языке C# (хотя лично я не вижу в этом ни каких проблем). Но ведь такую же картину видят и многие мои коллеги, которые проходят собеседования на Senior или даже Middle позиции.

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

З.Ы. Если так уж случилось, что вы были на моих собеседованиях (Земля ведь квадратная;), будет интересно услышать ваше мнение о нем.

З.Ы.Ы. Понравился пост? Поделись с друзьями! Вам не сложно, а мне приятно;)