Наскільки ефективні проблеми програмування в процесі набору? [зачинено]

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

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

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

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

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

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

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

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

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

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

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

Дуже ефективний.

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

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

Більше шансів побоюватися прийти до нас на ярмарку кар’єри.

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

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

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

Удачі в цьому.