Парное программирование для собеседования

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

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

Любые мысли о том, хорошая ли это идея / плохая или как заставить ее работать, - это то, что я как бы ищу здесь.

Ваше здоровье!

РЕДАКТИРОВАТЬ:

РЕЗУЛЬТАТ - КАК запрошено

Первые шаги собеседования будем проводить так же, как и раньше. Телефон с последующим лицом к лицу. Вместо того, чтобы возвращать их для третьего и последнего гриля, мы собираемся вернуть 3 разработчиков, чтобы они сели со всеми 7 членами команды. Мы решили позволить команде решать, кого потом нанять.

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

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

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

Ответов (13)

Решение

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

Итак, вы предлагаете первое собеседование и, возможно, второе собеседование как сеанс парного программирования? - Тед Смит (1 минуту назад)

Ага. Вы даже можете подумать о том, чтобы провести простое собеседование по кодированию через Интернет с помощью чего-то вроде CoPilot .

Несколько дней назад у меня было собеседование по парному программированию, и, честно говоря, оно мне не очень нравится. Меня уведомили об этом за день до собеседования, а затем интервьюер сказал мне, что парное программирование - это то, чем я в конечном итоге собираюсь заниматься в работе. Я вошел в офис и попал в пару с одним из очень старших инженеров-программистов. Компания находится в Сан-Франциско, и это хорошо известная компания по парному программированию, все парные программы в офисе. Сначала казалось, что все в порядке, он рассказал обо всех инструментах, которые они использовали, о своей собственной платформе модульного тестирования, которую они создают, и о небольшой части проекта. Затем он в основном написал кучу модульных тестов и попросил меня поработать над реализацией, чтобы она прошла. Как и к вашему сведению, кодовая база, которая уже существует, огромна, я бы сказал, 10 тысяч строк, это ' Это не похоже на сверхсложный проект, но для кого-то сложно просто вмешаться, а затем написать код без предварительного понимания иерархии классов и т.д. исходного кода, который уже существует. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. но для кого-то сложно просто вмешаться, а затем написать код без предварительного понимания иерархии классов и т. д. Мне очень трудно поверить, что он ожидает, что кто-то сразу перескочит на 10-тысячную строку исходного кода, которая уже существует. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. но для кого-то сложно просто вмешаться, а затем написать код без предварительного понимания иерархии классов и т. д. Мне очень трудно поверить, что он ожидает, что кто-то сразу перескочит на 10-тысячную строку исходного кода, которая уже существует. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. Мне действительно трудно поверить, что он ожидает, что кто-то сразу перескочит на 10-килобайтную строку исходного кода, которая уже существует. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. Мне действительно трудно поверить, что он ожидает, что кто-то сразу перескочит на 10-тысячную строку исходного кода, которая уже существует. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как я был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже. Я немного боролся с навигацией по классам и переходом туда и обратно, потому что я не мог вспомнить имена классов, так как был ошеломлен количеством классов / кода, которые уже существуют. Честно говоря, это действительно заставило меня ужасно себя вести в процессе собеседования. В конце концов, мне это не очень понравилось. Раньше я не занимался парным программированием, в основном только во время заданий в колледже.

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

Это просто мой опыт, полученный на собеседовании по парному программированию, мое предложение, если вы действительно хотите это сделать:

  1. убедитесь, что вы не даете кандидату работать с большой кодовой базой, работать с меньшей базой, и поэтому он / она может показать свои навыки по максимуму
  2. Будьте на связи с кандидатом перед собеседованием по парному программированию, можете ли вы задавать вопросы, когда вы застряли, если у вас есть возможность делать то или это, что вы не можете
  3. быть как можно более подробным

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

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

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

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

У Джоэла Спольски есть отличный Guerrilla Guide to Interviewing, в котором, помимо прочего, говорится о задачах программирования.

Интересный факт: Джоэл Спольски - соучредитель stackoverflow.com

Самый простой способ - дать каждому человеку одного и того же программиста для работы и один и тот же фрагмент кода.

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

Еще одна вещь в парном программировании, на которую вам нужно обратить внимание, - это количество времени, необходимое для того, чтобы каждый кандидат на этом этапе прошел такой тест. Если бы я искал работу, я бы не стал идти на собеседование в компании, которая меня попросит об этом. Почему? Потому что это много времени, и если я прохожу собеседование в нескольких местах, я могу потратить буквально дни, просто идя на собеседование по поводу работы, которую я, возможно, даже не получу или не хочу. Некоторые места, такие как Google или MS, будут исключением, но большинство мест не похожи на эти два. (Не говоря уже о том, что если они работают над реальным кодом, вы, по сути, просите их выполнять чью-то работу бесплатно).

Мне нравится эта идея. Однако я думаю, что это может быть сложно сделать, поскольку для этого потребуется, чтобы кандидат обладал некоторыми знаниями о проекте, в котором вы с ним будете работать. Кроме того, от 4 до 5 часов кажется немного длинным. Что, если вы сразу увидите, что ничего не получится, вы собираетесь просидеть с кандидатом всю сессию?

Но хороший вопрос. Есть о чем подумать.

Как личный анекдот, на собеседовании меня раскритиковали из-за такой техники. Я далеко зашел в их собеседовании; прошла проверку резюме, отправку кода, и это была личная часть собеседования.

Я только что закончил университет и никогда раньше не занимался парным программированием и не занимался TDD. Они усадили меня, чтобы я сделал упражнение с колодой карт, и это провалилось. Плохо! Я не понимал, почему интервьюер писал тесты, которые казались такими глупыми * (IE "return null;"), и они не объясняли, почему и, конечно, будучи чуждым TDD, я не знал, какие вопросы задавать. Конечным результатом было то, что казалось, что я не могу запрограммировать выход из бумажного пакета.

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

** Теперь, когда я понимаю TDD, я понимаю такие тесты и то, как они должны работать, но в то время это казалось глупым! *

Почему нет? Кроме того, интервью не всегда (и не всегда) честны. Вы должны оценить конечные результаты нового подхода по сравнению с традиционным подходом, основанным на собеседовании.

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

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

Ненавижу, когда даются ответы на слишком конкретные вопросы. Однажды у меня было собеседование, на котором программист проверял мои знания о STL, который я широко использовал, и пытался заставить меня ответить, что нужен специальный распределитель. Я слышал о них, но никогда не использовал их (особенно в окнах), и я чувствовал себя немым. IOW, избегайте осуждения.

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

Хороший вопрос!

Одна конкретная компания использует метод, называемый экстремальным интервьюированием . Для экстремального собеседования они соберут, скажем, 30 разработчиков и сгруппируют их в 15 пар. Они объяснят, что ищут людей, которые хорошо работают с другими. Что они примут решение о приеме на работу исключительно на основании своей способности работать с другими.

Они дадут парам задачу решить. Они подчеркнут, что их не интересует решение, а просто способность каждого программиста работать с другими. Для каждой пары они предоставят наблюдателя пары. Во время упражнения (продолжительностью от 2 до 4 часов) наблюдатель будет делать записи о способности человека образовывать пары ... но не решение.

Они удивлены, как много программистов сосредотачиваются на решении проблемы вместо того, чтобы сотрудничать. Из 15 пар они выберут от 4 до 6 разработчиков для второго собеседования. Этих разработчиков попросят вернуться и провести неделю с командой (им платят). Через неделю они решают, кого оставить. Обычно около половины из них (от 2 до 3 разработчиков).

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

У меня только что было интервью с компанией из Сан-Франциско, которая гордится гибкими методами и т. Д. Я должен был взять интервью у самого генерального директора. У меня около 20 лет опыта в отрасли, но я никогда не программировал и не разрабатывал пары с использованием подхода TDD. Мне сказали, что это будет «интервью по программированию», но я не знал, чего ожидать, и перед тем, как мы начали, парень сказал, что, по его мнению, я могу согласиться с тем, что все интервью должны проводиться таким образом. (что в ретроспективе было не более чем высокомерным заявлением).

Как бы то ни было, на собеседовании было предложено разработать класс с использованием TDD. Мне потребовалась секунда, чтобы скорректировать свое мышление по всему процессу, опять же, поскольку я никогда не программировал и не выполнял TDD в паре. Пока я спотыкался то тут, то там, в конце концов все получилось. но его ответ был таким, что я не демонстрировал агрессивного движения вперед и назад, которое им требуется для их среды парного программирования. Так вот, это также могло быть закулисным способом сказать, что «я не думаю, что вы сделали отличное» сообщение.

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

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

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

Но ... как отмечали другие, необходимое время может быть проблемой. Я провел пару дней собеседований и нашел некоторые периоды хорошими, в то время как другие чувствовали, что несколько часов были потрачены впустую: один из-за того, что разработчик не работал над чем-то, что подходило для создания пары (особенно с учетом моего опыта), другой, потому что проблема с env какое-то время мешала многим полезным работам. Если с работой не получается, может быть неприятно, что вы взяли для этого день или два отпуска.

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

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

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

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