Нещодавно я посперечався з колегою-програмістом. Він проводив співбесіду на нову посаду і йому було задано це питання:

Наведіть послідовність чисел, що починається з X і закінчується на Y, але один елемент відсутній, так що N є YX-1, знайдіть відсутній елемент в O (N) або краще.

Тепер відповідь тут не має значення (але цікава). Це розпочало дискусію про те, чи це навіть гарне запитання для інтерв'ю.

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

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

Ваші думки? Хороше запитання для інтерв'ю чи ні?

Я згоден із запитанням щодо алгоритму, але я не згоден із наполяганням на конкретному рівні якості великої якості.

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

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

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

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

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

Вимоги

Такі питання свідомо недостатньо конкретизуються. У вашому прикладі більше ніяких деталей щодо послідовності немає. Якщо у вас є співбесідник, який запитує, чи справді ці цифри відсортовані, то це хороший знак. У нього правильний спосіб мислення, щоб запитати клієнтів про подальші деталі, що допоможе прийти до кращого рішення за коротший час. Кандидат може також грати з ідеєю використовувати простір O (n) для зберігання масиву з N чисел, але він не повинен цього робити, не розпитуючи про більш детальну інформацію про X та Y. Скажімо, що X і Y - від 1 до 1000 , тоді впевнено, ідіть вперед і запускайте рішення на основі масиву. Але якщо я скажу вам, інтервал - 1 і 1 мільярд, то проблема стає зовсім іншою. Дозвольте ще раз наголосити, що мені не байдуже рішення.

Стандартні методики

Я не хочу наймати програміста, який навіть не знає, що означає O (n). Це абсолютно обов'язково знати, чи мали ви гідну освіту в цій галузі. Але також важливо не просто знати, що це означає, а реально застосувати ці знання. У вашому прикладі я хочу, щоб кандидат усвідомлював, що йому заборонено сортувати дані (не задаючи додаткових питань, орієнтованих на вибір сорту відра чи інші підходи до сортування O (n)) через сортування, необхідне O (n log n) загалом.

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

Проблема розбору проблем

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

Приклад: Ви не хочете, щоб ваш кандидат перейшов у безшумний режим протягом наступних півгодини! Перевірте, чи може він підійти з розумними запитаннями (див. Вимоги), перевірте, чи не починає він думати з коробки, як тільки зрозуміє, що не може цього зробити. Навіть "веселе" зустрічне запитання на кшталт "Чи можу я скористатися параметром" телефон-колега "?" - хороший знак.

Як відповісти

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

Як загальна примітка до питань інтерв'ю: зустрічні запитання рідко є поганою справою. В одному з моїх власних інтерв'ю мене, наприклад, запитали щось на зразок наступного: "Якщо вам доведеться реалізувати X, ви вибрали б для цього C ++ або Java, і чому?" - Я просто протистояв "Чи обмежений я цими двома?". Здогадайтесь самі, яку реакцію ви отримаєте від інтерв'юера на таке зустрічне запитання - і як легко вам реально показати інтерв'юеру, на що ви здатні.

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

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

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

Проблема цього конкретного питання полягає в тому, що це майже хитромудрі питання. Отримавши одне конкретне розуміння, ви легко придумаєте O (n), інакше ви будете боротися, щоб стати кращим, ніж O (n log n). Це майже зводиться до "Ви бачили це раніше?"

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

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

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

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

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

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

Мені подобаються питання алгоритму, тому що це ми робимо. Мені подобаються обмеження, тому що це ми використовуємо. Big-O особливо актуальний у моїй галузі.

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

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