Является ли «White-Board-Coding» неуместным во время интервью? [закрыто]

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

Мы разделили наше техническое интервью на 4 части. Напишите код, прочитайте и проанализируйте код, сессию дизайна и код на белой доске.

Что касается последней части, мы просим респондентов написать небольшой фрагмент кода (4-5 строк) на доске и объяснить, как они его проходят. Позвольте мне прояснить, цель не состоит в том, чтобы поймать людей Мы не ищем идеальный синтаксис. Черт, это может быть даже псевдокод. но дело в том, чтобы дать им очень простую проблему и посмотреть, сможет ли их мозг сообщить нам решение. Под простыми задачами я подразумеваю «Перевернуть строку», «FizzBuzz» и т. Д.

Обратите внимание, что мы всегда сначала запрашиваем явный язык. Мы дом .NET C #. мы говорили только «псевдокод», когда кто-то глушил / действительно боролся с кодом.

У меня такой вопрос: «Неуместно ли / необоснованно ли ожидать, что программист напишет фрагмент кода на доске во время интервью?»

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

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

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

Мой вопрос: «Разве это неуместно / неразумно ожидать, что программист напишет фрагмент кода на доске во время интервью?»

Это очень разумно. Альтернативой интерактивной доске могут быть ноутбук и проектор, поскольку программисты чаще пишут код на клавиатуре, чем на доске. Просто убедитесь, что среда разработки, такая как Eclipse, VS или Idle, уже запускается с пустым проектом при запуске кандидата, чтобы ей не пришлось тратить время на поиск в установленных приложениях.

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

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

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

В последней части мы просим респондентов написать небольшой фрагмент кода (4-5 строк) на доске и объяснить, как они его проходят.

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

На твоем месте я бы сделал это Для последней части ...

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

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

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

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

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

• Хороший код не пишется, он переписывается. Доска в значительной степени неизменна, так как ее трудно изменить после того, как вы ее написали. Должно быть как можно проще изменить свое мнение, как только вы лучше поймете проблему.
• Нахождение на собеседовании является стрессовой ситуацией, поскольку нет необходимости оказывать дополнительное давление на кандидата. Многие компьютерные люди не имеют хорошего почерка. Современные IDE предоставляют множество инструментов, к которым вы привыкли. И возможность что-то гуглить в ту минуту, когда вам это нужно, также является частью стиля работы большинства программистов. Зачем убирать все эти вещи и создавать искусственную среду, в которой им никогда не придется работать, если вы сделаете им предложение?
• Мы также очень заинтересованы в способности писать хорошие тесты, может быть, даже делать TDD. Это невозможно увидеть во время кодирования доски.

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

Хотя сессия на доске, вероятно, помогает отфильтровывать плохих кандидатов, она также отфильтровывает многих хороших программистов.

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

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

Но да, доска идеально подходит, хотя я думаю, что вы должны принять другой набор проблем. Предоставьте им реальную проблему и попросите их нарисовать кучу скандалов на языке UML, чтобы объяснить их общую стратегию решения этой проблемы. Дайте им компьютер с Интернетом, чтобы они могли искать сторонние библиотеки, которые они могли бы использовать в качестве «черных ящиков» в своем сквибл-бэке.
Через несколько минут вы действительно увидите, как они решают проблемы. На самом деле вы можете сделать это очень интересной вещью, выбирая проблемы, для которых у вас не обязательно есть решение, и пытаясь «решить» их вместе, чтобы увидеть, насколько хорошо они общаются и насколько хорошо они могут включать вклад (однако не не давите на них слишком сильно - некоторые люди могут просто замерзнуть, если вы это сделаете). А затем добавить несколько требований на лету. Это похоже на разработку программного обеспечения без реализации и, самое главное, без отладки, поэтому 15 минут - это много времени.

Позвольте мне ответить на другой вопрос:

Дает ли написание кода на белой доске какое-либо реальное преимущество в оценке возможностей программирования по сравнению с набором кода и выполнением кода на компьютере?

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

Нет, но IMO лучшим подходом было бы использовать доску по ее прямому назначению и использовать UML / sketchches / notes для какого-то вымышленного проекта, а не старый «напишите мне SQL-запрос для получения всех записей» или «напишите метод, который переворачивает строку ".

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

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

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

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

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

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

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

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

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