Як розпізнати хорошого програміста? [зачинено]

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

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

Редагувати: Відповідно до відповіді Маной, ось питання, пов'язане із завданням кодування на співбесіді.

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

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

Наймати хороших людей важко .

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

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

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

Деякі ідеї:

• Задайте кілька питань відкритого типу з декількох різних кутів:

  • Перегляньте деякий код. Що визначено? Технічні помилки, невідповідності стилів, коментарі, алгоритми, ремонтопридатність тощо ...
  • Напишіть якийсь код. Шукайте процес, куленепроникність, читабельність тощо.
  • Створіть дизайн високого рівня для невеликої системи. Шукайте розуміння проблеми, підходу, комунікацій, повноти, деталізації.
  • Опишіть процес розробки програмного забезпечення. Шукайте дизайн, співпрацю, огляд, тестування, хороші / шкідливі звички та загальний досвід.

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

  • Чесність: чи він знає стільки, скільки стверджує?
  • Глибина знань: наскільки добре він / він вчиться речам?
  • Спілкування: наскільки добре він / він пояснює вам щось незнайоме? Чи логічний процес логічним?
  • Реакція на стресові ситуації: наскільки важко він / він працює, щоб відповісти? Він / він підробляє це? Це неминуче "я не знаю" легко чи важко?

• Запитайте, як кандидат вирішував різні ситуації на попередніх робочих місцях: командна робота, прострочені проекти, налагодження тощо . Чи відповіді позитивні чи негативні? Пристрасний? Розумний? Нахабний?

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

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

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

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

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

Редагувати: Я також написав коментар про інтерв'ю тут .

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

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

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

Зробіть їх кодом. Надайте проблему, яку можна вирішити, скажімо, через 4 або 5 годин, і ознайомтесь з кодом щодо документації, стилю кодування, як він планував рішення, перш ніж насправді почати кодувати тощо. Йому не потрібно дійсно вирішувати проблему. І як згадував Джон Скіт, змусьте їх говорити про програмування, мову вибору та подібні речі. Ви можете розпізнати пристрасть у хорошого програміста. Запитайте, скільки сайтів, пов’язаних з програмуванням, вони переглядають, як stackoverflow. Блоги, які вони слідкують за іншими, можуть бути хорошим показником.

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

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

Але є кілька типів програмістів.

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

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

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

Питання, яке я б задав при прийнятті на роботу програміста, було б: "Чому ви виховували себе як програміста?". Це було б мертвим піддаванням, якщо вони там вагаються.

Це моя думка.

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

Дуже важко розпізнати програміста на основі співбесіди.

Деякі речі, які вирішують, що хтось є хорошим програмістом, це:

• вміти працювати в команді
• пише хороший код, зрозумілий і корисний
• вміє дізнаватися про нові технології

Отже, у вас є кілька невеликих підказок, про які можна дізнатися в інтерв'ю:

• Чи знає кандидат одна технологія / мова програмування чи він знає кілька? Якщо він знає різні мови, він, здається, може навчитися новому, і, можливо, він знає про недоліки його поточної вподобаної технології / мови. Тож вимагайте знань, окрім технології, яку ви використовуєте у своїй компанії.
• Запитуйте проекти, в яких він уже працював, особливо хобі-проекти та відкритий код. Хобі-проекти показують, що він любить програмування та займається цим навіть у вільний час (і це покращує його навички). У проекті з відкритим кодом ви можете шукати написаний ним код. Якщо в проекті бере участь більше однієї людини, ви можете отримати підказки про його командні навички. В ОС-проекті ви можете знайти архіви списків розсилки, щоб знати більше.

Ви можете зробити тест в інтерв'ю.

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

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

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

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

Після цього я використовую пару техніки в галузі Java, як обговорюю деякі принципи, в основному взяті з Ефективної Java.

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

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

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