«Тестирование» доски во время собеседования: законный способ резервного копирования кода (доски)? [закрыто]

15

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

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

Кто-нибудь пробовал / видел этот подход? Достойна ли вся идея?

[это также относится к случаю с ручкой и бумагой, конечно]

mlvljr
источник
23
Если бы я хотел, чтобы кто-то написал код на доске или бумаге во время собеседования, я бы не ожидал, что он будет на 100% синтаксически правильным - это оказывает на них слишком большое давление. Да, это должно быть в целом правильно, но пропущенные точки с запятой или даже немного неправильное получение имени метода / профиля параметра - это (или должно быть) ОК.
ChrisF
17
Я большой поклонник кодирования доски на собеседованиях, но любой, кто ожидает, что ваш код доски будет синтаксически совершенен, делает это неправильно. Дело в том, чтобы увидеть, как вы атакуете проблему, а не в том, что вы можете создавать синтаксически совершенный код в абсолютно нереалистичной среде.
Тим Гудман
3
Вы должны быть в состоянии сказать, что есть что, попросив их дать подробный комментарий о том, что они делают, например, или обсудить решение с ними после того, как они закончат.
ChrisF
6
Чрезмерное беспокойство по поводу точного синтаксиса и правописания будет стоить очков интервьюера в моей книге.
JeffO
2
это то, что псевдо-код для
JK.

Ответы:

49

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

Вот несколько отличных способов не пройти тест «Кодирование доски»:

  • откажись
  • не задавайте ни одного уточняющего вопроса (язык, платформа, что-то о требованиях), И не рассказывайте мне свои предположения о каком-либо из них И делайте предположения, далекие от того, на что я бы ответил

(например: напишите это на Фортране, интерпретируйте «display» или «print» как «запись в журнал событий», что-то в этом роде. Я мог бы разрешить это, если вы заранее сказали мне, что это были ваши предположения)

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

(Мы здесь консультанты. Я проверяю поведение консультантов так же, как и кодирование. Спрашивать клиента правильно, только если у клиента действительно есть выбор. Управлять разговорами с людьми, которые будут вам платить, сложно. Это урок 1. Это отметьте себя на любую тему, но для конкретного «вы нанимаете программиста на X, но я не хочу писать для вас на X», теперь у вас есть две большие черные отметки.)

  • Покажите мне, какой вы астронавт архитектуры, заполнив две доски интерфейсами, фабричными шаблонами, абстракциями, инъекциями и тестами, когда я хотел, чтобы вы «печатали числа от одного до 5».

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

Я всегда говорю "тебе это нравится?" "Вы можете улучшить это?" «проведи меня через это» и тому подобное. Как правило, пропущенная точка с запятой обнаруживается, или один за другим, в этом разговоре. Если нет, я обычно отмечаю это до нервов.

Другие вещи, которые вы можете не иметь значения на доске, которые важны для меня:

  • когда ты закончишь, я все еще могу это прочитать? Вы испачкались, набросали, поменяли цвета, нарисовали стрелки, вычеркнули и вообще оставили беспорядок, который теперь нельзя использовать? Или вы знаете, что доски стираются, указывают на строки кода в воздухе вместо того, чтобы обводить их стрелками или стрелками, и оставляют мне то, что я могу сфотографировать и сохранить в файле дизайна?
  • сколько ты спросил у меня как ты это сделал? Вам нравится оставаться в одиночестве и не обсуждать свой код, или вы рассматриваете код как вещь для совместной работы? Как вы ответили, когда я спрашивал вас, когда вы еще это писали?
  • Вы насмехались над «легкой» задачей или падали в обморок от «тяжелой»? Вы были грубы из-за того, что вас попросили показать, что вы можете кодировать? Вы легко запуганы технической проблемой или высокомерны из-за своей способности придумать хороший алгоритм?
  • Вы решаете это в своей голове или вспоминаете решение, которое вы где-то читали? Я обычно могу сказать о трудных проблемах.
  • Вы планировали заранее о том, где вы начали писать? Люди, у которых заканчивается доска, обычно начинают слишком низко или пишут слишком много - я могу сказать, что они не знали, что это будет 20 строк кода, и поэтому оставалось место только для 5 - верьте этому или нет, эта крошечная деталь отражена в большие задачи оценки, а также.
  • Вы смотрели это до того, как сказали, что закончили? Я видел, как вы указали или постучали по нему и сами проверили его, прежде чем я вас об этом попросил? Когда я вам подсказывал или задавал конкретные вопросы по этому поводу, вы смотрели на это снова или просто уходили из памяти? Готовы ли вы считать, что ваш первый черновик может быть неполным?

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

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

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

Кейт Грегори
источник
2
Кажется, это один отличный ответ (и, честно говоря, гораздо более интересный, что я изначально надеялся получить). Огромное спасибо.
mlvljr
9
@KingOfHypocrites ты действительно прочитал ответ? Мне не важно пропустить точку с запятой. Посмотри, что там написано, я забочусь 20 минут на доске много говорят о вас.
Кейт Грегори
7
Мне любопытно, подтвердило ли какое-либо исследование интервью на доске. Полное раскрытие: я стал любопытным после того, как просто провалил собеседование на доске. Я не брал интервью в течение нескольких лет, никогда не был хорошим исполнителем / ведущим и в значительной степени застыл. Ваше понимание превосходно, и если бы я прочитал это первым, я бы подумал об этой части собеседования гораздо иначе (и говорил бы больше). Тем не менее, многие люди имеют твердое мнение по этой теме, но это все. Я предполагаю, что существует объективное обоснование этой практики, подкрепленное подтверждающими данными. Есть?
Suboptimus
3
+1 Если честно, я бы подошел к доске в качестве прокси для упражнения в парном программировании, надеясь продолжить поток разговоров о задаче, как предлагает Кейт, - хотя я бы предпочел иметь машину и фактически парную программу с кандидат (или кандидат в парные программы с интервьюером). То, как вы кодируете вместе, так же важно, как то, как вы пишете код самостоятельно, в организации любого размера.
Джулия Хейворд
4
Я знаю, что это старо, но я только что связался с ним, и я хотел бы отметить: один из признаков расстройства визуальной обработки - отсутствие способности оценить пространство, в котором вы пишете, и, следовательно, в конечном итоге не хватает места , Если человеку, которого вы оцениваете, не только не хватает места для большего количества строк, но и персонажи становятся меньше к концу строки, поскольку они понимают, что они начали слишком много, у них может быть просто неспособность к обучению, а не не понимание как долго будет код Попросите их оценить что-то непространственное, и вы можете получить лучший результат.
Yamikuronue
17

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

Мартейн Вербург
источник
2
Я провалил одно собеседование, потому что, как они сказали, я не написал идеально оптимизированный код при первом прохождении теста «ручка-бумага» (из школы «готовься, работай с юнит-тестами-потом-оптимизируй») ). С другой стороны, у них не было тестовой среды, они просто предполагали, что у них есть программисты, которые сделали это правильно с первого раза!
Джулия Хейворд
3
@JuliaHayward - Счастливое спасение для вас по звукам! Не могу поверить, что люди все еще делают это.
Мартейн Вербург
7

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

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

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

FinnNk
источник
2
Ваша история, кажется, доказывает, что ваш тест был эффективным. Вместо того, чтобы вообще спрашивать "Как вы просматриваете код?" они дали вам несколько отзывов. Вы говорили вслух и говорили что-то вроде «должен убедиться, что он реализует все», и хотя вы случайно не обнаружили недостающий, вы показали им, что действительно знаете, как проверять код на наличие ошибок, а не просто отвечать на вопросы об этом. , Вы также, вероятно, не указали на множество ошибок, которые могут иметь некоторые люди, и, возможно, вы видели и другие ошибки. И тогда ты получил работу. Это звучит эффективно для меня, для всех!
Кейт Грегори
2
Кроме того, пропущенные точки с запятой продолжают игнорироваться как реальный минус. Последовательное опечатывание синтаксиса предпочитаемого вами языка означает, что вы медленнее разработчика, чем тот, кто усвоил весь этот синтаксис. Вы постоянно возвращаетесь и исправляете вещи, которые забыли. Есть большая вероятность, что вы сбились с ритма из-за постоянного нытья от IDE. Кроме того, люди, которые оставляют все свои точки с запятой на доске и не замечают, когда вы предлагаете им, не находятся на одном уровне с хорошими разработчиками, которые раз в неделю забывают вводить точку с запятой в IDE, а затем исправляют Это.
Кейт Грегори
2
+1 это неэффективно. Это абсолютно ничего не доказывает. Я уверен, что многие люди, которые проваливают тест, лучше, чем средний парень, который проходит его.
3
@ Кейт - я понимаю, откуда ты, но я не согласен - тем более, что я сейчас сижу на другой стороне стола. Если кто-то регулярно пропускает точки с запятой, я хочу видеть, что в среде IDE нет искусственных условий. Это как ключевой код в моем офисе - я могу набрать номер, не задумываясь, попросить записать его со 100% уверенностью, и я буду изо всех сил. Интервью никогда не будет на 100% реалистичным, поэтому я не хочу делать все возможное, чтобы сделать его еще менее реалистичным.
FinnNk
1
Я гораздо реже пропускаю важный синтаксис на клавиатуре, чем на доске, потому что печатание усиливается мышечной памятью. Тем не менее, опечатка (и недоделка от моего редактора или партнера по паре), особенно в ситуации парного программирования, может привести меня к обратной связи, где ошибки укрепляют нервы, которые вызывают ошибки. Я думаю, что полиглоты, скорее всего, окажутся в невыгодном положении по сравнению с одноязычными кандидатами.
dcorking
5

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


источник
4

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

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

Примечание для себя - придумайте имя
источник
4

Просить кандидата написать код на доске глупо. Существуют современные инструменты, такие как сниппиты, jsfiddle и intellisense. Кроме того, никакой инженер не должен запоминать синтаксис. Синтаксис ищется и на него ссылаются. Если вы запоминаете код, вы, вероятно, не потратили времени на карьеру, изучая, как программировать в мультитенантной среде, оптимизируя синтаксис или даже размещенную среду.

Джеймс Бейли
источник
3
Любой, кто на полпути приличен на определенном языке, должен запомнить синтаксис простого его использования. Если парень пишет код на C # весь день и не знает большую часть синтаксиса, он будет медленным и ужасным. Вы также можете посмотреть, что такое 2 ^ 8, но любой разработчик, который стоит их соли, должен знать, что это за голову, только от того, что сталкивался с ним так часто. То же самое касается синтаксиса.
whatsisname
1
Это просто не соответствует действительности. Запоминать синтаксис в этот день и возраст не нужно. Сказать, что разработчики, которые знают, как кодировать на многих языках, таких как sql, vb, c #, javascript и использовать json, angularjs, telerik и другие, не стоят их соли, потому что они не могут запомнить синтаксис, глупо. Быть хорошим инженером-программистом - это не только математические операторы, как вы перечислите. Как насчет понимания требований, структур дизайна, шаблонов, отраслевого опыта? Существует буквально достаточно синтаксиса в языках и библиотеках, чтобы заполнить заднюю часть грузовика.
Джеймс Бэйли
Дело не в том, чтобы быть «необходимым». Дело в том, что если вы используете что-то достаточно часто, вы запомните это. Если какой-то парень заявляет, что он является разработчиком SQL, но не может написать заявление о присоединении, то это потому, что он либо а) некомпетентен, б) лжет о своей квалификации, либо в) имеет очень странный ум, все три ситуации, с которыми я не хочу иметь дело.
whatsisname
1
«Соединение» - это не то, что обычно спрашивают на доске. Это часто загадки и вещи, не имеющие отношения к работе. Что делать, если кандидат сертифицирован, имеет ученую степень и имеет надежное резюме. Вы все еще думаете, что он "некомпетентен", потому что он не кодирует на белой доске для жизни? Маркетологам не предлагается составлять ежеквартальную маркетинговую стратегию на местах интервью. Это глупо. Вы должны быть в состоянии поговорить с кандидатом и легко определить, умеют ли они кодировать.
Джеймс Бэйли
3

Когда ресторан хочет нанять шеф-повара, владелец не просит его приготовить «горшочек с зубочисткой» и зубочистку.

Не просите разработчика написать код на доске в интервью.


источник
3
А когда спросили?
mlvljr
Во время собеседования
3

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

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

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

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

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

Дэвид
источник
1
Спасибо за ввод, кажется, это правильно о том, о чем я думал, задавая вопрос - можно действительно застрять в коде доски, не зная, является ли он (уже) правильным, и не имея возможности «фактически» его проверить. Хитрое решение - напишите тест на доске! ;)
mlvljr