Прозрачность: иллюзии единой системы. Часть 2

Хорошее собеседование  —  это просто неформальная беседа двух увлеченных программистов

Чарльз Баркли поразительно точно отметил:

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

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

Мое самое первое собеседование в индустрии ПО было именно таким. Это была компания, предоставляющая услуги обслуживания приложения для клиентов по всему миру, что мне не очень нравилось: я всегда хотел работать в продуктовой компании. Тем не менее я присутствовал на собеседовании и представитель компании, ведущий программист, был просто потрясающий.

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

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

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

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

Не будьте умным работодателем

Дейт Бэнгер (Deyth Banger) точно выразился, когда сказал:

Лучше прикинуться тупицей, чем умником… в конце концов, умники получают то, что они заслуживают.

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

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

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

Не думайте, будто ваше решение единственное

Вы задаете каверзный вопрос кандидату и ждете от него только одного конкретного правильного ответа. Что-то иное неприемлемо. Но это же чушь.

Хорошее собеседование программиста посвящено тому, чтобы получить представление о его способности решать проблемы и о методах этих решений. Если вы зациклены на конкретном решении и, что еще хуже, ожидаете, что программист придумает только его, то это не оставляет места для дальнейших дискуссий. Что еще хуже, вы можете в итоге выбрать посредственного программиста, не очень-то умеющего мыслить нестандартно. И наихудшая ситуация: программист просто хорошо запоминает решения и дал вам именно то, которое вы хотели услышать, но в действительности этот человек — просто ужасный программист.

Помните, что для раскрытия творческого потенциала необходимо сотрудничество, но грань между сотрудничеством и сговором очень тонкая. Принцип сотрудничества — “не соглашайся, чтобы согласиться”. Он выявляет лучшее в людях. Принцип сговора— “соглашайся без несогласия”. И это  —  рецепт катастрофы.

Не задавайте задачки

Ребекка Уэллс сказала однажды:

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

Какой самый необычный способ сломать часы?

Рост продавца в мясной лавке  —  пять футов десять дюймов, он носит кроссовки 13 размера. Сколько он весит?

В Британской Колумбии невозможно сфотографировать человека с деревянной ногой. Почему?

По мнению некоторых просвещенных работодателей, такие задачи помогают понять, как программисты “думают”, особенно если они столкнулись с неизвестными, неразрешимыми проблемами. Но это один из самых лучших способов… разозлить хорошего программиста.

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

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

Не просите программиста писать код на бумаге

Об этом хорошо сказал Ричард Фейнман:

Я не понимаю то, что не могу создать.

Просить программистов написать код на листе бумаги (или даже на доске)  —  это очень глупая идея. Программисты  —  профессионалы, а к профессионалам нужно относиться иначе, чем как будто вы учитель, который просит детей написать алгоритмы на доске.

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

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

Не задавайте слишком много вопросов, не связанных с работой

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

Но все быстро пойдет под откос, если вы будете упорствовать только в расспросах о предметах, не связанных с работой. Это приведет программиста в замешательство и, в конце концов, рассердит. Он начнет бормотать что-то себе под нос: “Что, черт возьми, происходит?” и терять интерес.

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

“У вас есть дети?”

“Какая у вас национальность?”

“Сколько вам лет? Вы выглядите молодо” (особенно для девушки).

И так далее…

Эмпирическое правило гласит: не нанимайте программиста, который вписывается в культуру. Нанимайте программиста, который “подходит для этой работы”.

И последнее

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

“Собеседование с опытными менеджерами  —  о квалификации… собеседование с неопытными менеджерами  —  о дисквалификации.

---

Перевод статьи Vaidehi Joshi: Transparency: Illusions of a Single System (Part 2)