Чи погана практика інтерв'ю, щоб кандидати писали реалізацію зв'язаного списку? [зачинено]

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

Однак я не можу не стверджувати, що це може бути поганою практикою з наступних причин:

• Сучасні мови вищого рівня, такі як C # та Python, в основному широко використовують списки; писати власний об’єкт списку потрібно лише за незвичних обставин, і навіть тоді, ймовірно, необдуманих.
• Мови нижчого рівня, такі як C ++, мають стандартні бібліотеки з ітераторами / контейнерами списку та об'єктами.
• З огляду на перші два пункти, кодери можуть пройти роки, навіть не замислюючись про те, щоб реалізувати список (зв'язаний, подвійний зв’язок тощо). Деякі люди навіть не дуже бачать таких речей ще з коледжів.
• Обчислювальна потужність також не є тим фактором, який був років тому, тому ефективність за допомогою покажчиків - це не проблема, якою вона була раніше (загалом).
• Простий пошук в Інтернеті на кшталт "прикладу зв'язаного списку" може принести безліч прикладів коду, які можна було просто запам'ятати і виплюнути назад, а не справді вказувати на справжню компетентність заявника.

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

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

EDIT : Є багато (хороших) коментарів, які дозволяють стверджувати, що це хороший чи поганий питання, що задається, залежить від контексту роботи. Я повністю погоджуюся, тому дозвольте перефразувати це запитання: Реалізація зв'язаного списку - це поширене питання інтерв'ю для широкого кола завдань кодування, подібне до таких питань, як FizzBuzz, або написання рекурсивної функції для обчислення факторіалів. Чи є в цьому питанні достатня корисність, щоб звичайно його використовувати для оцінювання кандидатів на програмування у всій раді? Або варто вважати поганим питанням, окрім посади "Старший розробник, вбудована група пов'язаних списків"?

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

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

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

Щодо вашої редакції:

Чи є в цьому питанні достатня корисність, щоб звичайно його використовувати для оцінювання кандидатів на програмування на всій посаді? Або варто вважати поганим питанням, окрім посади "Старший розробник, вбудована група пов'язаних списків"?

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

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

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

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

Треба визначити тип завдання програмування. Якщо ви займаєтесь розробкою компіляторів та алгоритмів, питань про такі речі слід очікувати. Якщо ви користуєтеся програмами бізнес-типу та очікуєте, що кандидат може робити додатки CRUD, то знання концепції (без написання програми), можливо, достатньо. Сьогодні знання різних технологій, необхідних для спеціальної роботи в додатках типу LOB, витісняє потребу в акуратних алгоритмах.

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

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

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

1) Це питання про фіз-кайф. Ви просто перевіряєте щось дуже основне: чи розуміє людина пов'язаний список. Запитайте і рухайтеся далі.

2) Існує складна проблема із пов'язаними списками, що мови, які дуже підходять для відображення вашого розуміння понять зв'язаного списку (наприклад, C), можуть не збігатися з мовою, з якою вони працюватимуть у роботі. Ви, звичайно, можете продемонструвати базове розуміння будь-якою мовою зі структурами, але, попросивши кандидата повторно реалізувати зв'язаний список в Ерланге, не використовуючи [], це не той самий виклик і не скаже вам те саме про розуміння кандидата як просити їх зробити це в C. Попросити їх зробити це в C, якщо робота навколо Java, також дещо не вистачає точки.

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

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

Якби я коли-небудь брав інтерв'ю, я б пішов на якусь реалізацію пов'язаного списку, щоб не перевірити, наскільки хороша людина в кодуванні, а щоб перевірити, скільки уваги людина приділяє деталям. Будь-хто може написати пов’язаний список, але це крайові випадки, коли навіть деякі хороші програмісти не вдається. Не питайте його: Write a code for linked list in C/C++. Попросіть його написати загальний пов'язаний список на C (а не на C ++) тощо.

Скрутіть проблему та поставте деякі інші умови у зв'язаному списку, і у вас буде гарне запитання. Деякі люди зобов'язані робити помилки тоді.

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

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

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

Задавайте питання, що стосуються роботи, яку кандидат, швидше за все, призначить, і спробуйте скласти уявлення про те, як вони почуваються щодо отримання нових знань. Як вони могли б розібратися у значенні якогось незрозумілого синтаксису, якого вони ніколи не бачили? (Якщо ви, наприклад, магазин C, тоді ви можете спробувати питання, пов’язане з триграфами.) Що стосується програми програмування, чи регулярно вони читають чи сприяють форумам, таким як переповнення стека? Якщо б їх попросили виконати якесь завдання в мові програмування або в рамках, з якою у них мало або немає досвіду (скажімо, якщо ви в першу чергу є магазином Java, що робити з Clojure або .NET?), То як би вони підійшли до проблеми? Можливо, візьміть справжню помилку зі свого трекера помилок (можливо, навіть такий, який давно вирішений) та запитайте їх, як вони в загальних рисах підійдуть до його вирішення, і будьте готові пояснити відповідні частини продукту, про який йде мова.

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

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

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

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

Ось як я думаю про це:

• Рідко виникає потреба написати таке, як ви кажете, щоб люди легко забули.
• Їх не дуже важко написати.
• Поняття, які використовуються для їх написання, можна вважати фундаментальними.
• Вони використовуються неймовірно часто (навіть якщо ви цього не знаєте).

Я думаю, що це робить їм гарні запитання. Якщо ви переживаєте за них, попередньо навчаючись на співбесіду, тоді киньте список. Попросіть їх написати циркуляр і запитати, який асимптотичний час їх виконання. Або вони записали іншу загальну та / або швидку структуру даних ... Двійкове дерево пошуку? Черга (FIFO)? Стек (FILO)? O(n)Черга наївних ( ) пріоритетів? Багато людей, яких я знаю, думають, що BST - це O(log n) лише тому, що це дерево .

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

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

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

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

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

Якщо людина зможе написати код, я б подумав про включення до алгоритму та / або питання структури даних, якщо це було би відносно цієї посади. Я б спробував вибрати щось, про що можна було б обговорювати або використовувати раніше. Я б також зосередився на речах, крім простої реалізації згаданих алгоритмів та структур даних, таких як час роботи та споживання пам’яті (такі речі, як нотація big-O). Ці поняття стосуються не лише створення структури даних, а й вибору, яка реалізація найкраще підходить (наприклад, наприклад, ArrayListпорівняно з a LinkedList).

Я не думаю, що для звичайної роботи з програмування має бути питання, яке усуває кандидата. Але це добре, щоб побачити, чи маєте ви справу з дійсно старшим програмістом або тим, хто просто мав форми кодування мавп протягом багатьох років. І навіть так, це не повинно бути принциповим критерієм вибору програміста. Можливо, це чудовий програміст з поганою пам’яттю і не хоче читати слова «пов’язаний список» років (або не пам’ятає ім’я), але все ж може робити хороші програми.

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

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

Написання реалізації зв'язаного списку - це гарне запитання про інтерв'ю, оскільки воно відкриє багато про спосіб кодування кандидата:

• Він знає, що таке API? Чи може він використовувати код інших людей? Чи може він написати код, щоб інші люди могли ним користуватися?

• Він знає, що таке пов'язаний список? Чи знає він колекції, структури даних, алгоритми?

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

• Як він справляється з проблемою? Починає він спочатку з аналізу, невеликої специфікації, деяких тестів заздалегідь? Або він просто починає щасливо злому?

• Він обробляє крайові справи? А що з видаленням останнього вузла із пов'язаного списку? Що робити, якщо хтось спробує додати посилання на пов'язаний список до пов'язаного списку, а потім видалить усе?

• Він обробляє винятки? Кожна мова програмування має власні умови для обробки винятків: на Java ви очікуєте, що LinkedList викине NoSuchElementException, коли ви зробите getFirst () у порожній список. Інші мови можуть повертатися невизначеними, -1 або постійними.