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

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

Інтерв'юер був трохи розчарований і сказав, що програміст повинен мати "ці" навички. Я не здобув, про які навички він говорив.

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

Деякі люди запитують їх у спробі оцінити вашу здатність та підхід до вирішення проблем. Особисто я не думаю, що такі головоломки є точним показником. У "реальному світі" у вас є більше п'яти хвилин, щоб розібратися, чи стосуєтеся ви, наприклад, проблеми з упаковкою сміття проти проблеми із заднім пакетом . Спочатку іноді легко зрозуміти проблему, що виникає, поки ви не вживаєте неправильного рішення. Це трапляється з людьми, які мають досвід 1, 5, 10 чи навіть 20 років.

Найкращі "пазли" для інтерв'ю - це те, коли ви сідаєте за комп'ютер, щоб вирішити проблему в тій області, в якій ви вимагаєте досвід. Мені також не подобається думка "Ну, програміст повинен вміти ...", оскільки він не враховує, що люди занепокоєні, коли потрапляють у щось несподіване в обстановці, яка вже є стресом. Звичайно, ви могли б це вирішити, якби встигли подумати над цим .. і, можливо, ви могли б вирішити це швидше, якби зрозуміли, що ваше життя закінчиться, якщо ви цього не зробите. Ви хочете працювати десь, де закінчиться ваше життя, якщо ви не зможете вирішити проблеми за п’ять хвилин ? Чи звільнять вас, якщо не зможете ?

Чи повинні всі великі програмісти також бути чемпіонами з вирішення судоку? Я впевнений, що вдосталь є, але це не як якась передумова компетентності.

Я не кажу, що ви не повинні проходити тестування на те, як ви підходите до проблем, але тести повинні бути веселими та запрошувати "найкраще", яке має дати заявник, враховуючи сферу своєї компетенції. Доведення того, що ти такий розумний, як персонаж, якого зображує Брюс Вілліс, здається безглуздим, враховуючи, що продюсери витратили неабияку суму, щоб вийти на цю сцену як раз .

Іншими словами, якщо ви виявите, що вас беруть інтерв'ю у когось, хто мало розуміє, що ви насправді робите , вибачте себе піти в туалет і ніколи не повертатися.

Microsoft почала використовувати ці питання на початку 1980-х. Оскільки Microsoft набув значних успіхів, інші компанії почали їх копіювати, але пара ключових моментів втратилася в перекладі.

У той час Microsoft намагалася заповнити багато технічних, але не програмуючих посад: технічних письменників, тестерів, підтримки телефону тощо. Це не були звичайними робочими місцями в той час, і людям з фактичним досвідом роботи в цих областях було важко знайти. В якості альтернативи Microsoft вважала, що вони можуть найняти дійсно розумних, розумних, гнучких людей та навчити їх працювати. Оскільки ці люди не мали досвіду програмування, задавати їм питання програмування в інтерв'ю було безглуздо. Загадки були обрані для випробувальних та розумних людей, які були розумні та мали надзвичайно хороші аналітичні навички. Програмістам, як правило, задаються проблеми програмування білої дошки, хоча вони також можуть задавати загадки під час обіду або вечері.

Ці питання ніколи не мали на увазі невдачі. Вони повинні були стати початком розмови про те, як ти вирішиш проблему та як ти думаєш про проблеми, яких ти ніколи не бачив. Єдиний вірний спосіб «провалитись» - це відмовитись від спроби вирішити проблему. У той час це була нова стратегія, і ви не могли просто шукати питання в Google.

Редагувати:

Колись після написання цієї відповіді я прочитав "Computer Boys Take Over" - історію інституційних обчислень у 1950-х та 1960-х роках. Мабуть, практика задавати задачі на мозок та загадки кандидатів на роботу з програмування сягає аж до 1950-х років. США намагалися комп’ютеризувати свою систему протиповітряної оборони, і IBM підрахувала, що для роботи їм буде потрібно кілька тисяч програмістів. Відповідь була шоком і побоюванням: у всьому світі було лише пару десятків "професійних програмістів". Було випробувано декілька підходів: тести на здатність до абстрактного програмування, набір математиків як програмістів, набір шахістів та вирішення кросвордів, а також пошук скриньки із загадками та тизерами для мозку.

Зрештою, їм вдалося набрати достатню кількість програмістів для завершення проекту, але висновок полягав у тому, що жоден із методів скринінгу не був кращим, ніж шанс виявити новобранців, які стали успішними як програмісти.

Чи корисні вони? Ні, не дуже. Колись вони були настільки поширеними в Microsoft, що їх навіть називали "питаннями Microsoft", і про них написано книги, ця насправді досить добре прочитана.

З ними є 2 проблеми. По-перше, якщо заявник зробить дослідження (і прочитає книгу), він все одно їх знатиме, по-друге, навіть якщо зможе вирішити їх, як це покаже, що це буде хороший розробник / тест / ПМ.

З цих причин їх рідко запитують у Microsoft. Набагато краще задати питання кодування або вирішити проблеми, на які не потрібна відповідь "хитрощі". Іншими словами, вам потрібно задавати питання, які дозволяють вивчити навички та поведінку заявника, коли він намагається вирішити цю проблему - як інтерв'ю, я хочу, щоб вони задавали питання, придумували рішення та потім відстежували, коли вони з'ясують проблема, можливо, навіть не знайти рішення за час, який у них є, але, принаймні, зробити це розумним шляхом. Це відображає реальну роботу. Мені ніколи не доводилося міряти 3 пінти, використовуючи 2 відра і курку (або як би там не було).

Це сказав, що мені було задано кілька хитромудрих питань у свій час, і я зараз вважаю себе експертом з транспортування курей і лисиць на маленьких човнах і підрахунку тривалості життя мухи, яка живе в поїзді. Мені ніколи не доводилося користуватися цією інформацією, але хто знає, можливо, одного разу….

Ви можете прочитати книгу Як би ви рухалися на гору Фудзі? . Це входить в міркування, що багато людей використовують загадки під час інтерв'ю, і я вважаю, що це поєднання культової поведінки ( "Microsoft це робить, і якщо ми хочемо бути настільки ж успішними, як вони є, тоді нам краще робити те, що вони робити " ) та братовбивства ( " до боже!! Я повинен був відповісти на ці питання, і ви краще повірте, що наступний хлопець повинен буде відповісти на них! " ).

Історія цих питань як практика інтерв'ю почалася з Вільяма Шоклі в 1950-х роках. Вони були досить розповсюдженим питанням для інтерв'ю у Силіконовій долині, які задавали інтерв'юери, оскільки це робили інші інтерв'юери (а може, вони знали щось таке, чого цей інтерв'юер не знав?). Шоклі задумав їх як тест інтелекту, і питання з двома відрами було на одному з оригінальних тестів IQ Stanford Binet IQ ще в 1916 році.

Цілком можливо, люди, які проводять співбесіду, насправді хочуть побачити, як ви шукаєте відповіді, тому вони не можуть поставити підрахунок питань, наприклад, скільки газових насосів у вашому місті. Такі проблеми - проблеми Фермі . Два цікавих повідомлень в блозі від Джеффа на цю тему The Hardest Інтерв'ю Головоломка Питання Ever і наскільки добре оцінювач Ви? Частина ІІІ .

Особисто я маю низьку думку щодо таких питань, оскільки вони, як правило, використовуються інтерв'юерами, які не знають, чим займаються, і як шукати розробників. Якщо ви не збираєтесь працювати в компанії, яка створює загадки / загадки, вони належать до кошика історії разом із тим, "яка ваша найбільша слабкість" (відповідайте на це правдою, і ви закінчуєте своє інтерв'ю погано) або "чому є кришками люків круглими "(не всі вони є).

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

У першому хорошому інтерв'ю, який я пам’ятаю, ми багато говорили, не поспішаючи. По-перше, протягом години, по телефону, про об’єктно-орієнтований дизайн та плюси та мінуси його впровадження в C ++. Потім, на місці, я поговорив з кількома людьми про їхні розробки програмного забезпечення, інтеграції, тестування, контролю версій та управління конфігурацією, про команди та обов'язки, про технології та про дизайн. Це було цілоденне інтерв'ю, яке включало обід з людьми, які опитали мене. Заздалегідь було зрозуміло, чи я б продуктивно вписався в те, що вони вже робили.

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

Якби я сьогодні взяв інтерв'ю з кимось для роботи з програмування, я би продовжував подобатися. Я хотів би попросити думки щодо широких тем і залишити осторонь:

1. Які ваші переваги мови програмування? Чому?
2. Як підійти до обробки винятків?
3. Хіба не про міф багатошарового дизайну?
4. Чи не безперервна інтеграція є тягарем для ефективності?
5. Хто б не написав фрагмент коду, він повинен володіти ним, правда?
6. Що ви робите, щоб потрапити в "потік".
7. Як слід повідомити про дефекти, включені до плану проекту?
8. ...

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

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

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

Як інтерв'юер багатьох людей протягом багатьох років, я зазвичай не задаю питання типу типу готчі, як такого, яке ви, схоже, описуєте, але я можу щось задати і запитати "як би ви вирішили ...".

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

Це просто практики найму вуду. Інші люди задають ці питання, щоб вони відчували себе так, як їм належить. Вони знають, що не відповісти на питання - це погано, а відповісти - «добре», але вони не можуть сказати, чому поза невідповідями на кшталт «розробнику потрібні ці навички». Вони марно витрачають час і є показником того, що інтерв'юер не є компетентним інтерв'юером.

Це раціональний старий радок, який повинен мати базові логічні навички; будь-що ще можна навчити. Але це не зовсім вірно. Читання булевої логіки , умов та циклів - це не те саме, що вміти розгадувати логічну загадку .

Це говорило, що в часи процедурних мов, ймовірно, було правдою, що хтось, хто міг би вирішити ці проблеми, матиме більшу схильність до можливості застосувати будь-яку проблему з точки зору комутаторів. Але на мій погляд, OO / функціональне програмування вимагає інженерного мислення, яке є зовсім іншим (хоча і не суперечливим).

Особисто я не впевнений, що хотів би працювати в компанії, яка досі вважала, що логіка важливіша, ніж практичні навички програмування.

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

Інтерв'юер, мабуть, мав на увазі розв’язання проблем та логічні навички, що є частиною повсякденної роботи програміста. Коли вам задана проблема, вам потрібно вміти її аналізувати, підрозділяти та писати рішення для неї, використовуючи найоптимальніший підхід.

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

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

Буває, що для програмістів рішення набуває форми програми.

Тож саме тому важливо мати можливості вирішення проблем і чому це тестується.

Попри це, я не впевнений, що розв язання хитрої головоломки - найкращий спосіб оцінити когось.

Головоломки в інтерв'ю поділяються на дві категорії: "логічні головоломки" (на зразок тієї, про яку вас попросили) та категорію "думайте інакше". Категорія думок по-різному (я не впевнений, що їх ще називають бічними головоломками?) Зазвичай такого типу: Скільки листя у цього дерева? або Скільки кравців присутні у вашому місті?

Мені добре «Логічні головоломки», оскільки вони мають одне чи, можливо, два рішення, і до них можна дійти простою логікою. І я вважаю, що логічні головоломки в тій чи іншій мірі хороші, оскільки процес, необхідний для їх вирішення, - це те, як потрібно кодеру думати в реальному житті.

Помилка "думай по-іншому" мене не закінчує, тому що вони змушують тебе робити припущення, а потім робити деякі розрахунки на основі припущень. Простіше кажучи, якщо ваш інтерв'юер погоджується з вашою логікою, але не з вашими припущеннями, або навпаки, ви програли. Інтерв'юер має занадто багато місця, щоб не погодитися з вашим рішенням.

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

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

Два бали:

1. Програмування в основному відрізняється від розгадування головоломок. Це досконало пояснює Стів МакКоннелл у "Кодексі завершено":

   Що? Вам не потрібно бути суперінтелектуальним? Ні, ви цього не робите. Ніхто не є досить розумним для програмування комп'ютерів. Для повного розуміння середньої програми потрібна майже необмежена здатність засвоювати деталі і однакова здатність осягати їх все одночасно. Те, як ви зосереджуєте свій інтелект, важливіше, ніж наскільки ви маєте інтелект. Як уже згадувалося у розділі 5, на лекції з нагороди Тюрінга 1972 року Едсгер Дайкстра виступив із документом під назвою «Покірний програміст». Він стверджував, що більшість програм є спробою компенсувати суворо обмежений розмір наших черепів. Люди, які найкраще програмують, - це люди, які усвідомлюють, наскільки малий їхній мозок. Вони смиренні. Люди, які найгірше програмують, - це люди, які відмовляються сприймати той факт, що їхній мозок не дорівнює завданню. Їхні егої не дають їм бути великими програмістами. Тим більше тинавчитися компенсувати свій маленький мозок, тим краще програміст ти будеш . Чим ти скромніший, тим швидше ти вдосконалишся.

2. Такі головоломки можуть бути корисними під час інтерв'ю, але лише якщо інтерв'юер дивиться на Процес , не давати результату.

Але в ідеалі головоломки повинні бути більш складними та пов'язаними з програмуванням (як маленький 2-годинний проект), на мою думку. Вся справа в тому, що інтерв'юери - це люди, які не мають ідеальних "навичок інтерв'ю".

Існує кілька різних способів вивчення таких проблем:

1. Знання попереднього рішення. У фільмі ... Вмирай важко з помстою ... поясни мені це ...? є прикладом знання рішення для випадку, коли благи 4,3 та 5 відповідно. Деякі люди зможуть швидко використати свої внутрішні знання про минуле рішення та при необхідності адаптувати його. Зазвичай, я вважаю, що очікував інтерв'юер, який може бути, а може і не бути хорошою ідеєю.

2. Навички творчої імпровізації. Це було б у випадку, якщо ви не знаєте попереднього рішення або навіть визнаєте проблему такою, що можна було б змалювати як діофантинове рівняння. Таким чином, питання полягає в тому, як швидко ви можете використати те, що дано, і знайти творче рішення проблеми творчо, разом з поясненням того, що у вас є правильним рішенням проблеми.

Будь-яке може бути задовільним чином, але в кожному випадку є також трохи перевірки комунікативних навичок, оскільки можна також спробувати відповісти: "Чи справді це стосується позиції, на яку я застосування? Коли останні навички використовувались? " це може призвести до цікавого діалогу, якщо інтерв'юер розкриється про те, що саме вони хочуть бачити, що, можливо, альтернативний підхід тут може бути сприйнятий як більш ефективний.

Це не особливо хитра проблема. Потрібно лише три кроки, і на кожному кроці є лише два варіанти. Я був би здивований, якби хтось із моїх колег не зміг вирішити це в дуже короткому порядку. Ми не представляємо подібних проблем в інтерв'ю, але я думаю, що розумно задавати такі питання. Вони, безумовно, корисніші, ніж детальні запитання про синтаксис чи бібліотеки.

ОТО, я думаю, що проблеми програмування корисніші.

Ви повинні пам’ятати, що немає можливості з абсолютною впевненістю знати, що хтось буде добрий у роботі. Особливо це робота з КС, оскільки багатьох проблем, які можуть мати цю роботу в магазині, неможливо передбачити.

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

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

Пам'ятайте, що це гра в здогадки, і реальність полягає в тому, що всі речі, рівні будь-кому з нас, швидше найнять когось, хто зможе вирішити ці головоломки, ніж того, хто не може.

Так, ви можете вивчити головоломки для інтерв'ю, але я думаю, ви потрапите у спалення, якщо подана головоломка не відповідає тій, яку ви вивчаєте ... і до тих пір, поки ви не запам’ятаєте загадки та їх рішення, можливо, вивчайте загадки самі зроблять вас розумнішою людиною по-справжньому, як і будь-яка реальна освіта.