Программисты, которые настоятельно рекомендуются, но не могут справиться с вопросом программирования бумажного теста

Вкратце: Как поступить с программистами, которых очень рекомендуют, но которые не могут ответить на вопрос по программированию бумажного теста

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

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

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

И я уже упоминал, что меня совершенно не волнует синтаксис/язык. Мне достаточно псевдокода

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

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

Редактировать:

  1. Меня не волнует синтаксис, ему это ясно сообщили
  2. На уровне вопросов используются только самые элементарные конструкции, такие как for, if... вообще ничего о вызовах эзотерических библиотек. Все, что требует практических знаний в определенных рамках, считается небазовым. Поэтому я не прошу испытуемого запоминать любые вызовы httpметода.
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Почему вы все еще используете бумажный тест, мне непонятно. Когда кто-нибудь кодирует на бумаге? Вы должны были позволить ему провести тест в среде IDE на системе с зеркальным дисплеем и наблюдать за его процессом. Это скажет вам НАМНОГО больше о том, с кем вы работаете. Ваш тест эквивалентен тому, что вы ставите кого-то перед краскораспылителем в Home Depot и используете этот результат, чтобы решить, является ли этот человек хорошим художником-портретистом.
Как минимум вы думаете, что можете дать кандидату текстовый редактор и компьютер, а не только карандаш и бумагу. Редактирование на карандаше и бумаге — это боль. Мы, программисты, привыкли вставлять вещи.
Как программист, я никогда не верил в эти тесты. Слишком часто они содержат вопросы о вещах, которые вам никогда не понадобятся, и ожидают, что вы будете знать что-то ради знания.
Когда вы говорите, что он не мог правильно решить задачи, вы имеете в виду, что он неправильно понял синтаксис или даже не смог составить псевдокод?
@DaveG, он даже не смог выложить псевдокод
Возможно ли, что кандидат сильно полагается на пробы и ошибки? Компьютерные алгоритмы можно запускать и отлаживать так, как не могут письменные алгоритмы.
@Gaviton Я помню, как еще в школе они пытались преподавать псевдокод, как если бы это был другой язык. Поэтому, когда я кого-то спрашиваю, я говорю что-то вроде «Вы можете написать какой-нибудь псевдокод или написать несколько логических выражений для объяснения», чтобы дать возможность написать что-нибудь вообще, что похоже на код, а не на какой-то новый стандарт псевдокода.
@Gaviton Можете ли вы рассказать нам, какие были вопросы? Это помогло бы нам определить, почему на них нельзя ответить. FizzBuzz плохо сформулирован и недостаточно точен, чтобы давать инструкции программисту. Это на пользовательском языке.
@TrevorD, FizBuzz буквально один из вопросов. Другие вопросы, такие как «получить позицию индекса элемента в массиве», «последовательность Фибоначчи».
Мне трудно определить, что вы ищете в этом вопросе, поэтому ему не уделяется должного внимания. Не могли бы вы переформулировать наверху понятным языком, что вы ищете в Интернете, пожалуйста?
@Mirv, я поставил tl;dr в начале этого вопроса

Ответы (16)

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

Возможно ли, что он поручил кому-то другому сделать эту работу? Конечно.

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

+1 или люди могут иметь инвалидность, как я. У меня дисграфия, поэтому я вообще не могу много писать. (Он теряется между моим мозгом и рукой), но я могу печатать очень хорошо. Чем дальше тест удален от работы, тем менее ценен тест.
Сеанс кодирования на месте или тест кода, когда они получают компьютер и должны что-то кодировать на лету, были бы хороши, а затем попросите их объяснить, что они сделали. Это кажется лучшим отражением того, как люди работают. Если вы используете сопряжение в своей работе, вы также можете объединить их с сотрудником.
@RichardU, если у тебя дисграфия, то как ты сдал школьные экзамены?
Возможно, стоит дать оба. Или вы также можете перейти на несколько более сложные вопросы с несколькими вариантами ответов. Было бы здорово сделать один из возможных ответов - Ни один из них.
@Graviton По крайней мере, в Великобритании студентам можно было дать дополнительное время на экзаменах или даже разрешить использовать компьютер для ответов на экзаменационные вопросы, в зависимости от инвалидности, с которой они могли быть диагностированы. У меня был друг, который в старшей школе стал парализованным и каждый экзамен диктовал писцу со 100% дополнительным временем.
Вот что случилось с нами. Мы снова пригласили замечательного кандидата после того, как он так себе справился с задачами программирования на доске. Мы дали ему онлайн-IDE с базовой средой компиляции/исполнения и снова задали вопрос об алгоритме (синтаксис по-прежнему не имел значения). Честно говоря, второе интервью лишь подтвердило первое. Кандидат слишком долго находился в руководстве и был слишком заржавел в программировании, даже IDE ему не помогла.
@RichardU Хотя я частично согласен с тем, что хорошо проводить тесты, близкие к реальным требованиям, я бы считал обсуждение псевдокода неотъемлемой частью большинства заданий командного программирования. Теперь, когда собеседника просят написать код на бумаге, он действительно может думать о «написании программы», а не об обсуждении общего алгоритмического решения проблемы. В соответствии с ответом я бы, по крайней мере, дал ему другие варианты, чтобы объяснить, как он это решит: белая доска, я пишу ему объяснения, разговариваю и т. д., но общую способность абстрагироваться от кода я бы посчитал настоящим активом.
@Darkwing Да, я плохо справляюсь с такими настройками, однако на прошлой неделе я сэкономил своей компании 1,5 миллиона долларов. Хотя я плохо тестирую. никогда не делал.
@RichardU Поздравляю. Я не говорю, что вы не можете быть великим, если не можете пройти их, но во многих случаях общение в команде о том, что вы делаете и почему, важно, и это инструмент для проверки этого навыка (как я уже сказал, я согласен с тем, что программирование на бумаге имеет довольно большое значение). много недостатков, и я бы выбрал это как вариант среди других вариантов). Я бы также не сказал, что это должен быть единственный навык, который вы ищете на собеседовании, а иногда, например, если вы хотите нанять одного разработчика, который выполняет ваши требования, и вам все равно, как, это не должно быть вообще на столе.
@Darkwing Я знаю, что мой случай уникален. У меня что-то под названием "дисграфия". В моем мозгу есть разрыв в нервных путях между той частью, которая думает, и той частью, которая пишет. Я могу печатать, я могу говорить очень членораздельно, я просто не могу физически писать.
@RichardU Я видел ваш оригинальный комментарий. Вы, вероятно, справитесь с устным объяснением алгоритма, и если вы чувствуете, что можете раскрыть это на собеседовании, я, конечно же, либо напишу для вас что-нибудь на доске, если это необходимо, либо позволю вам использовать компьютер/планшет, чтобы взять примечания. Мое единственное замечание заключалось в том, что само по себе кодирование — не единственный навык, требуемый от разработчика программного обеспечения во многих работах, в частности, способность объяснить, как на абстрактном уровне, также часто является ценным навыком, и я считаю справедливым проверить это. (но с открытым набором инструментов).
Дайте кандидату 30-45 минут, уходите и следите за его трафиком. Посмотрите, посещает ли он спецификацию API/Stack Exchange или начинает обмениваться мгновенными сообщениями со своими друзьями через социальные сети. Сообщите ему, что за ним наблюдают.

Эта ссылка из комментариев https://blog.codinghorror.com/why-cant-programmers-program/ публикует интересную проблему, которую откровенно неприятно писать на бумаге.

Почему?

Вот требования в тексте:

Напишите программу, которая печатает числа от 1 до 100. Но для числа, кратного трем, вместо числа печатайте «Шизз», а для числа, кратного пяти, печатайте «Жужжание». Для чисел, кратных как трем, так и пяти, выведите «FizzBuzz».

Вот требования как шаги

  1. Цикл от 1 до 100 и вывести число
  2. Проверьте, кратно ли 3, и напечатайте «шипение» вместо числа.
  3. Проверяйте число, кратное 5, и печатайте «Buzz» вместо числа.
  4. проверить наличие кратных 3, а также кратных 5, вывести "FizzBuzz"

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

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

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

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

Это очень хороший момент, поскольку разбить требования на этапы — хорошая идея. На самом деле кто-то может написать код и тест для каждого требования, что еще больше затруднит выполнение на бумаге.
Но именно здесь разрешение псевдокода устраняет необходимость перезаписи. Вы можете написать на бумаге: LOOP 100 TIMESзатем с отступом: CHECK MODULO 3и с отступом IF TRUE PRINT "Fizz"и т. д. Синтаксис в Python, например, позволяет это без перезаписи даже на бумаге :)
Вы не правильно написали требования ;)
@Juha Untinen доказывает ли псевдокод что-нибудь полезное? Доказывает ли вопрос что-либо помимо того, что человек, у которого берут интервью, не может переключить треки и увидеть всю проблему в своем уме? Поскольку это очень специфическое требование, обычно для лидов этот навык полезен. Теперь, если бы я нанимал веб-разработчика внешнего интерфейса, я мог бы попросить его написать простую веб-страницу с кнопкой, заголовком и жирным шрифтом, просто чтобы посмотреть, знают ли они что-нибудь вообще. Но для этого не требуется никакой логики.
@Chan-HoSuh Исправлено, но это многое говорит о качестве инструкций, не так ли? Я прогнал его через нескольких человек и получил несколько интерпретаций.
Я в некоторой степени согласен с описанным здесь принципом (ручка и бумага не имеют ничего общего с IDE и не имеют ничего общего с тестируемой работой) и согласен с ним для проблемы любой значительной сложности. Но пример с FizzBuzz очень, очень, очень прост, а утверждение, что «старший разработчик, занимающий 15 минут, вполне разумно» — безумие.
@BittermanAndy Попробуйте сами, возьмите свой третий любимый язык и напишите его. Засеките время, убедитесь, что ваш синтаксис и отступы точны. Если вы допустили ошибку, начните сначала, но не перезапускайте таймер. Когда я попробовал это, мне потребовалось 12 минут, чтобы построить это неправильно после того, как я перечитал инструкции :(
@TrevorD Я спросил ОП, и он заявил, что кандидат даже не мог написать псевдокод. Другими словами, это не проблема синтаксиса. Я подозреваю, что кандидат обычно мог бы сделать это нормально, но у него просто «заморозили мозги», когда его поставили на место (если только он каким-то образом не является полным мошенником).
@DaveG Согласен, звучит подозрительно. Интервьюер должен быть в состоянии обнаружить полную блокировку и сказать разницу. Писать псевдокод несложно (на самом деле это не правила, поэтому все мы пишем на чем-то близком к первому языку, который выучили), так что нет причин даже не писать на бумаге.
Быть здесь педантом. «Вот требования как шаги» правильнее формулировать как «Вот конкретное решение, которое реализует требования». Существует несколько архитектур, которые могут реализовать требования, и ничто в требованиях не ограничивает, какую архитектуру следует использовать.
@PeterM Извините, что вы немного превзошли мой английский в этом, но если вы хотите предложить редактирование, я проверю его и одобрю.
Это не требование редактирования... скорее шутка/сарказм. С моей точки зрения, ваш список шагов - это не требования, а детали реализации, и может быть много способов реализовать одни и те же требования. Я пытался быть умным, указывая на это, но, очевидно, я был слишком умным для своего же блага.
Небрежно при моей первой попытке: для N = от 1 до 100 (если N равномерно div 15, то напечатайте FB, иначе если N равномерно div 3, напечатайте F, иначе если N равномерно div 5, напечатайте B, иначе напечатайте N). И это было красивее на моей бумаге, чем здесь.
@DarkMatter В моей голове я уже переделал это, беспокоясь о межстрочном интервале вывода. Вопрос, кажется, подразумевает, что он не хочет, чтобы слова объединялись в 1 длинную строку, потому что FizzBuzz происходит на 9 и 10, что не является требованием для FizzBuzz. Вам нужно вернуться назад и убедиться, что FizzBuzz никогда не появится случайно, если его число не кратно 3 и 5? И я застрял в интервью, пытаясь обдумать это
Поскольку это псевдокод, я просто предполагал, что «печать» означает «печать строки» при реализации.
@DarkMatter Если это не указано в требованиях, вы можете делать то, что хотите. У меня есть клиент, который собирается выстрелить себе в ногу из-за этого.
@TrevorD Для некоторых людей писать псевдокод очень сложно , тем более что это псевдокод! Они настроены на то, чтобы написать правильную программу без помощи своей IDE, что расстраивает, поскольку они понимают, что на самом деле не знают правильного синтаксиса. Это может сильно помочь, если вы избавите их от такого мышления, т.е. попросите их объяснить алгоритм, который они будут использовать для чего-то, чтобы они интуитивно не пытались написать синтаксически правильную программу. Это проще, если вы уже находитесь в абстрактном представлении задачи, например, в виде графа, где они могут обсудить алгоритмы графа на примере.
@Darkwing Это интересный момент, интересно, было бы полезно на собеседовании описывать логику кода устно, а не записывать?
@TrevorD Я чувствую, что многие, кто сталкивается с этой проблемой, с большей вероятностью перейдут на «абстрактный уровень» мышления, когда вы предоставите им бело-черную доску - даже лучше, если у нее уже есть небольшой пример, на котором они могут визуализировать свой алгоритм. . Я бы по-прежнему оставлял им свободу использовать бумагу или набрасывать конкретный алгоритм в псевдокоде на доске или на бумаге, но это дает им отправную точку. Однако, если вы смотрите на код, я считаю, что предоставление IDE или использование собственного ноутбука является лучшей альтернативой бумаге. Вообще я бы оставил выбор инструмента как можно более открытым.
@TrevorD Я думаю, что нет лучшего решения, подходящего для всех, поэтому я стараюсь оставлять выбор инструментов как можно более открытым и, возможно, предлагать тот или иной инструмент для разных задач, чтобы увидеть, могут ли они справиться со всеми или имеют определенные сильные стороны / сильные предпочтения с одним.
Возможно, стоит упомянуть, что единственная причина, по которой люди могут написать FizzBuzz за несколько минут, заключается в том, что они полностью усвоили , как именно это работает, и именно поэтому это такой плохой пример. FizzBuzz имеет больше общего с секретным рукопожатием, чем с вызовом программирования. Либо ты знаешь это наизусть, либо будешь выглядеть некомпетентным, потому что не можешь сделать это, не думая, как последние два парня.

Я написал свои первые программы в 1967 году, а в 1970 году получил работу программиста. Первые несколько лет своей карьеры я писал свои программы на листах кодирования.

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

  1. Запоминание внешних структур. В среде IDE вы можете настроить, например, если-то-иначе перед заполнением содержимого. На бумаге вам нужно запомнить, где вы были с каждой незавершенной структурой.
  2. Поиск вещей: IDE предлагают варианты и завершение слов, которые недоступны на бумаге. При программировании на бумаге мне нужны были под рукой справочные руководства для всего, что я не запомнил полностью. Если вам необходимо выполнить бумажные тесты по программированию, предоставьте соответствующие ссылки либо на компьютер, либо на мертвые деревья.
  3. Почерк. Я мог очень быстро создавать разборчивые прописные буквы, когда делал это весь день каждый день. Когда относительно недавно я столкнулся с некоторыми академическими экзаменами, которые нужно было сдавать на бумаге и карандаше, я подготовился, попрактиковавшись в письме, в том числе в написании математических обозначений. Прошло много лет с тех пор, как я много писала от руки.

Если вам действительно не нужна возможность программировать без IDE, вам следует настроить среду программирования для своих тестов.

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

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

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

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

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

Так что, если вас просят решить фундаментальную концептуальную проблему в информатике, не связанную с каким-либо конкретным языком или структурой, это не возможность «оценить, как вы думаете». что такое? :)
@Affe ммм ... Я не думаю, что мы на одной волне, потому что это не совсем то, о чем я пишу. Я имею в виду, что оценивается не то, как вы думаете, а ваши энциклопедические знания, которые в большинстве случаев и так ничего не доказывают.
Я извиняюсь, что мой триггер о людях, которые отвечают на каждый вопрос «Я бы просто погуглил», был направлен на вас ;). Мои стажеры — отличные гуглеры, если только они не хотят, чтобы зарплата стажера давала мне что-то. Я понимаю, что вы говорите о навыках решения проблем, а не о мелочах. Меня не волнует, является ли ответ «правильным» или «неправильным» на какой-либо конкретный вопрос, но в последние несколько лет собеседования стали разочаровывать, когда я не могу найти ни одной темы, на которую люди действительно могли бы поговорить об этом . не мелочи о том, какой фреймворк они использовали совсем недавно!
Есть статья о разработке, основанной на переполнении стека — dzone.com/articles/…
У меня есть ровно ОДИН большой вопрос в моем обычном наборе вопросов для собеседования, но за ним следует вопрос о том, как кандидат ожидает, что этот алгоритм будет работать на реальном современном процессоре ПК? То, что я ищу, - это некоторое понимание предсказания ветвлений, ужасной стоимости промахов кеша и подобных вещей. Понимает ли кандидат, что большое О — не единственное, что имеет значение. Страшно, как много кандидатов либо не могут ответить на первый бит, либо плохо понимают разницу между теорией CS и реальными машинами.

если он так хорош, как предполагает его рекомендательная рекомендация

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

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

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

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

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

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

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

Возможны две проблемы

  1. Кандидат на самом деле может обманывать.

  2. Кандидату потребуется больше времени для выполнения задания, чем обычно, а это значит, что он тратит свое время на чтение поста с заданной задачей.

Это сводится к тому, как вас ухаживали. В наши дни большое внимание уделялось алгоритмам, и нас учили писать алгоритмы на бумаге. До появления IDE нам приходилось писать код в блокноте, что делало наше владение синтаксисом намного сильнее, чем у тех, кто изучал IDE. Правильный синтаксис не очень важен, но если кандидат борется до такой степени, что не может ответить ни на один вопрос, на мой взгляд, кандидату нужно работать над основами программирования. Скорее всего, они будут бороться, и им потребуется гораздо больше времени, чтобы выполнить задание, чем обычно ожидается.

К тому времени, когда появился блокнот, были и IDE. Если вы не говорите о редакторе VI в UNIX. Кроме того, некоторые из нас используют графические интерфейсы раньше, но на клавиатуру все же легче положить что-то, чем на бумагу. Бумажные тесты устарели
Turbo Pascal был выпущен в 1983 году и представлял собой IDE. Не изменяя программы, вы можете написать программу, отредактировать ее, скомпилировать и запустить. Ее было намного проще использовать, чем другие системы разработки для домашних компьютеров. Где-то в то время существовала система, которая не позволяла вам написать синтаксически неверную программу на Паскале, но из-за которой ее было очень сложно использовать.
В моих двух степенях (ассоциированный и бакалавр) по разработке программного обеспечения у нас не было ни одного курса по алгоритмам. Многое было "встроено" в тему, но ни разу прямо не сказано, что мы сейчас изучаем алгоритмы. У нас никогда не было ничего похожего на изучение быстрой сортировки, создание b-деревьев или O-нотации и анализа. Все дело было в разработке решений различных проблем любым методом, который мы считали подходящим. В основном используют С.

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

Абсолютно возможно. Разные люди работают по-разному. Их мозг работает по-разному. А у некоторых просто проблемы с записью от руки.

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

Поэтому, если вы хотите наблюдать за людьми, вы наблюдаете за ними с помощью инструментов, к которым они привыкли, и там вы видите, насколько хорошо они могут работать. Если кто-то плохо пишет на бумаге и хорошо использует IDE, наймите его. Наоборот, не надо.

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

Вот несколько вариантов того, что вы можете сделать, если вы заинтересованы в этом кандидате:

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

  2. Пригласите кандидата вернуться и подчеркните, что он может использовать псевдокод; если они пишут «List.append» вместо «List.add» или даже «добавить X в список», это нормально. Опять же, в реальной ситуации на работе у них будет доступ к вещам, которые сделают это за них. Возможно, кандидат зациклен на вопросе «правильно ли я понял синтаксис?» и не может дать вам то, что вы на самом деле хотите. Если вы скажете, что синтаксис не имеет значения, вы можете получить то, что хотите.

  3. Задавайте наводящие вопросы. «Напишите FizzBuzz» на самом деле мало что вам говорит; это просто говорит вам, запомнил ли он решение FizzBuzz. «Объясните мне, как бы вы написали программу для выполнения X» говорит вам гораздо больше. В частности, он говорит вам, обладает ли этот человек умственными способностями для разработки решения проблемы, которое он, возможно, видел или не видел раньше. Если они даже не могут сказать вам простыми словами (а «сказать» — это рабочее слово, это должно быть словесным упражнением, чтобы избежать таких проблем, как дисграфия или дислексия), каков первый шаг к решению проблемы, это красный флаг, который вы ищете, чтобы отправить их домой.

У него могла быть ДИЗГРАФИЯ, как у меня. Или аутизм, или что-то еще, что может вызвать проблемы с записью.

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

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

Я чувствую, что все стало проще, потому что то, что COBOL сделал с синтаксисом, обрабатывается библиотечными вызовами в современных языках.

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

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

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

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

Подумайте о том, что вам действительно нужно, и примите соответствующее решение.

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

Вероятно, произошло две вещи:

  1. Он погуглил ответ. Вероятно, взял это сразу из stackoverflow. Я забыл, кто написал статью, но я помню, как один человек упомянул, что чем сложнее/умнее их FizzBuzz, тем больше вероятность того, что вы поймете, что они искали ответ в Google, а не думали об этом с макушки головы. Предполагается, что людям, которые разбираются в программировании, не нужно будет искать что-то столь же простое, как FizzBuzz, и они получат самый простой ответ.
  2. В среде IDE он думает лучше, чем с ручкой и бумагой. Он также мог полагаться на функции автоматического завершения или поиска в среде IDE, подобные тем, что имеются в phpStorm или msdn, интегрированных в Visual Studio.

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

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

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

Какого программиста вы бы хотели, того, кто умеет хорошо программировать, или того, кто может хорошо говорить о кодировании?

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

К тому же тесты тупые. FizzBuzz тупой. Дайте мне задание, которое я могу выполнить в IDE, например, как бы я работал, если бы работал... и на самом деле не имеет значения, как я это сделаю, если я верну его вам, и это то, что вы хотите. Я могу использовать google, переполнение стека, угол C # ... какое это имеет значение? Непрограммист не может программировать, глядя на переполнение стека. Непрограммист даже не знает, какие вопросы нужно задавать, чтобы получить ответы, которые он ищет.

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

Могу я спросить, какую работу по программированию вы занимали? Мой опыт показывает, что если вы работаете в команде над сложным проектом, вам необходимо уметь кодировать и объяснять, что делает ваш код, вашим товарищам по команде.
@CharlesE.Grant Я не говорил, что не могу объяснить, что делает мой код. Я имею в виду, что я не могу объяснить концепцию ООП так, чтобы это звучало правильно. Или что такое полиморфизм. И если вам нужно объяснить кому-то, что делает ваш код, значит, вы написали его неправильно и/или другие программисты не умеют читать. Хороший программист должен уметь смотреть на хороший код и понимать, что он делает.
Хотя как программист я согласен с вашим ответом. Ответ очень негативный, как будто вы выражаете свое разочарование в ответе.
Вам нужны люди, которые хорошо умеют программировать и могут говорить о кодировании, если только вы не нанимаете одного человека и не собираетесь нанимать другого. Тот, кто не может выразить основные понятия, гораздо менее полезен, чем тот, кто может. Также полезны такие тесты, как FizzBuzz, как быстрый способ отсеять совершенно неподходящие.
Я согласен с тем, что нельзя ожидать, что программисты будут помнить каждый метод каждого класса в каждой библиотеке, которую они используют. Но вам не нужны никакие библиотеки для написания FizzBuzz. Вам нужно написать цикл for и использовать оператор mod. FizzBuzz может быть глупым, но если вы не можете написать цикл for в уме, то вы не программист.
@Dan Как я уже сказал, быстрый способ отсеять совершенно неподходящие. В зависимости от качества заявителей, это может быть полезно.

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

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

Дайте ему еще несколько тестов, но на этот раз используйте доску, чтобы она не сильно отличалась от IDE. Если он все еще не может этого сделать, откажитесь от него.

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

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

есть шанс, что он умный программист :)

https://www.hanselman.com/blog/AmIReallyADeveloperOrJustAGoodGoogler.aspx