Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
Люди работают и получают хорошие деньги, не умея писать программы. Встречаются очевидные и очень печальные пробелы в знаниях в казалось бы базовых областях (теория сложности, структуры данных, 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 на планете.
Я обрадовался и отписался рекрутёрам, чтобы они назначали интервью со мной на ближайшее время. Хотя радость моя сдерживалась уверенностью, что Таня сейчас отпишется, что она нанимает Марину сама. Но время шло, а Таня не отписывалась. Это было странно. После слов Владимира я ожидал, что Таня такую кандидатку утянет в свой проект.
Так что я пошёл к Тане и спросил, что там с Мариной, и почему кандидатка, которая так понравилась Володе, до сих пор не нанята.
– Ты бы лида своего женил. – сказала мне Таня, – Марина с ним флиртовала, а Владимир совсем ум потерял от её красоты. Нанимать я её не буду, так как кроме внешности она никаких плюсов не имеет. Так что если вам нужна такая Марина – берите.
Я Таню поблагодарил и пошёл собеседовать Марину сам. Она оказалась правда очень красивой девушкой, уверенной в себе и действительно склонной к флирту. А вот особой склонности к тестированию она не проявила. Пробившись через её улыбки и уклончивые ответы, я выяснил, что ей нужно просто иметь хорошую запись в трудовой книжке, а работать в этой компании сколько-нибудь долгое время она не планирует. Так что финальное моё мнение было ближе к таниному, чем ко мнению Владимира, и нанимать Марину я не стал.
Так я ещё раз удостоверился, что интервью могут быть действительно сложными для собеседующего. И что коварные кандидаты не чураются наносить удары ниже пояса.
А перед собеседованиями лучше вступить в брак.
