Константин Евгеньевич Борисов
Брать или не брать? или Как собеседовать разработчика
Про агрессивного Алексея
Пришёл ко мне как-то на собеседование разработчик Алексей. Он работал в одной из соседних компаний на должности лида разработки. То есть у него хватало и опыта, и технических знаний, и понимания процессов. Алексей был довольно активным, отвечал чётко и быстро.
Но через некоторое время я заметил странности в его ответах. На некоторые вопросы он очень бодро докладывал мне абсолютный бред. То есть было очевидно, что знаний у него по заданному вопросу нет, а текст, который он выдавал, больше походил на случайный набор терминов. Бывает иногда, что человек путает индекс в базе данных и индекс в массиве и отвечает не то. В таких ситуациях я обычно просто иду дальше. Но здесь уж очень много таких ответов было.
И когда в следующий раз я получил от Алексея непонятный ответ, я начал копать глубже. Я объяснил свой вопрос заново более чётко и сказал, что я не понимаю, как ответ Алексея относится к этому вопросу. И результат был неожиданным. Алексей покраснел, его кулаки сжались, он ажно привстал со своего места и очень агрессивно и громко стал повторять свой ответ. Я не понимал, что происходит.
– Что такое транзакции в базах данных? – спрашивал я Алексея.
– Транзакциями называются специальные объекты в базах данных, для работы с которыми используются особые классы, – отвечал он.
– Алексей, но ведь это не ответ на вопрос. Это же не объясняет, что такое транзакции. Вы не знаете, что это такое? Может, просто дальше пойдём? Или, может, вы другими словами объясните?
– Я уже ответил на вопрос!
Любая моя попытка уточнить ответ или объяснить Алексею, почему его ответ меня не устраивает, вызывали приступ гнева с его стороны. Я был максимально корректен, но это не помогало. Некоторые вопросы вызывали неадекватные ответы, а попытки разобраться в этих ответах вызывали гнев.
Довольно скоро я понял, что Алексей не может ответить «Не знаю». В принципе. Ни на какой вопрос. К моменту осознания этого факта я уже довольно хорошо понимал, в каких областях Алексей «плавает», поэтому для проверки своей гипотезы я задал несколько реально сложных вопросов из этих областей. Получил в ответ порцию откровенного бреда. Со стороны это смотрелось, наверное, сюрреалистически. Кандидат генерировал поток слов, щедро пересыпанных техническими терминами, но абсолютно не имеющих никакого смысла.
Такое нежелание признаться в собственном незнании мешает в работе. Решение любой проблемы начинается с определения, что мы про неё знаем, что мы про неё не знаем, и что мы должны сделать, чтобы знать больше. Нормально, если разработчик скажет, что не знает, почему лежит продуктовый сервер, и что ему надо часа два, чтобы разобраться. Но если вы не можете получить ответ «не знаю» от разработчика, то вы не сможете понять, что делать с проблемой.
Я решил разобраться, как Алексей работает на его текущей позиции, если он не может признаться в собственном незнании. И оказалось, что руководство компании Алексея не интересуется причинами любых проблем. Оно объявляет разработчиков виноватыми и кричит на них изо всех сил. Решение любых вопросов сводится к тому, чтобы о них не узнало руководство. Защититься можно, если так же сильно кричать в ответ. Что именно кричать – неважно, так как всё равно никто не хочет разобраться, а все хотят найти виноватых. Использование технических терминов помогает, так как руководство их не понимает. А признание в незнании чего угодно, вызывает обычные крики со стороны руководства, так как незнание – это какая-то проблема, и в ней, очевидно, виноваты разработчики.
Алексей в этой компании проработал много лет, поэтому он привык к такому образу действий и выработал защитные механизмы, позволяющие ему существовать с максимально возможным в таких условиях комфортом. Меняться Алексей не хотел, так как проблемы не видел. С его точки зрения он действовал эффективно. В то, что бывают другие руководители и другие способы решения проблем он не верил. Хмыкнул, сказал, что руководитель, который хочет решить проблему, а не найти виноватого – это пропаганда какая-то. Такое в книжках пишут, а в жизни так не бывает.
Это собеседование заставило меня очень сильно задуматься о том, как сильно меняется человек в зависимости от условий работы. И о том, как важно найти для себя компанию, где не только будет хорошая зарплата и интересные проекты, но и где твоя психика будет развиваться в нужном тебе направлении.
3.3 Технические вопросы от менеджера
Очень часто кандидата отдельно собеседуют технический эксперт, который проверяет его технические знания, и менеджер, который исследует общий профиль кандидата, его soft skills, его мотивацию и так далее. И неоднократно я видел в менеджерах нежелание задавать технические вопросы. Зачем? Ведь эти знания уже проверил эксперт! Менеджеры не хотят тратить своё время. А иногда они боятся показаться незнающими или просто не уверены в своей возможности оценить технические ответы кандидата.
Я настойчиво рекомендую менеджерам задавать технические вопросы (равно, как и техническим экспертам задавать вопросы «менеджерские»). Дело в том, что в реальных проектах менеджерам часто приходится глубоко влезать в технические детали. Им нужно понимать, что происходит в разработке и понимать это на уровне достаточном, чтобы принимать решения, объясняться с заказчиком и отслеживать, насколько действительность соответствует планам.
Менеджеры на практике задают такие вопросы, которые, хотя и являются техническими, но, обычно, не покрываются техническим интервью. Эти вопросы являются «промежуточными» между техническими и менеджерскими.
Например, если эксперт хочет узнать, умеет ли кандидат анализировать и улучшать производительность приложений он спросит про инструментализацию и профайлеры, он спросит про опыт в улучшении производительности, он спросит про подходы в построении высокопроизводительных приложений с нуля.
Но это совсем не то, что нужно знать менеджеру. На менеджерских собеседованиях я задаю вопрос: «Заказчик пишет вам гневное письмо, утверждая, что ваше приложение работает медленно. Что вы будете делать?»
Этот вопрос покрывает совсем другую сторону работы разработчика. Даже если кандидат прекрасно умеет оптимизировать приложения, в реальной жизни задачи не приходят готовыми, «на блюдечке с голубой каёмочкой». Перевести задачу из практической, неформальной формы в форму, пригодную для решения – это часто тоже задача разработчика.
Например, с одним из кандидатов получился следующий диалог в ответ на вышеприведённый вопрос о медленном с точки зрения заказчика приложении. Заказчик недоволен, что будете делать?
– Я попрошу организовать митинг с заказчиком, – ответил кандидат.
– Отлично. И что вы на этом митинге будете делать? – начало ответа мне понравилось. Когда информации нет, то это хорошая идея поговорить напрямую.
– Я попрошу заказчика показать проблему. Может быть её и нет.
– И дальше?
– Всё, на митинге делать нечего. Пойду анализировать код.
Я прямо представил себя на таком митинге, где заказчика просят показать проблему, а потом разработчик убегает, и я остаюсь один на один с заказчиком, чтоб объяснить ему, что происходит.
Гораздо спокойней я бы чувствовал себя с разработчиком, который:
– Вместе с приглашением на митинг спросил бы у заказчика, в какой части приложения возникает проблема.
– Просмотрел бы ешё разок, какие требования по производительности у нас были.
– Посмотрел бы , какие требования к оборудованию должны быть для нормальной работы приложения.
– На митинге не позабыл бы спросить у заказчика, что для него «быстро» и «медленно».
– Приготовил бы к митингу пункты, которые нужно проверить (конфигурация оборудования заказчика, загрузка сети, зугрузка сервера БД и т.д.).
–Был бы готов сообщить заказчику, как мы будем исследовать и решать эту проблему.
Многие из этих пунктов может сделать и менеджер, но они должны быть основаны на технических знаниях, на знании архитектуры приложения. Для того, чтобы разработчик стал высокооплачиваемым, ему нужно быть готовым такие проблемы решать.
При обсуждении технических вопросов играют роль не собственно технические знания, а способность кандидата использовать эти знания в условиях, приближенных к реальным. Я беру случаи из своей практики, выкидываю из них ненужные подробности и получаю ситуации для обсуждения: «Заказчик просит ускорить приложение», «Вам нужно исправлять баги в большом legacy проекте с кучей технического долга», «Вы делаете ревью кода и заметили, что вся команда делает одни и те же ошибки». Когда кандидат будет описывать, что он будет делать в этих ситуациях, он должен будет использовать свои знания из разных технических областей и свои soft skills.
Если вы не сможете эффективно обсуждать подобные ситуации в тепличных условиях собеседования, то будьте уверены, что в реальной работе вас будут ждать большие проблемы.
