Парное программирование для собеседования
Наша компания думала о том, чтобы отменить наши процедуры собеседования и пригласить каждого кандидата на 4-5 часов, чтобы посидеть с некоторыми программистами и просто заняться парным программированием.
Мне нравится идея в теории, но я не уверен, как вы можете сделать это справедливо для каждого кандидата. Как бы вы оценили их? Разве их вклад не будет зависеть от того, над чем работал каждый программист в тот день?
Любые мысли о том, является ли это хорошая идея / плохая идея или как заставить ее работать, это то, что я отчасти ищу здесь.
Ура!
РЕДАКТИРОВАТЬ:
РЕЗУЛЬТАТ - КАК запрашивается
Мы собираемся провести первые шаги собеседования так же, как и раньше. Телефон сопровождается лицом к лицу. Вместо того, чтобы вернуть их для третьего и последнего гриля, мы собираемся вернуть 3 разработчиков, чтобы они сидели со всеми 7 членами команды. Мы решили позволить команде решить, кто тогда будет нанят.
Мы пришли к такому выводу по нескольким причинам. Мы считаем, что это даст разработчикам возможность дать им выбор, над кем они работают. Вторая причина - групповая динамика. Мы думаем, что очень важно иметь хорошую групповую динамику, и трудно сказать, до тех пор, пока вы не наймете человека, подойдет ли он вам или нет.
Таким образом, конечный результат заключается в том, что мы собираемся продолжить сессию парного программирования, но совершенно другим способом и совершенно другим способом, чем первоначально предполагалось.
Любые мысли или критика такого подхода приветствуются! (это изменение опубликовано как ответ ниже, поэтому не стесняйтесь понижать голос, если считаете, что это не лучший подход)
13 ответов
Я надеюсь, у вас есть несколько шагов впереди этого. Для этого вам понадобится отличное резюме и экран телефона. Вы не хотите тратить кучу времени на кандидатов, с которыми вам вообще не следует разговаривать.
Таким образом, вы предлагаете начальное интервью и, возможно, второе интервью в качестве сеанса парного программирования? - Тед Смит (1 минуту назад)
Да уж. Вы можете даже подумать о том, чтобы провести простое собеседование по кодированию через Интернет, используя что-то вроде CoPilot.
Если вы не будете широко использовать парное программирование в своей реальной разработке, я бы очень колебался использовать это. Я встречал множество профессиональных разработчиков высокого уровня, которые упомянули о сильном отвращении к парному программированию и чьи навыки не были бы хорошо оценены в таком процессе.
Самый простой способ - дать каждому человеку один и тот же программист для работы и один и тот же кусок кода.
Проблема, с которой вы столкнетесь, заключается в том, что найм не похож на программирование. Не существует пошагового процесса, который бы приводил к правильному ответу относительно того, кого нанимать. (Вы можете сделать несколько шагов, чтобы сделать решение проще). Вы должны оценить каждого из них по их сильным сторонам и т.д. и, по сути, сделать обоснованное предположение о том, какой из них лучше всего нанимать. Иногда ты угадаешь неправильно.
Еще одна вещь в парном программировании, которую вы должны будете отслеживать, это количество времени, необходимое для того, чтобы каждый кандидат на этом этапе прошел такой тест. Если бы я искал работу, я бы не хотел идти на собеседование в компанию, которая попросила бы меня это сделать. Зачем? Потому что это много времени, и если я беру интервью во многих местах, я мог бы потратить буквально дни, просто посещая собеседования на работу, которую я могу даже не получить или не хотеть. Такие места, как Google или MS, были бы исключением, но большинство мест не такие, как эти два. (Не говоря уже о том, что если они работают над реальным кодом, вы по сути просите их сделать чью-то работу бесплатно).
У меня только что было интервью с компанией из Сан-Франциско, которая гордится гибкими методами и т. Д. Я должен был взять интервью у самого генерального директора. У меня около 20 лет опыта работы в отрасли, но я никогда не программировал и не разрабатывал с использованием подхода TDD. Мне сказали, что это будет "собеседование по программированию", но я понятия не имел, чего ожидать, и, прежде чем мы начали, парень сказал, что он думает, что я могу согласиться, что все собеседования должны проводиться таким образом. (который в ретроспективе был не более чем высокомерным заявлением).
Во всяком случае, на собеседовании упражнение было разработать класс с использованием TDD. Мне потребовалась секунда, чтобы настроить мое мышление на весь процесс, опять же, так как я никогда не программировал пару или не делал TDD. В то время как я споткнулся здесь и там, я все сделал хорошо в конце. но его ответом было то, что я не проявлял агрессивный характер, который им необходим для среды парного программирования. Так вот, это также могло бы быть закулисным способом сказать, что "я не думаю, что вы сделали великолепно".
К счастью, мне не нужна была работа, и, честно говоря, опыт заставил меня понять, что я предпочел бы найти другую карьеру, чем необходимость быть инженером-программистом, который должен работать парами, день за днем, когда дело доходит до разработки код. Странно то, что иногда я работал с другим человеком над кодом одновременно, поэтому все возможно.
В конце концов, я думаю, что это был хороший результат, так как они не думали, что я был в хорошей форме, и мне не было дела до их методов работы. Но мы бы пришли к такому же выводу, если бы я немного поговорил о себе и дал бы мне немного больше информации о том, как они работают. Это значит, что есть другие способы найти подходящего кандидата, чем подвергнуть их стрессу парного программирования с совершенно незнакомым человеком; фиктивный способ оценить компетентность ИМО.
Как личный анекдот, я попал в интервью из-за такой техники. Я далеко продвинулся в процессе собеседования; прошли проверку резюме, отправку кода, и это была личная часть интервью.
Я только что закончил университет, никогда раньше не программировал пар и не занимался TDD. Они усадили меня, чтобы выполнить упражнение с колодой карт, и оно провалилось. Плохо! Я не понимал, почему интервьюер писал тесты, которые казались такими глупыми * (IE "return null;"), и они не объясняли, почему и, конечно, будучи чужими TDD, я не знал, какие вопросы задавать. Конечным результатом было то, что я не мог запрограммировать свой выход из бумажного пакета.
Если вы собираетесь выполнять это упражнение, вам нужно удовлетворить собеседника, потому что он будет находиться в разных местах со своей способностью. Это означает, что вы получите разные оценки, которые могут не основываться на реальных талантах и, таким образом, будут сильно смещены.
** Теперь, когда я понимаю TDD, я понимаю такие тесты и то, как они должны работать, но в те времена это казалось глупым!*
Одна конкретная компания использует технику, называемую экстремальное интервьюирование. Для экстремального интервью они приведут, скажем, 30 разработчиков и сгруппируют их в 15 пар. Они объяснят, что ищут людей, которые хорошо работают с другими. Что они будут принимать решение о найме, основываясь исключительно на их способности работать с другими.
Они предоставят проблему для пар, чтобы решить. Они подчеркнут, что они не заинтересованы в решении, так как каждый программист может работать с другими. Для каждой пары они предоставят наблюдателя от пары. Во время упражнения (продолжительностью от 2 до 4 часов) наблюдатель будет делать заметки о способности человека к соединению... а не о решении.
Они поражены тем, сколько программистов сосредоточено на решении проблемы, а не на сотрудничестве. Из 15 пар они определят от 4 до 6 разработчиков для второго интервью. Этим разработчикам будет предложено вернуться и провести неделю с командой (им платят). Через неделю они решают, кого оставить. Обычно около половины из них (от 2 до 3 разработчиков).
Когда они готовы, у них есть разработчики, которые могут сотрудничать, и после недели работы с различными парами у команды есть четкое представление о том, кто может эффективно разрабатывать программное обеспечение. Процесс является инновационным и эффективным. У них был высокий показатель успеха с теми, кого они наняли.
У меня было пару дней назад интервью по парному программированию, и, честно говоря, оно мне не очень нравится. Я был уведомлен об этом за день до интервью, а затем интервьюер сказал мне, что парное программирование - это то, что я в конечном итоге собираюсь делать в работе. Я вошел в офис и был в паре с кем-то, кто является очень старшим инженером-программистом. Компания находится в Сан-Франциско, и это хорошо известная компания по парному программированию, все парные программы в офисе. Поначалу все было в порядке, он объяснил все инструменты, которые они использовали, их собственную структуру модульного тестирования, которую они создали, и немного о проекте. Затем он написал несколько модульных тестов и попросил меня поработать над реализацией, чтобы она прошла успешно. Как и в случае с FYI, база кода, которая уже существует, огромна, я бы сказал, 10 тыс. Строк, это не очень сложный проект, но для кого-то сложно просто вмешаться, а затем написать код без предварительного понимания иерархии классов и т. Д. Мне действительно трудно поверить, что он ожидает, что кто-то сразу запрыгнет в уже существующую строку исходного кода длиной 10 тысяч. Это просто не подходит для собеседования по парному программированию, поможет меньшая база кода. Я немного боролся с перемещением по классам и переходом назад и вперед, потому что я не могу вспомнить имена классов, поскольку я был поражен количеством классов / кода, который уже существует. Если честно, это действительно сделало меня ужасным в процессе собеседования. В конце концов, я не очень хорошо к этому относился. Раньше я не занимался парным программированием, в основном это было только во время моего студенческого года.
Для меня сила парного программирования может быть использована, если вы уже хорошо владеете парой, но не очень подходит для собеседования. Иногда я хотел бы задать вопросы своей паре, но потом я подумал, что если я задам слишком много вопросов, то они могут предположить, что я глуп и не могу выступить. Если бы это было уже на реальной работе, я бы без колебаний спросил, но на собеседовании это сложно... вы хотите спросить, потому что ваша пара должна помочь вам, когда вы застряли, но в то же время это интервью так что вы не можете много спрашивать.
Это всего лишь мой опыт, полученный во время интервью по парному программированию, мое предложение, если вы действительно хотите сделать это:
- будьте уверены, что вы не дадите кандидату работать с большой базой кода, работайте с меньшей, и поэтому он / она может показать свои навыки по максимуму
- будьте откровенны с кандидатом перед собеседованием в парном программировании, можете ли вы задавать вопросы, когда застряли, сможете ли вы делать то и то, что не можете делать
- быть максимально подробным
В конце концов, я бы не стал это предлагать. Трудно измерить эффективность кандидата в парном программировании, и это также может быть предвзятым.
Мне нравится эта идея. Тем не менее, я думаю, что это может быть трудно сделать, так как это потребует от кандидата определенных знаний о проекте, с которым вы будете работать в паре с ним. Кроме того, от 4 до 5 часов кажется немного длинным. Что, если вы сразу увидите, что это не сработает, вы собираетесь провести весь сеанс с кандидатом?
Хороший вопрос, хотя. Материал для размышления.
Почему бы и нет? Кроме того, интервью не всегда (или никогда) честно. Вы должны оценить конечные результаты нового подхода по сравнению с традиционным подходом на основе интервью.
Кроме того, мини-интервью перед сеансом парного программирования может быть полезным, чтобы не тратить время программистов на людей, которые плохо подходят.
Из моего ограниченного опыта мои чувства смешаны. Мне нравится идея спаривания как часть интервью, особенно. если компания часто использует сопряжение, потому что это дает обоим лучшее чувство соответствия. Как кандидат, я часто проходил собеседования, где я сидел в комнате, отвечая на вопросы в течение нескольких часов, но потом у меня не было хорошего представления о том, каково это было бы работать в их среде. Сопряжение может быть более полезным, чем случайное кодирование, если только интервьюер не умеет работать с ними. И мне нравится обсуждать технические вопросы с обеих сторон. И как кандидат, я бы предпочел взаимодействовать с кем-то, чем просто отвечать на вопросы или решать проблемы кода самостоятельно.
Но... как уже отмечали другие, время может быть проблемой. Я прошел через пару дней парных интервью и нашел некоторые периоды хорошими, в то время как другие чувствовали, что несколько часов были потрачены впустую: один, потому что разработчик не работал над чем-то, что поддается сопряжению (особенно учитывая мой опыт), другой, потому что проблема env помешала многим полезным работам на некоторое время. Если работа не сработает, может быть неприятно, что на это уйдет день или два.
Одно место, пробующее такой подход, не было уверено, должен ли кто-то за пределами компании работать над проектом клиента. Они также обеспокоены тем, что объяснение предметной области и выполняемой работы займет слишком много времени, хотя без этого кандидат не сможет внести большой вклад. Поэтому они выбрали проект с открытым исходным кодом, над которым работал сотрудник.
Кажется, это ключевой момент: должна быть правильно выбранная задача, которую кандидат может быстро понять и внести в нее свой вклад. Последняя часть будет зависеть в некоторой степени от навыков кандидата. Также ключевым будет способность сотрудника оценить кого-то с таким подходом. Не все хорошо справляются с обычным собеседованием, и это, вероятно, больше относится к собеседованию.
Кроме того, если компания не делает много спаривания, то такого рода интервью могут быть не такими полезными. Кажется, полезно видеть чей-то код (как отмечает Джоэл Спольски), и это может быть хорошим способом сделать это. Но если спаривание не является типичной частью работы, то, возможно, полноценный сеанс спаривания не подходит. Возможно модифицированная версия.
Мне было бы любопытно, что компании, которые приняли этот подход, думают о результатах. Чтение некоторых других ответов на этот вопрос показывает, что он не всегда кажется идеальным с точки зрения кандидата.
Чтобы это было честно, вам нужно, чтобы у каждого участвующего сотрудника была подготовленная задача для оценки кандидата. Желательно, чтобы что-то было принято из реального мира в опыте их компании, но что-то, что уже решено Это хороший шанс оценить знания по проблеме и оценить не только навыки программирования.
Я ненавижу, когда на слишком конкретные вопросы отвечают. Однажды у меня было интервью, где программист проверял мои знания о STL, которые я широко использовал, и пытался заставить меня ответить, что нужен специальный распределитель. Я слышал о них, но никогда не использовал их (особенно в окнах) и чувствовал себя глупо. IOW, избегайте осуждения.
Поэтому я хочу задать практические вопросы, которые не столько касаются тестирования знаний в области программирования, сколько вы можете оценить более качественные подходы к решению проблем личности, если вы используете идею "парного программирования".
Хороший вопрос!
Честно говоря, это звучит как отличная идея, хотя Джейсон Пуньон, безусловно, прав, что вы должны прополоть много, прежде чем тратить значительное количество времени ваших разработчиков на отборочные испытания. Вы получаете представление о важной метрике, которая в остальном практически недоступна для интервьюирования: с кем работать.
Я не думаю, что на самом деле нужно беспокоиться о том, чтобы это было "справедливо" на основе предмета или пыталось представить согласованные ситуации разным кандидатам, если вы придерживаетесь правильной оценочной позиции - дело не в том, "получил правильный ответ" или прыгнул через правильный набор обручей, но какие усилия, решение проблем, коммуникабельность и гибкость они показали. Вы потеряете большую часть пользы от этого упражнения, превратив его в искусственный тест, не говоря уже о том, чтобы заменить его чем-то, от чего ваши разработчики могут получить какую-то выгоду (или, по крайней мере, по-прежнему выполнять некоторую работу во время работы), до огромной траты их время
У Джоэла Спольски есть превосходное партизанское руководство по интервьюированию, в котором, помимо прочего, рассказывается о задачах программирования.
Общая информация: Джоэл Спольски является соучредителем stackru.com