Технічне інтерв'ю та здатність програміста [закрито]

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

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

1. Чи справді можна оцінити чиїсь технічні можливості за півгодини? Чесно? Або це просто кидок кісток?

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

3. Чи люди, які в цьому інтерв'ю виходять з літаючими фарбами, стають чудовими програмістами? Вони продовжують розробляти гладкі ігрові двигуни, графічні бібліотеки, пишуть швидкі рамки для з'єднання форк? Чи є якісь докази, які свідчать про позитивний взаємозв'язок між успіхом у технічних інтерв'ю та фактичною здатністю програмування? Або ці інтерв’ю більше орієнтовані на пошук типу "вирішення справи" (Спольський)?

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

Я в основному в академіях (студент ступеня) - тому дуже оціню сприйняття когось із іншого боку паркану. Хтось, хто насправді проводить ці співбесіди?

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

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

Майте на увазі, що ...

1. Основна мета процесу співбесіди - не довести до абсолютної правди про особисті здібності кожного респондента, а вибрати декілька кандидатів із групи людей.
2. МНОГО, МНОГО дорожче найняти поганого розробника, ніж передавати хорошому.

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

Чи реально судити чиїсь технічні здібності за півгодини?

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

Чи вимірюють питання технічного інтерв'ю можливість вирішення проблем?

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

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

Ось про це. Велич рідкісна. Я радий знайти когось грамотного.

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

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

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

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

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

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

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

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

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

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

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

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

Щодо Ваших питань:

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

2. Див. №1. Частина шуму виходить від зміни того, чи бачили люди проблему раніше.

3. Див. №1. Мабуть, існує невелика позитивна кореляція між цими тестами та набуттям чудового програміста.

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