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

88

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

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

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

пропавших без вести
источник
20
выглядит как головоломка Die Hard 3 кувшин youtube.com/watch?v=lZ64IR2bz5o
JF Dion
64
Одна большая проблема с такими вопросами заключается в том, что они часто измеряют, видел ли заявитель эту проблему раньше и «видел много логических головоломок», что не является действительно хорошим критерием найма.
Дэвид Торнли
37
Это просто практика найма вуду. Другие люди задают эти вопросы, чтобы они чувствовали, что они должны. Они знают, что не отвечать на вопрос «плохо», а отвечать «хорошо», но они не могут сказать вам, почему, помимо отсутствия ответов, таких как «разработчик нуждается в этих навыках». Это пустая трата времени и показатель того, что интервьюер не является компетентным интервьюером.
Рейн Хенрикс
5
Да, эти тесты не так хороши. Но приятно, когда программист хотя бы немного интересуется этими головоломками. Мой совет: просто изучите головоломки, пройдите собеседование и решите, хотите ли вы присоединиться.
Работа
10
Я хотел бы спросить об этом во время интервью в надежде найти кандидата, который спрашивает: «WTF, это имеет отношение к программированию?» и сделайте им предложение, прежде чем они выйдут с парковки.
JeffO

Ответы:

97

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

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

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

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

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

Тим Пост
источник
8
Это точка зрения, которую должны иметь все интервьюеры. Решите проблему в своем домене, и ваши замечания о стрессе и неожиданных вопросах на высоте!
Крис
20
+1 за В «реальном мире» у вас есть больше пяти минут, чтобы выяснить , хороший ответ!
Муравей
7
также нравится тот факт, что они обычно представляются так, как будто интервьюер создал вопрос и решил его самостоятельно :)
RyBolt
10
Я бы так усердно excuse yourself to go to the restroom and never return!
Флориан Маргэйн
Да, я всегда стараюсь сделать так, чтобы соискатель чувствовал себя максимально комфортно, поэтому я могу попытаться выяснить, насколько хорош этот человек для работы. Запрашиваемая «ваши сильные стороны» вместо «что вам нравится?» и глупые головоломки вместо кодирования философии не дадут мне никаких указаний на то, насколько хорош этот человек для этой работы.
winkbrace
56

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

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

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

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

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

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

Чарльз Э. Грант
источник
49

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

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

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

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

Стив Хей
источник
26

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

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

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

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

оборота тангурена
источник
3
+1, не могу больше согласиться с последним абзацем!
фактор
+1 для ссылки на проблему Ферми: интересно посмотреть, сможет ли кто-то сделать оценки с разумными границами ошибок. С таким же успехом вы могли бы попросить о доверительном интервале в отношении того, «сколько там стран?». Тем не менее, я думаю, что знание о том, как мыслить таким образом, хотя и достойно восхищения и пользы, на самом деле не является необходимым для развития. Это как разработчик, знающий исчисление или статистику: это хорошо, но больше говорит об их прошлом, чем о том, будут ли они хороши на работе.
пул
17

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

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

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

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

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

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

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

Апалала
источник
Отличный ответ. Оффтоп: Ваш пример вопроса № 3 вызывает у меня любопытство. Мне интересно узнать больше о вашем мнении о многослойном дизайне.
фактор
2
@missingfaktor # 3, как уже говорилось, это вопрос с подвохом, чтобы зажечь разговор о том, что сделано быстро, а что нет. № 4 и № 5 одинаковы. № 7, вероятно, самая сложная и только подходящая для лидерских ролей.
Апалала
1
@missingfaktor Я снова дал ответ на другой вопрос. Эта статья в Википедии, связанные с ней ссылки и внешние ссылки предоставляют обширную информацию о том, почему разделение интересов имеет первостепенное значение для проектирования и построения сложной системы: en.wikipedia.org/wiki/Modularity
Apalala,
Имеет смысл. Большое спасибо! :-) Опять отличный ответ. Делает много хороших моментов, не упомянутых в других ответах здесь.
фактор
Лично я бы также добавил вопрос об инструментах. Люди, которым небезразличны используемые ими инструменты, как правило, становятся лучшими программистами. Как пользователь Emacs, я предпочитаю пользователя vim тому, кто просто пожимает плечами и ему все равно.
Синглтон
13

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

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

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

SDG
источник
1
Я сделал то же самое, когда брал интервью у бесчисленных людей. Суть вопроса в том, чтобы посмотреть, как они работают над решением, не обязательно, если они получат правильный ответ. Вы можете довольно быстро найти хороших программистов, просто наблюдая за этим процессом.
Дейв Уайз
2
@ Дэйв, попробуй меня. Когда я решаю такие загадки, я обычно беру лист бумаги, рисую графики или таблицы, или вычеркиваю фигуры, представляющие актеров, или пишу числа, которые каким-то образом связаны с процессом решения проблемы в моем уме; Я делаю все это в полной тишине, иногда нарушаемой неразличимым ропотом. Итак, я хороший программист?
П Швед
4
Гейзенберг не одобрил бы. Человек может быть в состоянии придумать хорошее решение проблемы, но не сможет рассказать о внутреннем процессе, который он использовал. Попросив их сделать это, они не только проверяют свои способности в обстоятельствах, при которых они обычно не работают, но и оказываются предвзятыми из-за их способности или неспособности объяснить другому человеку, как работает их мыслительный процесс. Они могут даже не осознавать, как это работает.
Джейсон
4
Некоторые люди считают, что только потому, что они экстраверты, каждый должен быть экстравертом. Моя нынешняя команда - группа интровертов, и это, безусловно, лучшая команда, с которой я когда-либо имел удовольствие работать.
Данк
2
@ Чарльз То, что я говорил, - это то, что людям, заинтересованным в общении, как правило, нужно продумать проблему, прежде чем они смогут найти решение, которое удовлетворит их, и затем они смогут объяснить другим. Это сильно отличается от «Невозможно общаться». Экстраверты, как правило, должны говорить о своем решении проблем. Оригинальный плакат явно ожидает экстравертный стиль для решения проблем.
Данк
8

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

Рейн Хенрикс
источник
5

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

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

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

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

прецизионный самописец
источник
2

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

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

Стивен Джеурис
источник
1

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

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

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

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

Ксавье Т.
источник
1

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

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

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

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

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

DPD
источник
Под палиндромами вы имеете в виду очень сложную проблему поиска самой длинной подстроки палиндрома во входной строке за линейное время? :-)
b_jonas
1

Два момента:

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

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

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

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

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

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

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

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

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

JB King
источник
0

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

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

Кевин Клайн
источник
0

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

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

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

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

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

8steve8
источник
3
Я не знаю о вас, но во время интервью я предпочитаю описать реальную сложную проблему, которая недавно возникла в мире нашей компании, и посмотреть, как собеседник подойдет к ней. Как ни странно, в последнее время мы не привлекали клиентов для измерения количества воды, используя два ведра. В основном мы занимаемся компьютерным программированием.
Carson63000
@ Carson63000 не то, чтобы настоящая проблема, с которой столкнулась ваша компания, была бы плохой идеей, но часто из-за недостатка времени из-за специфики реальной проблемы и реализации решения. Вот почему загадки с ведрами великолепны, потому что стоимость входа очень мала и сразу приводит к интересным деталям.
8steve8
Я предполагаю, что вы можете увидеть аналогию между проблемой корзины и, скажем, написанием программного обеспечения для выполнения задачи при использовании минимального числа обращений к диску или http-запросов.
8steve8