Брать или не брать? или Как собеседовать разработчика

2.3 Задачки на собеседовании: FizzBuzz

При собеседовании специалиста вам нужно посмотреть, как он реально работает. Для тестировщика нужно дать ему что-то протестировать. Для мендежера – решить какую-то управленческую задачу. Для разработчика – дать ему написать код.

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

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

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

Вы знаете, какие именно разработчики вам нужны. Поэтому вам нужно попросить кандидата написать что-то прямо на интервью. Это должна быть совсем небольшая задача. Реализовывать её лучше на бумажке, так как на бумажке это будет быстрее, и кандидат не будет отвлекаться.

Классическая задача, которую я использую – это FizzBuzz. Она формулируется следующим образом:

Напишите программу, которая выводит на экран числа от 1 до 100. При этом вместо чисел, кратных трем, программа должна выводить слово «Fizz», а вместо чисел, кратных пяти – слово «Buzz». Если число кратно и 3, и 5, то программа должна выводить слово «FizzBuzz». Это программная реализация детской игры, в которой игроки должны по очереди называть числа или слова «Fizz», «Buzz» и «FizzBuzz» по тем же правилам.

Решение этой задачи простое и кандидат может написать его за минуту или две. В интернете есть куча обсуждений на эту тему и много разнообразных решений на разных языках. Вот пример такого решения на C#:

for(int i=1;  i<=100; i++)

{

  string output = "";

  if (i % 3 == 0)         output += "Fizz";

  if (i % 5 == 0)         output += "Buzz";

  if (output.Length == 0) output = i.ToString();

  Console.WriteLine(output);

}

Я смотрю, как кандидат подходит к решению этой задачи. Вот он написал в сторонке начало выходной последовательности, потом каким-то псевдокодом набросал решение, прокрутил вручную несколько итераций, отмечая ручкой текущую операцию, внёс пару исправлений, перепроверил и переписал всё на нормальном языке программирования. Потом пара вопросов от меня («А не сложно ли будет в вашем коде заменить 5 на 7?»), и мы можем идти дальше.

В интернете многие пишут, что эта задача просто раскрыла им глаза, что 90% соискателей в принципе не могут написать рабочий код или тратят на него больше 15 минут. На моей практике результаты не настолько печальные. Действительно, многие разработчики впадают в лёгкий ступор и тратят неразумное время на решение этой задачи даже с моими подсказками. Но таких мне встречалось не более 20%. Возможно, отбор рекрутёров в моих компаниях был лучше, чем в среднем по отрасли.

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

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

Есть очень много возмущённых отзывов на тему, что человек не может называться программистом, если он не может написать FizzBuzz. Я более спокойно отношусь к этому. Да, любой выпускник профильного ВУЗа должен уметь решить эту задачку. Да, решение этой задачи включает только очень базовые навыки программирования, и печально, что не все с ней справляются. Но надо признать, что есть много компаний, где от разработчика не требуется реализации хоть сколько-нибудь сложных алгоритмов.

Люди работают и получают хорошие деньги, не умея писать программы. Встречаются очевидные и очень печальные пробелы в знаниях в казалось бы базовых областях (теория сложности, структуры данных, SQL, логика), но это не ставит крест на кандидатах навсегда. Когда у них будет достаточная мотивация, они подтянут знания в этих областях.

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

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

А иногда кандидат пишет код, но не может найти в нём ошибку, если я говорю, что она есть. То есть кандидат не может отлаживать код в голове, он не может его полноценно читать. И это уже проблема, которая будет проявляться в его работе.

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

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

     x

    xxx

   xxxxx

  xxxxxxx

 xxxxxxxxx

xxxxxxxxxxx

2.4 Задачки на собеседовании: Цикл в списке

Эта задача гораздо сложнее, чем FizzBuzz, которая может считаться разминочной. Я сам когда-то получил эту задачу на собеседовании и срочно включил её в свой арсенал. Задача формулируется так:

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

Задача нарочито формулируется без всяких ненужных уточнений. Такая формулировка достаточна для понимания. А если кандидат, например, не знает, что такое «цикл» или «односвязный список», то он просто может задать вопрос.

Ситуация, с которым должен работать требуемый метод может быть иллюстрирована вот таким хороводом символов Марса:

 Рис. 2.2: Односвязный список с циклом

Сушествует два типа решений этой задачи:

Через два указателя.

Помещаем два указателя в начало списка. На каждой итерации двигаем первый указатель на 1 шаг вперёд, а второй – на 2. Если второй указатель «догоняет» первый, значит, цикл есть.

Через запоминание пройденных узлов.

На каждой итерации запоминаем текущий элемент, проверяем, не запоминали ли мы уже следующий элемент, и сдвигаем текущий элемент на следующую позицию.

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

Оба решения требуют очень аккуратного кода, чтобы избежать Null Reference Exception.

К обоим решениям стандартный дополнительный вопрос: посчитать вычислительную сложность получившегося алгоритма. Здесь традиционно возникает вопрос алгоритмической сложности поиска в хэш-таблице (любимой структуре хранения данных кандидатов) и традиционный ответ, что это O(1). В Википедии, например, указано более правильно, что O(1) достижимо только «в среднем», а так-то может быть до O(n).

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

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

Реализовать какую-то структуру классов;

Очень аккуратно работать с указателями;

Принимать во внимание граничные случаи (пустой список, список без цикла);

Объяснить решение (без чертежа это сложновато).

2.5 Проверка тестовых заданий

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

Например, задаёт ли кандидат вопросы? Хорошо, когда кандидат не имеет никаких вопросов и сразу выдаёт приемлемый результат. Ещё лучше, когда он быстро обдумывает задание и предлагает пару уточнений. И совсем другое, когда кандидат молча замирает на пару минут, а когда вы спрашиваете его, как дела, оказывается, что у него есть какой-то вопрос, который он стесняется задать. Можете не сомневаться, что в реальной работе вас ждут те же проблемы, помноженные на сложность проектных задач.

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

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

Также важно, использует ли кандидат рисунки, чтобы объяснить ход своих мыслей. Вам стоит побыть непонятливым, чтобы увидеть, насколько кандидат может быть понятным. Вспомните, сколько раз вы видели ситуацию, когда заказчик не мог понять техническую проблему, объясняемую разработчиком. Разработчики в таких ситуациях обвиняют заказчиков, считая их упёртыми и глупыми, но обычно проблема в объяснениях.

Лучше прямо попросить кандидата объяснить что-нибудь детально. Например, он говорит, что вычислительная сложность алгоритма O(n). А может ли он это показать? Можно так и спросить: «А вы могли бы это как-то объяснить так, чтобы объяснение можно было показать заказчику, и тот бы понял?» Навык просто объяснять сложные вещи очень полезен.

И, конечно, любые проблемы, которые вы видите у кандидата, не должны восприниматься как нечто окончательное и непреодолимое. Например, кандидат «завис» при решении задачи. Понятно, что это плохо. Но что именно плохо? Он боится задавать вопросы? Или он пасует при возникновении любых проблем?

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

Про красавицу Марину

Как-то надо было мне нанять в свой проект тестировщика. Искал я его уже довольно давно и безуспешно. Рынок пустой, свободных кандидатов нет. И менеджер соседнего проекта, Таня, тоже была в поисках тестировщика. Мы уже отчаялись найти готового специалиста и готовы были брать junior’а, если кандидат хороший.

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

Я смирился, что первый хороший кандидат уйдёт Тане. Но зато, успокаивал я себя, Владимир получит с ней хороший опыт собеседований. А собеседовать junior’ов особенно тяжело. Я специально говорил Владимиру: «Не уделяй сильно много внимания опыту. Гляди, чтобы глаза у кандидата горели. Ищи такого кандидата, на обучение которого тебе не жалко будет тратить своё время».

И вот на горизонте появилась кандидат, Марина. Она не имела опыта тестирования, но по словам рекрутёров, была очень мотивирована и рвалась самообучаться и работать. Так что интервью было назначено, и Владимир с Таней ушли собеседовать Марину. После собеседования Владимир зашёл ко мне в очень радостном настроении и сказал, что Марину нужно брать. Она прекрасно впишется в команду. Он готов её учить всему. Она тоже готова учиться. В общем, лучший junior на планете.

Я обрадовался и отписался рекрутёрам, чтобы они назначали интервью со мной на ближайшее время. Хотя радость моя сдерживалась уверенностью, что Таня сейчас отпишется, что она нанимает Марину сама. Но время шло, а Таня не отписывалась. Это было странно. После слов Владимира я ожидал, что Таня такую кандидатку утянет в свой проект.

Так что я пошёл к Тане и спросил, что там с Мариной, и почему кандидатка, которая так понравилась Володе, до сих пор не нанята.

– Ты бы лида своего женил. – сказала мне Таня, – Марина с ним флиртовала, а Владимир совсем ум потерял от её красоты. Нанимать я её не буду, так как кроме внешности она никаких плюсов не имеет. Так что если вам нужна такая Марина – берите.

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

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

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

2.6 Технический проект

Во многих компаниях обязательной частью приёма на работу программиста является выполнение большого технического проекта. Такой проект похож на реальные проекты компании и включает бизнес-логику, UI, backend, и часто состоит из нескольких отдельных модулей.

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

Когда проект требует выделения всего лишь одного дня (4-6 часов) реакция кандидатов, в основном, положительная. Люди готовы потратить столько, если они действительно заинтересованы вакансией.

Кроме потери кандидатов, включение такого этапа в процесс затягивает найм[4]. Даже если проект требует всего лишь 4 часов работы, то, скорее всего, кандидат сможет выделить это время только на выходных. А значит, вам придётся просто ждать.

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

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

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

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

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

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

Другая ситуация, где технический проект полезен – это найм junior-разработчика. Если разработчик никогда не писал коммерческий код, то имеет смысл дать ему попробовать свои силы. Для него это будет не нудная часть приёма на работу, а полезное упражнение. Но в любом случае проект не должен требовать больше 6 часов работы. Такой объём уже достаточен для «серьёзного» кода, но не вымотает кандидата.

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

2.7 Проверка знания английского

Во многих международных компаниях знание английского необходимо и это знание проверяется при приёме на работу в обязательном порядке. И также в обязательном порядке делаются одни и те же две ошибки.

Первая ошибка.

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

Часто такому кандидату после некоторых сомнений молча высылается офер. Ведь английский реально легко подучить. А кандидаты обычно говорят, что они усердно учат английский и, конечно, хотят подтянуть его уровень[5].

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

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

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

Вторая ошибка.

Часто вся тема английского языка отдаётся на откуп преподавателям, к которым, совершенно заслуженно, в IT большое уважение. И они определяют, например, что рядовые сотрудники должны иметь уровень Basic, старшие – Intermediate, а остальные – Advanced[6].

Для этих уровней составляются тесты (или берутся готовые), и все сотрудники, новые и имеющиеся, эти тесты проходят.

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

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

Или вот другая тоже распространённая ситуация. Специалист может общаться с заказчиком на упрощённом и ломаном языке. Он не употребляет Third Conditional и Past Perfect. Он игнорирует дифтонги и межзубные θ и №. Но заказчик может прекрасно его понимать.

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

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

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