Парное программирование для собеседования [закрыто]

https://stackoverflow.com/questions/596426

09-09-2019
|

Вопрос

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

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

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

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

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

РЕЗУЛЬТАТ — ПО ЗАПРОСУ

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

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

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

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

Решение

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хороший вопрос, однако.Есть над чем подумать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общая информация:Джоэл Спольски — соучредитель stackoverflow.com

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow