Подтвердить что ты не робот

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

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

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

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

Ура!

EDIT:

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

Хороший вопрос. О чем подумать.

Ответ 9

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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