Який найкращий спосіб розпізнати відмінника-програміста на співбесіді з роботи?


82

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

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

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


Питання передбачає, що це можна зробити надійно.
Ентоні


не обов'язково. вірною відповіддю було б "взагалі немає можливості"
Клавдіу

Відповіді:


65

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

Загальний інтелект (тизери для мозку / логічні головоломки)

Знання з інформатики

Вправи з програмування

  • ГХД , Факториал , Фібоначчі , вежі Ханої
  • Зміна рядків і списків
  • Визначте, чи є в окремо пов'язаному списку цикл (чи можете це зробити лише з двома вказівниками?)
  • Знайдіть помилку

Знання об'єктно-орієнтованих методик програмування та загальних моделей проектування

Аналіз алгоритму (час виконання O (n) складності та вимоги до зберігання)

Використання інструментів та методологій

Знання загальних вразливих місць безпеки та атак

Основна математика

  • Числові системи (перетворення з однієї бази на іншу)
  • Теорія ймовірностей
  • Відстань між двома точками на декартовій площині (теорема Піфагора)
  • Квадратний корінь (чапля Олександрійської, послідовне наближення)

Криптографія

  • Криптографія відкритого ключа
  • Симетрично-ключова криптографія
  • Хеш-функції
  • Криптографічні протоколи (обмін секретом, підтвердження нульових знань)

Дискретна математика

  • Логіка
  • Теорія множин
  • Теорія графів
  • Інформаційна теорія
  • Комбінаторика
  • Докази (як існування ірраціональних чисел, нескінченних простих чисел)

Можливо, ви також захочете поглянути на книгу " Програмні інтерв'ю, що експонуються" . Це гарна посилання на тему.


10
Фу, це повинно бути довге інтерв'ю.
Рік Мінерих

8
Сьогодні я спробував вирішити "Перетинання мостів" зі своїм товаришем по конкуренції з програмування ACM. Єдина відмінність полягає в тому, що ми повинні вирішити це для будь-якої кількості людей. На це нам знадобилося близько 30 хвилин, щоб вирішити будь-яку кількість N людей .. але в інтерв'ю я вважаю, що головоломки є поганою метрикою.

52
Під час інтерв'ю головоломки смокчуть, оскільки респондент нервує, не думає прямо тощо. Крім того, багато головоломок - це а-ха! введіть речі, які насправді нічого не говорять про кандидата.

11
Я вважаю ці математичні проблеми великими труднощами. Після того, як ви закінчили ступінь інформатики протягом 10 років, як ви можете запам'ятати, як довести ірраціональні числа і таке?

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

28

Ах, вічне питання.

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

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

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

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

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

Я навчив дівчат з HR, щоб мені здавали будь-які резюме, як тільки вони їх отримують; Я розкладаю інтерв'ю особисто, якнайшвидше (в ідеалі післязавтра після отримання резюме для хороших резюме). Потім він отримує зі мною півгодинну або однугодинну співбесіду і принаймні одного колегу (як правило, мого начальника чи члена команди), де я знайомлюсь з ним і відповідаю на будь-які запитання. Навіть якщо я відхиляю його заявку на місці, він отримує 20-30 хв тур компанії, і я розмовляю про те, що ми робимо і як це робимо. Потім я надсилаю його до HR на психотест і трохи дійсно базового кодування паперу / SQL. Обидва тести майже ніколи не відіграють значної ролі в моєму рішенні, це скоріше перевірка, яку я правильно оцінив в інтерв'ю. Після результатів, це 15-хвилинна розмова, де я пропоную йому пропозицію, і якщо ми домовляємось про умови, якими ми обоє задоволені, він найнявся.

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

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

Також одна порада. Надсилайте листи про відхилення (або електронні листи) для кожної отриманої вами програми. У моїй нинішній компанії я зазвичай залишаю це HR (крім тих, про які я розповідаю під час співбесіди), але в один момент це було безцінне отримання задоволення від відхиленого кандидата у рядках "ДЯКУЙТЕ! Ви - перша компанія, яка насправді відповів замість того, щоб залишати мене цікавити, чи відповідуть вони одного дня! "


Психологічне тестування?

5
@ Ink-Jet: ні, психотестування було правильним - кандидата просять написати код, який буде підтримувати насильницький чоловік, який також знає свою домашню адресу.

Це я читав як перший раз, якщо чесно.

@Grundlefleck - так, це правильно. :)
Домчі

2
Якби я отримав ваш лист про відмову, я би вдячний вам. Мене відхилили через мовчання після того, як я отримав інтерв'ю по телефону, і це нервує нерви.
01d55,

24

Ця відповідь трохи поза рамками, але я вважаю, що це цінний момент.

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

Отже: найкращий спосіб сказати відміннику-програмісту на співбесіді з роботи - це те, що його там немає .


2
так правда ... чудовий момент. :)
Арніс Лапса

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

17

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


11

Можливо, "відмінний" програміст не приходить до вас на співбесіду. Ймовірно, вам доведеться викрасти його у когось іншого.


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

9

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

Я виявив, що пристрасні програмісти ВЖЕ завжди читають, і зазвичай список включає кілька програмувань / Comp. Наук. книги в останньому списку.

Йдеться не лише про те, щоб бути в курсі професії - пристрасні програмісти мають бажання та любов до програмування та схильні пожирати матеріал на найрізноманітніші теми - не лише те, якою мовою вони зараз користуються, але методологіями, іншими мовами (особливо нові або "дивні" або стародавні), інші аспекти ІТ (можливо робототехніка, або AI, або ігри, або ...)

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

Ура,

-R


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

1
А ще краще запитайте їх, яку книгу вони написали цього місяця. :)

7

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

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


7

Книга " Розумний та отримує щось зроблене: Короткий посібник Джоела Спольського щодо пошуку найкращого технічного таланту " може допомогти знайти відповідь.

Зміст:

  • Вступ
  • Глава 1: "Потрапляння у високі ноти"
  • Глава 2: "Пошук великих розробників"
  • Глава 3: "Польовий посібник для розробників"
  • Глава 4: "Сортування резюме"
  • Глава 5: "Екран телефону"
  • Глава 6: "Партизанський посібник з інтерв'ю"
  • Глава 7: "Виправлення субоптимальних команд"
  • Додаток: "Тест Джоеля"

Стаття Джоела "Партизанський посібник з інтерв'ю (версія 3)" також може бути корисною.

І стаття "Готово, і отримує речі розумні" Стіва Йегге на цю тему.


4

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

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


4

Попросіть їх на дошці. Тільки так ви зможете сказати, чи знають вони, як написати код.


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

3
@Kristopher: Якщо програміст може написати хороший код на комп’ютері, що змушує вас думати, що вони зможуть записати його на дошці? Це значно різні середовища.
Девід Торнлі

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

3

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

Щоб вирішити проблеми з кодуванням, використовуйте чат із чимось на зразок codepad.com і дозвольте їм це робити з комфорту власного будинку. Ви пишете велику частину свого коду на дошці перед начальником, із 30-хвилинним терміном і вашим бонусом на лінії? Я не.

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

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


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

2

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

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

Але я визнаю, якщо він не може написати простий цикл, що рахує від 1 до 10, у вас виникли проблеми.


1

Перш за все, є один із способів отримати ідею до того, як інтерв'ю навіть розпочнеться:

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

По суті, у них є пристрасть до програмування чи ні? Це справжнє питання.


1

Прийняття хорошого програміста на інтерв'ю найкраще, на мою думку.

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

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


1

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

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

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


1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

Зі статті:


Критерії в куль

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

Позитивні показники :

  • Пристрасний до технологій
  • Програми як хобі
  • Якщо вам буде запропоновано, викликте вухо на технічну тему
  • Значні (і часто численні) особисті побічні проекти протягом багатьох років
  • Вивчає нові технології самостійно
  • Думав про те, які технології кращі для різних звичаїв
  • Дуже незручно щодо ідеї роботи з технологією, яку він не вважає "правильною"
  • Ясно розумний, може великі розмови на найрізноманітніші теми
  • Почав програмувати задовго до університету / роботи
  • Має кілька прихованих «айсбергів», великих особистих проектів під CV-радаром
  • Знання великої кількості різноманітних непов'язаних технологій (можливо, їх немає в резюме)

Негативні показники :

  • Програмування - це денна робота

  • Не дуже хочеться "розмовляти", навіть коли це рекомендують

  • Вивчає нові технології на курсах, спонсорованих компанією

  • Рада працювати з будь-якою технологією, яку ви вибрали, "всі технології хороші"

  • Не здається занадто розумним

  • Почав програмувати в університеті

  • Весь досвід програмування - на резюме

  • Зосереджено в основному на одному або двох стеках технологій (наприклад, все, що стосується розробки додатку java), без досвіду поза ним


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

0

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

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


Я здивований, що ви не натрапили на оператор модуля. Мене познайомили з різними мовами, які я вивчив за рік.

2
Якщо ви попрацювали в CS в коледжі, оператор Modulo програмує 101

напрочуд такі речі, як біт-зсув та модуль, пропускаються в коледжі
Клавдіу

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

2
Насправді вони обидва навчаються в початковій школі; на цьому етапі їх називають "залишком" і "множенням на 10".
інтуїтивно

0

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

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


рекурсія, синхронізація процесів, взаємне виключення. Ці технології не менш важливі, працюючи з C #, VB.NET, C або мовою складання.

-1 - Це невірно неправильно. "Вид" мов та інструментів на 100% "не має значення".
Морган Херлокер
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.