Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
Побег из курятника
Из компании, которая описана в истории «Про агрессивного Алексея » потянулась целая череда разработчиков. Зная, как там организуется работа, я этому не удивлялся. Собеседования я проводил совместно с лидом соседнего проекта, Евгением, с которым мы уже долго вместе работали и с которым процесс совместных собеседований был отлажен.
Первым пришёл совсем слабый junior-разработчик. Он выслушивал наши вопросы, улыбался, пытался что-то ответить, но получалось у него так себе. Практические задания он совсем не сделал. Хотя парень был активным. Он задавал много вопросов по тем темам, которые были ему наиболее непонятны, и расстались мы с надеждой, что через пару лет сможем поработать вместе.
Второй разработчик был уже сильней. На некоторые вопросы отвечал бодро. Техническое задание, с которым не справился junior, выполнил хорошо. На более сложном задании, правда, уже совсем ничего сделать не смог. Но тоже был активным, и мы хорошо поговорили.
Третий разработчик практические задания выполнил отлично. С теорией было похуже. Он хорошо отвечал на основные вопросы, но когда я начинал копать глубже, то выяснял, что понимания ему не хватает. Как-то царапнуло меня такое несоответствие знания теории и практики. Но Евгений первым догадался, что происходит. «Ты знаешь, Константин, – сказал он мне, – А ведь эти кандидаты сливают своим товарищам все наши вопросы и задачи».
Я немного подумал, и правота Евгения стала для меня очевидной. С теоретическими вопросами это не было проблемой, так как мы проверяли понимание, а не знание каких-то формулировок. Так что единственное, что нам нужно было поменять в процессе, чтоб не выслушивать заученные ответы – это сразу начинать со сложных вопросов, ответы на которые посмотреть нигде нельзя.
А вот с практическими задачами было гораздо сложнее. В моём арсенале было буквально две любымые задачки, и кандидаты уже наверняка их совместно прорешали дома. Когда кандидат, не задумываясь, пишет заранее подготовленное решение, это не даёт возможности понять ход его мыслей. Поэтому нужно было придумать что-то новенькое. Причём придумать надо было быстро, так как четвёртый кандидат был назначен буквально через полчаса после третьего. В результате пока Евгений гонял четвёртого кандидата по теории, я в быстром темпе сочинял практические задания.
С тех пор я имел запас практических задач на случай, если кандидат придёт с «домашней заготовкой». Ну и обращал внимание на то, были ли недавно кандидаты из той же компании.
3.4 Вопросы на собеседовании: Изучение нового
Очень часто в работе нужно изучать абсолютно новую область. Тестировщики изучают автоматизацию и тест дизайн. Разработчики изучают новые технологии. Аналитики изучают новые инструменты и языки описания систем. Все изучают новые методологии разработки. Очень важно знать, может ли кандидат взять новую для себя область и стать в ней экспертом в короткие сроки.
Как всегда, лучшим способом определить, может ли кандидат быстро учиться, будет просто задать прямой вопрос кандидату: «Предположим вам нужно выучить совершенно новую область для вас (библиотеку распознавания образов, например). Как вы подойдёте к этому?»
Хороший ответ, который я получаю на такой вопрос, звучит примерно так:
«Я попробую найти коллегу, который знает эту область, и спрошу его, как лучше всего её изучать и на что стоит обратить внимание. Если такого коллеги нет, то я могу найти специалиста в интернете. Например, задать вопрос какому-нибудь эксперту на форуме.
Обычно стоит начать изучение с каких-нибудь tutorials, чтобы реализовать что-то реально работающее. В процессе обязательно возникнут какие-то вопросы и проблемы. Их решение можно найти в Google или с помощью знакомых экспертов. Когда уже будут какие-то навыки, лучше начать писать реальный проект. Реализация будет неоптимальной и, наверняка, придётся много переписывать, но зато выучишь именно то, что тебе надо, и будет виден прогресс.
Чтобы глубоко изучить эту нужную область, можно найти какую-нибудь обстоятельную книгу. А ещё сейчас много обучающих сайтов, вроде Coursera, где можно найти нужный курс».
В таком ответе мне нравится сразу несколько моментов:
Кандидат не надеется только на себя, а сразу хочет найти кого-то, с кем можно посоветоваться. Видно, что человек готов работать в команде. В новой области он не сможет сразу стать экспертом, но, пользуясь «коллективным разумом», он сможет принимать разумные решения.
Перечислено много разных подходов. Какой-то один может не подойти, но что-нибудь да сработает.
Ориентация на практику. При таком обучении, есть надежда, что проект начнёт получать какую-то пользу в минимальные сроки. Причём итеративный подход к обучению мне тоже нравится. Кандидат готов ошибаться, учиться на своих ошибках и двигаться вперёд постепенно.
Для примера могу привести ответ, который я слышал от одного из кандидатов и который я считаю проблемным:
Лучший способ что-то выучить – это книга. Я возьму хорошую книгу и прочитаю её от корки до корки. Только в этом случае можно быть уверенным, что я действительно имею хорошую базу. Я так выучил всё, что знаю. Например, чтобы выучить C++ я взял классический труд Страуструпа и долго читал его, чтобы узнать все детали языка.
В каких-то областях так можно учиться, но в моей практике обычно приходится изучать что-то, для чего просто нет хорошей литературы[7]. Да и читать серьёзную книгу часами тяжело и неэффективно. Можно потратить много недель, а потом выяснить, что на практике применить полученные теоретические знания не так-то и просто. Поэтому с таким кандидатом я не могу рассчитывать на быстрое изучение нового. Я могу только надеяться на те знания, которые он уже имеет.
Очень хорошо кандидата спрашивать о изучении тех областей, в которых у него проблемы. Например, у кандидата проблемы с английским языком. Но он говорит, что готов быстро закрыть все пробелы. Пусть он достаточно хорошо знает грамматику, но испытывает трудности с говорением, а ему нужно задавать вопросы и получать ответы на английском. Этот навык действительно легко развить, но справится ли конкретный кандидат с этим? В такой ситуации я спрашиваю напрямую, как он планирует это сделать.
Однажды я получил такой ответ:
Я готов вкладываться в своё обучение. Я пойду на платные курсы английского языка. Сейчас много таких. Оплачу курс и стану учиться вечерами.
Такой ответ для меня неубедителен. Желание платить свои деньги и тратить своё личное время, чтобы чему-то научиться, очень похвально. Но позиция кандидата очень пассивная. Он ожидает, что кто-то его научит, но сам он учиться, похоже, не умеет. Мы с ним обсудили очень конкретную проблему, и решение для этой проблемы должно быть очень конкретное. Следующий ответ был бы гораздо лучше:
Я пойду в несколько местных обучающих центров и посоветуюсь, как мне лучше подтянуть английский. Но чтобы улучшить говорение, надо его практиковать. Так что я постараюсь найти кого-нибудь с кем можно говорить по-английски. Есть специальные сайты, где можно найти собеседника из других стран. У меня есть знакомые с хорошим английским, попробую попрактиковаться с ними. Кроме того, мне надо улучшить восприятие английской речи на слух. Например, слушать сериалы на английском языке. Если буду заниматься по часу-два каждый день, то через пару недель эффект уже будет значительный.
В таком ответе есть и активная позиция, и несколько вариантов решения проблемы. Если даже ни один из этих вариантов не подойдёт, то можно быть уверенным, что такой кандидат придумает ещё что-нибудь.
3.5 Вопросы на собеседовании: Сложная задача
Один из обязательных вопросов на моём собеседовании звучит так: «Представьте, что вы работаете над какой-то задачей и она оказалась очень трудной. Вы не знаете, как двигаться дальше и не уверены, что вообще её решите. Что вы будете делать?»
Этот вопрос не настолько прост, как кажется, так как покрывает сразу несколько областей: технический кругозор, стрессоустойчивость, умение работать в команде. Задача поставлена очень общо, конкретные действия, конечно, зависят от деталей проблемы. Поэтому самое главное, что ожидается от кандидата – это большой список возможных действий, чем больше, тем лучше:
Погуглить возможные решения;
Попросить помощи у коллег;
Задать вопрос на специализированном форуме;
Если проблема связана с какой-то коммерческой библиотекой, то обратиться в службу поддержки этой библиотеки;
Сообщить своему менеджеру и попросить у него помощи;
Если возможно, то вообще не делать эту задачу (изменить требования);
Переключиться на другую задачу. Возможно, решение придёт, когда над ним не работаешь;
Закопаться в код поглубже, нерешаемых задач нет.
Длина такого списка возможных действий определяет способность кандидата работать над такими «нерешаемыми» задачами. Эти задачи не решаются в лоб, поэтому чем больше вариантов может придумать кандидат, тем больше вероятность, что один из них сработает.
Особенно хорошо, когда в этом списке есть неочевидные решения (вроде варианта не решать эту задачу). Просто прекрасно, когда кандидат учитывает нетривиальные проблемы, связанные с этими вариантами. Например, просить помощи на форуме можно, только если проблемный код не содержит значимой интеллектуальной собственности (чтобы можно было его разместить в общем доступе).
Но кроме того интересно, есть ли у кандидата в ответе варианты попросить у кого-то помощи (у менеджера, у коллег, у экспертов в интернете). Если этого нет, то у кандидата проблемы с коммуникацией.
Отдельно интересно, упомянет ли кандидат, что о проблеме нужно сообщить менеджеру или лиду. Если кандидат работал в команде с нормальными процессами, то он проблему обязательно озвучит, чтобы вся команда знала о ней. Если нет, то вы можете получить в команду человека, который периодически «закапывается» в какую-то задачу и никто не знает, что вообще есть какая-то проблема в проекте. Такое поведение очень распространено и очень разрушительно, поэтому обратите внимание, готов ли кандидат рассказать другим, что у него есть трудности, с которыми он не может справиться.
Один раз у меня было очень показательное обсуждение с кандидатом. Вместо списка возможных решений, он возмущённо сказал, что очень странно спрашивать про сложные задачи, так как единственное, что тут можно сделать, это нырнуть в код поглубже и работать над задачей, пока она не будет решена.
Я не видел смысла продолжать обсуждение, так как вопрос вызвал у кандидата негатив, поэтому просто пошёл дальше. Но это кандидата тоже не устроило и у нас состоялся следующий диалог:
– Постойте. А какой ответ вы ожидали на этот вопрос?
– Я не ожидаю какого-то определённого ответа. Здесь именно важно, узнать, что вы думаете. Например, многие говорят, что они первым делом попробуют нагуглить решение.
– Но ведь это очевидное решение! Конечно, я тоже попробую погуглить! Неужели вы думаете, что я не умею пользоваться Гуглом?
– Уверен, что умеете. Но это вопрос не на ваши навыки, а на образ ваших мыслей. Например, после вашего ответа я знаю, что вы не считаете нужным проговаривать очевидные вещи.
– Конечно! Они же очевидные!
Я думаю, что кандидат так и считал меня и мои вопросы глуповатыми. Но зато этот вопрос вскрыл очевидную проблему кандидата с общением. Он не указал, что можно посоветоваться с кем-то насчёт возникшей проблемы. Кроме того, он считает вещи, очевидные для него, очевидными для других. И он возмущённо отреагировал на абсолютно нейтральный мой вопрос и столь же нейтральное обсуждение. Не имеет даже смысла оценивать способность такого кандидата решать сложные задачи. С такими проблемами в коммуникациях в большинстве проектов до сложных задач он не дойдёт.
