Хитрые логические головоломки - действительно ли они полезны при оценке навыков программирования? [закрыто]

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

Интервьюер был немного разочарован и сказал, что программист должен обладать «этими» навыками. Я не понял, о каких навыках он говорил.

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

Некоторые люди спрашивают их, пытаясь оценить ваши способности и подход к решению проблем. Лично я не думаю, что такие загадки дают точный показатель. В «реальном мире», то есть более чем на пять минут , чтобы выяснить , если ваше дело с бен упаковкой против в рюкзак проблемы, например. Изначально иногда легко понять проблему под рукой, пока вы не в середине применения неправильного решения. Это происходит с людьми с 1, 5, 10 или даже 20-летним опытом.

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

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

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

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

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

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

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

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

Через некоторое время после написания этого ответа я прочитал «Компьютерные мальчики захватывают власть» , историю институциональных вычислений в 1950-х и 1960-х годах. По-видимому, практика просить дразнилки и загадки кандидатов на рабочие места в программировании восходит к 1950-м годам. США пытались компьютеризировать свою систему противовоздушной обороны, и IBM подсчитала, что им потребуется несколько тысяч программистов для выполнения этой работы. Ответ был шоком и ужасом: во всем мире было всего пара десятков «профессиональных программистов». Было опробовано несколько подходов: тесты на способности к абстрактному программированию, набор математиков в качестве программистов, набор шахматистов и решателей кроссвордов, а также проверка кандидатов с помощью загадок и головоломок.

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

Они полезны? Нет, не совсем. Когда - то они были настолько распространены в Microsoft они даже получили под названием «Microsoft вопросы», и там были книги , написанные о них, это один на самом деле очень хорошо читать ..

Есть 2 проблемы с ними. Во-первых, если кандидат проводит исследование (и читает книгу), он все равно узнает их, а во-вторых, даже если они могут решить их, как это показывает, что он будет хорошим разработчиком / тестом / PM.

По этим причинам их редко спрашивают в Microsoft. Гораздо лучше задавать вопросы кодирования или решения проблем, которые не требуют «хитрого» ответа. Другими словами, вам нужно задавать вопросы, которые позволят вам изучить навыки и поведение заявителя, когда он пытается решить проблему - как интервьюер, я хочу, чтобы они задавали вопросы, находили решения и затем возвращались, когда выясняют проблема, может быть, даже не найти решение за то время, которое у них есть, но, по крайней мере, сделать это разумным способом. Это отражает работу в реальной жизни. Мне никогда не приходилось измерять 3 пинты, используя 2 ведра и курицу (или какой-то другой вопрос).

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

Возможно, вы захотите прочитать книгу « Как бы вы подвезли гору Фудзи»? , Это объясняется тем, что многие люди используют загадки в интервью, и я считаю, что это сочетание поведения культового груза ( «Microsoft делает это, и если мы хотим быть такими же успешными, как они, то нам лучше делать то, что они do " ) и дедовщина ( " черт возьми! Я должен был ответить на эти вопросы, и вам лучше поверить, что следующий парень должен будет ответить на них! " ).

История этих вопросов как практики интервьюирования началась с Уильяма Шокли в 1950-х годах. Это был довольно распространенный вопрос об интервью в Силиконовой долине, который интервьюеры задавали, потому что другие интервьюеры делали это (и, возможно, они знали то, чего не знал этот интервьюер?). Шокли задумал их как тест на интеллект, и вопрос с двумя ведрами был на одном из оригинальных тестов IQ Стэнфорда Бине еще в 1916 году.

Вполне возможно, что люди, проводящие собеседование, на самом деле хотят видеть, как вы ищите ответы, поэтому они не смогут вычислить такие вопросы, как, например, количество бензонасосов в вашем городе. Такого рода проблемы являются проблемами Ферми . Два интересных поста в блоге от Джеффа на эту тему: «Самый сложный вопрос для интервью» и « Насколько вы хороши оценщиком?». Часть III .

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

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

В первом хорошем интервью, которое я помню, мы много разговаривали, не спеша. Сначала поговорим по телефону об объектно-ориентированном дизайне и о плюсах и минусах его реализации в C ++. Затем на месте я поговорил с несколькими людьми об их методах разработки программного обеспечения, интеграции, тестировании, управлении версиями и управлении конфигурацией, о командах и обязанностях, о технологиях и о дизайне. Это было интервью на целый день, которое включало в себя обед с людьми, которые брали у меня интервью. Оглядываясь назад, это было все о том, буду ли я продуктивно вписываться в то, что они уже делали.

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

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

1. Какие у вас предпочтения в языке программирования? Почему?
2. Как подойти к обработке исключений?
3. Разве преимущества многослойного дизайна не являются мифом?
4. Не является ли непрерывная интеграция бременем для эффективности?
5. Кто бы ни написал кусок кода, он должен принадлежать ему, верно?
6. Что вы делаете, чтобы попасть в «поток».
7. Как сообщить о выявленных дефектах в план проекта?
8. ...

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

Более научные исследования об эффективной разработке программного обеспечения со времен Peopleware говорят, что лучшие программисты - это те, кто понимает динамику разработки программного обеспечения, даже если у них нет самых высоких IQ. Я предпочел бы взять новичка, который хочет учиться, чем кого-то с nмноголетним опытом, который сводится к 1годам опыта многократно n. Мое личное предубеждение относится к кандидатам, которые склонны мыслить нестандартно и в то же время знать, как вписаться в нынешнюю (мою) рамку.

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

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

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

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

Это старая логика, что вы должны иметь базовые логические навыки; чему-нибудь еще можно научить. Но это не совсем так. Чтение логической логики , условий и циклов - это не то же самое, что умение разгадывать логическую головоломку .

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

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

Отказ от ответственности: я очень хорошо разбираюсь в логических головоломках и, вероятно, не смог бы начать свою работу в этой области без этого логического обоснования.

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

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

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

Бывает, что для программистов решение принимает форму программы.

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

При этом я не уверен, что решение сложной головоломки - лучший способ оценить кого-либо.

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

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

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

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

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

Два момента:

1. Программирование в основном отличается от решения головоломок. Это правильно объяснил Стив Макконнелл в «Code Complete»:

   Какая? Вам не нужно быть суперинтеллектом? Нет, ты не Никто не достаточно умён, чтобы программировать компьютеры. Полное понимание средней программы требует практически безграничной способности воспринимать детали и равной способности понимать их все одновременно. То, как вы концентрируете свой интеллект, важнее, чем ваш интеллект. Как упоминалось в главе 5, на лекции Тьюринга в 1972 году Эдсгер Дейкстра выступил с докладом «Скромный программист». Он утверждал, что большая часть программирования - это попытка компенсировать строго ограниченный размер наших черепов. Люди, которые лучше всех умеют программировать, это люди, которые понимают, насколько у них маленький мозг. Они скромны. Наихудшие в программировании люди - это люди, которые отказываются признать тот факт, что их мозг не равен задаче. Их эго мешают им быть великими программистами. Чем больше тынаучись компенсировать свой маленький мозг, тем лучше будешь программистом . Чем скромнее ты, тем быстрее ты станешь лучше.

2. Такие загадки могут быть полезны во время интервью, но только если интервьюер смотрит на процесс , а не на сам результат.

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

Есть несколько способов исследовать такие проблемы:

1. Зная предыдущее решение. В фильме ... Крепкий орешек с местью ... объясни мне это ...? быть примером знания решения для случая, когда бла - 4,3 и 5 соответственно. Некоторые люди смогут быстро использовать свои внутренние знания прошлого решения и адаптировать его при необходимости. Как правило, это то, чего я ожидаю от интервьюера, что может быть хорошей идеей, а может и не быть.

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

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

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

OTOH, я думаю, что проблемы программирования более полезны.

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

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

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

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

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