Разработчики давно разделились на два лагеря — одни ненавидят парное программирование, а другие его обожают. Обе стороны правы, и здесь нет никакого противоречия: парное программирование, как и любая другая инженерная практика, имеет свои сильные и слабые стороны. Мы подробно рассказываем вам о том, как устроено парное программирование и почему его часто применяют во время собеседований.
Это адаптированный перевод статьи Why Pair Programming Is the Best Interview Approach for Hiring. Повествование ведется от имени автора.
У меня на работе часто программируют в парах, а еще используют парное программирование как формат для собеседований. Теперь это мой любимый формат, потому что он позволяет проверить способности кандидата с наименьшим количеством усилий.
Мы получаем ответ сразу на три вопроса:
- Как человек ведет себя в процессе написания кода?
- Какие у него прикладные навыки?
- Впишется ли он в коллектив?
Я понимаю, что трудно поверить, что один подход решает так много проблем.
Большинство подходов к собеседованию ничего не говорят о кандидате
Если человек прошел собеседование — это значит, что он умеет проходить собеседования. И все. Это не значит, что человек сможет написать фичу для сложного приложения, а именно это от него и потребуется.
Вопросы на доске
То, как человек отвечает на вопросы по алгоритмам, написанным на доске, говорит о многом. Например о том, как кандидат работает под давлением или о том, каковы его интеллектуальные способности. Но вот только этот этап собеседования легко пройти, если ты хорошо подготовился.
Даже синьоры с трудом ответят на вопросы по алгоритмам, если не дать им время на подготовку.
У крупных компаний есть веская причина фильтровать соискателей через вопросы по алгоритмам. Они ведь ищут человека въедливого, эрудированного. Но это еще не значит, что такой подход оправдан в среднем и малом бизнесе — они, как правило, ищут человека, который способен написать рабочий код, и для них это важнее всего.
К сожалению, глубокие познания соискателя в области алгоритмов и структур данных никак не помогут ему, если он не знает ни языка, ни фреймворка.
Вопросы по языку и фреймворкам
Эти вопросы тоже бесполезны. Попросите джуна своими словами описать промисы в JavaScript или декораторов в Python, и он зависнет. Спросите синьора про какую-нибудь малюсенькую деталь вашего языка или фреймворка, и он тоже застрянет. Если только не почитал об этом накануне, конечно.
А хуже всего то, что все эти вопросы никак не связаны с реальной разработкой. В реальности если ты забыл какую-то мелочь, ты пошел и почитал документацию — все, проблема решена.
Вопросы по софт-скиллам
Трудно проверить софт-скиллы кандидата, потому что ничего не мешает человеку просто выучить правильные ответы на ваши вопросы. Вы узнаете о слабых и сильных сторонах соискателя только то, что он хочет, чтобы вы знали.
Домашка и тестовое задание
Если вы даете тестовое на дом, человек может над ним сидеть часами. Я думаю, что это пустая трата драгоценного времени, которое он мог потратить на настоящую работу.
А еще кандидат может сделать тестовое, попросив помощи друзей. Или делать его 20 часов, хотя задание рассчитано на час. И в том, и в другом случае вам не нужен такой работник, но о том, как он на самом деле делал тестовое, вы не узнаете.
Парное программирование
Как я уже писал выше, парное программирование устраняет все перечисленные проблемы. В мире, где собеседования — это необходимое зло, парное программирование мне кажется наименее болезненным форматом.
Особенности парного программирования, если вы нанимаете разработчика
Ни один другой формат интервью не дает мне так много информации о кандидате как парное программирование. И это важно, ведь здоровые отношения в команде — это основа компании, ее культуры и продуктивности.
Парное интервью это самая настоящая командная работа. Причем без разницы, кто из вас пилот, а кто — навигатор, ведь перед вами стоит задача написать новую фичу, и вы работаете как единое целое. И для кандидата парное собеседование проще — ведь это не викторина, к которой надо просто выучить правильные ответы.
Читайте историю успеха: Как стать программистом, не получая от этого удовольствия. И уже потом влюбиться в профессию
Кроме того, парное программирование дает мне сразу понять, кто передо мной — скромняга или хвастун. Лично я предпочитаю работать со скромным разработчиком, который знает, что делает, чем с примадонной, которая постоянно закатывает сцены.
Если с кандидатом неприятно программировать в паре, мы его не нанимаем, все просто. А как иначе? Если разработчики не могут работать в команде без конфликтов, то это конец.
Еще надо помнить о том, насколько дорого обходится весь процесс найма. Парное программирование это отличный способ избежать лишних трат и быстро отфильтровать людей, которые будут вредить команде.
Особенности парного программирования для тех, кто ищет работу
Парное программирование — это возможность для кандидата прочувствовать на собственной шкуре, какой может быть работа с вами. И если ему не понравится этот опыт, ничего страшного, он имеет полное право отказаться от вашей вакансии.
Было бы хуже, если бы соискатель согласился на оффер, а потом страдал. Это нехорошо для обеих сторон.
Все было бы просто, если бы программист только обменивал свой код на зарплату. Но реальность намного сложнее. В реальности продуктивность упадет, если работник несчастен. Поэтому так важно дать соискателю опыт работы в компании — если ему не нравится эта работа, он это сразу поймет.
Парное программирование даст кандидату больше информации о будущей работе, чем он получил бы сам, задавая вопросы. Поэтому я с уверенностью заявляю, что это лучший способ понять, впишется ли соискатель в коллектив.
А сейчас я скажу то, что может шокировать противников парного программирования. Многие соискатели говорили нам, что им проще программировать в паре, чем проходить стандартное собеседование. Мне кажется, что одного этого факта уже достаточно, чтобы все претензии к парному программированию на собеседовании отпали.
Читайте также: Как сохранять фокус на протяжении всего обучения: советы от Хекслета
Что происходит в голове у соискателя
Во время наших парных сессий я получаю море информации о том, как соискатель ведет себя в разных ситуациях.
- Медитирует он на код или просит помощи?
- Пользуется гуглом? (это, кстати, не криминал)
- Он реализует первую попавшуюся идею или взвешивает разные варианты?
- Он думает о вычислительной сложности в процессе написания кода?
- Он может описать логику словами перед тем, как написать код?
- Активно ли он общается с напарником или работает молча?
Всего час над написанием фичи и я уже понимаю, как человек ведет себя в самых разных ситуациях.
Дисклеймер! Парное программирование имеет свои недостатки. Например человек не может писать код, когда за ними наблюдают, но в остальном это может быть хороший специалист.
Но даже с учетом этого, парное программирование — мой любимый формат собеседования.
А сможет ли он включиться работу?
Вопросы по алгоритмам заставляют соискателя рассматривать проблему в вакууме, а мне гораздо интереснее, сможет ли он работать над живым приложением. Приложением, которое постоянно меняется.
Парное программирование отвечает на вопрос: «Сможет ли соискатель сразу включиться в работу?». Еще я избегаю риска обмануться эрудицией соискателя, пока он мне про алгоритмы рассказывает. Ведь на самом деле моя задача — проверить его практические навыки, а не знания алгоритмов.
А еще мне неважно, если соискатель не может по щелчку пальцев выдать решение. Ничего страшного, если он пойдет почитать документацию, это тоже важный навык. Как и навык просить помощь у более опытного коллеги. Когда команда маленькая (как у нас), очень важно уметь полагаться друг на друга.
Между собеседованиями и реальной работой лежит глубокая пропасть. Парное программирование закрывает эту пропасть так хорошо, как только это возможно.
Заключение
Я понимаю всех, кто ненавидит парное программирование. Очень многим не нравится, когда другие наблюдают за их работой. От автора подобной статьи такое признание звучит странно, но я тоже когда-то был противником парного программирования.
Но я поменял свое мнение. Но если мне не удалось поменять ваше, ничего страшного. Вы можете избегать компаний, как наша, где часто программируют в парах, ведь иначе вам будет некомфортно. Несчастный работник — это плохой работник.
Конечно, парное программирование подойдет не для всех типов разработки, однако для веба это отличный формат. Еще больше формат подходит, если команда маленькая и дружная, даже если вы создаете сложные продукты.
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
