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

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

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

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

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

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

Хороший вопрос все же. Материал для размышления о.

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

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

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

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

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

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

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

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

У Joel Spolsky есть превосходное Партизанское Руководство по Интервьюированию , который говорит о, среди других вещей, программируя задачи.

Мелочи: Joel Spolsky является соучредителем stackoverflow.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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