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

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

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

3.1 Дедуктивный метод

В детстве я был просто зачарован Шерлоком Холмсом в те моменты, когда он, базируясь на исцарапанных часах или пыли на пальто, выдавал про человека кучу очень детальной информацией да ещё с присказкой: «Это элементарно, Ватсон!» Причём все эти выводы объяснялись, и любой мог проверить их обоснованность.

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

Когда я выразил своё удивление, объяснил:

– Посмотри, сколько раз он разделял код на «мой» и «не мой». Про проблемы с «чужим» кодом он даже говорить не стал.

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

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

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

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

Так как же надо подходить к собеседованию, чтобы самому получать такую же чёткую картину характера кандидата?

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

Ответ был такой: «Ой, я совсем не конфликтный человек! Я с коллегами очень хорошо общаюсь! И за чаем всегда болтаем про всякие нерабочие вопросы, наши семьи, наш отдых. Это только конфликтные люди со всеми ругаются. К сожалению, есть и такие».

А что это за люди такие? Кандидатка уточнила: «Как-то так получается, что это выскочки, которых повысили за что-то. Лидом человека сделали или менеджером. Нормально общались, а тут, как подменили человека. Почему-то люди очень часто начинают задаваться, хотя ничего из себя не представляют. Сами не знают, чего хотят, а кричат. Я считаю, это звёздная болезнь, прямо эпидемия звёздной болезни».

А можно что-то с этим сделать, как-то избавиться от этих конфликтных ситуаций? Кандидатка и тут дала прямой ответ: «Да вряд ли. Людей не исправишь. Если уж они такие зазвездившиеся, то остаётся только терпеть. Возможно, более высокое руководство может их поставить на место. Но руководству всё равно, они такие же».

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

Почему? Потому что она сама признала, что есть много людей, с которыми у неё конфликты (лиды, менеджеры, причём, их так много, что «прямо эпидемия»). Это просто определение конфликтности. Если у человека много конфликтов, значит он конфликтный.

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

Кандидатка не готова сама разрешать конфликты. Единственный выход она видит в том, что кто-то более сильный, более высокий менеджер (которого она тоже не уважает), вступит в конфликт с её противниками и «поставит их на место».

Ругань и конфликты в её понимании являются вполне приемлемым инструментом. И конфликты это именно ругань (она так и поняла вопрос). Причём выбранный ею тон был очень пренебрежительным и эмоциональным. Она про эти конфликты не забывает даже на собеседовании.

Так что можно уверенно утверждать, что с кандидаткой будут проблемы, так как она склонна крайне эмоционально воспринимать рабочие моменты и будет генерировать конфликты.

Но как же так? Ведь можно найти другие объяснения этим ответам! Давайте, попробуем: «В компании специально отбирают весь руководящий состав, исходя из их способности кричать на других людей. При любом повышении в той компании требуют, чтобы повышенный начинал кричать на тех, с кем ранее общался хорошо. Кандидатка понимает, что это неприемлемо, но её там удерживали силой, и вот она вырвалась и устраивается на работу».

Абсолютно неправдоподобное объяснение, правда? Примерно соответствует ситуации, когда к Шерлоку Холмсу пришёл бы человек, нанёсший царапины на свои часы и осторожно присыпавший печной сажей рукав своего пальто.

Здесь нам помогает бритва Оккама (XIV век, проверенный инструмент), в соответствии с которой не стоит выдумывать запутанные и неправдоподобные объяснения при наличии простого и логичного. Если кандидатка несколько раз показывает признаки своей конфликтности, значит она конфликтная.

Что же нужно, чтобы применять этот метод?

Заранее определите, что вы хотите узнать.

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

Уточняйте.

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

Обдумывайте ответы кандидата быстро.

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

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

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

Развёрнутый эталонный ответ, который я как-то получил, звучал примерно так: «В большой команде всегда есть достаточно много конфликтов. Это конфликты интересов. Менеджер хочет, чтобы работа была сделана как можно более быстро, разработчик хочет, чтобы код был как можно более элегантен, тестировщик хочет, чтобы код работал так, как описано в документации, аналитик хочет, чтоб его не мучили вопросами и не просили менять требования. К счастью, все члены команды имеют одну цель, создание продукта, и это даёт базис, чтобы все эти конфликты разрешить. Нужно быть конструктивным и не давать перерастать конфликтам в словесную перепалку. Методология разработки говорит каждому, что нужно делать, а все конфликты можно разрешить просто поговорив или эскалировав проблему менеджеру».

Нет нужды что-то дальше спрашивать у такого кандидата. Можно переходить с ним к следующей теме.

Про печального Олега

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

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

Я был недоволен результатом интервью, так как мне не удалось понять, почему Олег вёл себя так странно. Открытого разговора с Олегом не получилось, и никакие разумные объяснения мне в голову не приходили. К счастью, даже в миллионном городе круги общения разработчиков очень тесно пересекаются. Через полгода меня пригласил директор и сказал, что ему удалось получить объяснение «загадке Олега».

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

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

Так что Олег пережил очень большое потрясение прямо перед нашим с ним интервью. Не удивительно, что собеседование потеряло для него всякую привлекательность. Удар по нервам был такой, что никакого дополнительного напряжения на интервью он не мог выдержать. К тому же желание быть поближе к Маше и работать в нашей компании у него плавно сменялось желанием быть от Маши подальше. Поэтому он даже решил переехать в другой город.

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

3.2 Анализ коннотаций

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

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

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

Это кажется очевидным, но на практике многие собеседующие совершенно игнорируют эмоциии в разговоре, упуская 90% того, что кандидат действительно им сообщает. Помните пример с конфликтной кандидаткой на странице 74? Очевидно ли вам, что та кандидатка говорила о коллегах довольно злобно и с явным негативом? Если нет, то давайте выпишем все слова с негативной эмоциональной окраской, которые она использовала (я выделил их жирным шрифтом). Обратите внимание, что чем дальше, тем больше негатива вскрывается:

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

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

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

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

Эти дополнительные, «эмоциональные» значения используемых человеком слов называются коннотациями, необходимо уметь их слышать, видеть и учитывать.

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

Если же вы не уверены в своих возможностях, то для тренировки делайте такой анализ письменно. Можете для тренировки взять какое-нибудь обсуждение на форуме, вроде «iOS против Android» и подчёркивать одной чертой все слова с положительными коннотациями и двумя с отрицательными. Уверен, что текст будет очень густо расчерчен.

Помните эти нудные школьные сочинения на тему «Что чувствовал Обломов к своему дивану?» Так вот навыки, полученные в то время, нужно развивать дальше. Это реально поможет вам в вашей карьере.

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

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

Причём даже если вы хорошо чувствуете эмоции, вам придётся постараться, чтобы вывести кандидата на открытый разговор. Если вы просто спросите кандидата: «Расскажите про проекты, на которых вы работали», то вы получите протокольное перечисление проектов и использованных технологий. Совсем другой результат будет, если вы спросите: «Расскажите про самый любимый ваш проект. Не важно, недавний или совсем старый. Просто проект, на котором вы бы с радостью поработали ещё раз».

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

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

Почему вы хотите сменить работу?

Что для вас интересный проект? Что для вас неинтересный проект? Какой ваш проект был самым интересным?

С какими людьми вам тяжело общаться?

Почему вам нравится программировать?

Вспомните самого лучшего вашего начальника. Почему он лучший?

Про агрессивного Алексея

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

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

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

– Что такое транзакции в базах данных? – спрашивал я Алексея.

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

– Алексей, но ведь это не ответ на вопрос. Это же не объясняет, что такое транзакции. Вы не знаете, что это такое? Может, просто дальше пойдём? Или, может, вы другими словами объясните?

– Я уже ответил на вопрос!

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

Довольно скоро я понял, что Алексей не может ответить «Не знаю». В принципе. Ни на какой вопрос. К моменту осознания этого факта я уже довольно хорошо понимал, в каких областях Алексей «плавает», поэтому для проверки своей гипотезы я задал несколько реально сложных вопросов из этих областей. Получил в ответ порцию откровенного бреда. Со стороны это смотрелось, наверное, сюрреалистически. Кандидат генерировал поток слов, щедро пересыпанных техническими терминами, но абсолютно не имеющих никакого смысла.

Такое нежелание признаться в собственном незнании мешает в работе. Решение любой проблемы начинается с определения, что мы про неё знаем, что мы про неё не знаем, и что мы должны сделать, чтобы знать больше. Нормально, если разработчик скажет, что не знает, почему лежит продуктовый сервер, и что ему надо часа два, чтобы разобраться. Но если вы не можете получить ответ «не знаю» от разработчика, то вы не сможете понять, что делать с проблемой.

Я решил разобраться, как Алексей работает на его текущей позиции, если он не может признаться в собственном незнании. И оказалось, что руководство компании Алексея не интересуется причинами любых проблем. Оно объявляет разработчиков виноватыми и кричит на них изо всех сил. Решение любых вопросов сводится к тому, чтобы о них не узнало руководство. Защититься можно, если так же сильно кричать в ответ. Что именно кричать – неважно, так как всё равно никто не хочет разобраться, а все хотят найти виноватых. Использование технических терминов помогает, так как руководство их не понимает. А признание в незнании чего угодно, вызывает обычные крики со стороны руководства, так как незнание – это какая-то проблема, и в ней, очевидно, виноваты разработчики.

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

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

3.3 Технические вопросы от менеджера

Очень часто кандидата отдельно собеседуют технический эксперт, который проверяет его технические знания, и менеджер, который исследует общий профиль кандидата, его soft skills, его мотивацию и так далее. И неоднократно я видел в менеджерах нежелание задавать технические вопросы. Зачем? Ведь эти знания уже проверил эксперт! Менеджеры не хотят тратить своё время. А иногда они боятся показаться незнающими или просто не уверены в своей возможности оценить технические ответы кандидата.

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

Менеджеры на практике задают такие вопросы, которые, хотя и являются техническими, но, обычно, не покрываются техническим интервью. Эти вопросы являются «промежуточными» между техническими и менеджерскими.

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

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

Этот вопрос покрывает совсем другую сторону работы разработчика. Даже если кандидат прекрасно умеет оптимизировать приложения, в реальной жизни задачи не приходят готовыми, «на блюдечке с голубой каёмочкой». Перевести задачу из практической, неформальной формы в форму, пригодную для решения – это часто тоже задача разработчика.

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

– Я попрошу организовать митинг с заказчиком, – ответил кандидат.

– Отлично. И что вы на этом митинге будете делать? – начало ответа мне понравилось. Когда информации нет, то это хорошая идея поговорить напрямую.

– Я попрошу заказчика показать проблему. Может быть её и нет.

– И дальше?

– Всё, на митинге делать нечего. Пойду анализировать код.

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

Гораздо спокойней я бы чувствовал себя с разработчиком, который:

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

– Просмотрел бы ешё разок, какие требования по производительности у нас были.

– Посмотрел бы , какие требования к оборудованию должны быть для нормальной работы приложения.

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

– Приготовил бы к митингу пункты, которые нужно проверить (конфигурация оборудования заказчика, загрузка сети, зугрузка сервера БД и т.д.).