Який найкращий спосіб оцінити нових програмістів? [зачинено]


52

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

Більше речей, які я маю зазначити:

  • Система освіти в моїй країні смокче - справді смокче. Люди, які хороші в такій роботі, хороші тим, що мають талант до цього або справді намагаються навчитися самостійно.

  • Ступінь університету / випускника / післядипломної освіти не означає, що ви точно знаєте, як це робити.

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

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

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

Я сподіваюся, що я не звучу надто агресивно у своєму питанні; і BTW я сам програміст.

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


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

Відповіді:


52

Що стосується вибору кандидата, то я зазвичай йду з планом три удари:

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

  • Поверніться до тесту з кандидатом та обговоріть відповіді. Можливе розширення питань, щоб досягти меж кандидата. Це може бути обширним, і чим воно більш масштабне, тим краще.

  • Остання частина, але не в останню чергу, The Code Review . Я прошу кандидата принести фрагмент коду (я, як правило, попередній тест / дискусію та цей огляд відкладаю на кілька днів, щоб вони могли написати та відшліфувати один фрагмент коду). Тоді ми робимо регулярний огляд коду з двома людьми: однією людиною, яка буде безпосередньо працювати з кандидатом, і особою, яка раніше перевіряла тест з кандидатом. Щодо огляду коду, ви можете прочитати цю статтю від JohnFX .

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


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

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

1
@ChristopherMahan Значення FizzBuzz (і подібне до тривіального кодування) є простим воротарем. Якщо вони не можуть реалізувати FizzBuzz, мовою, якою вибираєте, вони можуть написати будь-який код?
Ватін

@Vatine FizzBuzz тести на здатність логічних міркувань, а не навичок програмування. Зрозуміло, треба робити це. Простим питанням програмування було б: відобразити на екрані список елементів, відсортованих цікавим чином. Їм доведеться кодувати, але вони зможуть скористатися досвідом, щоб придумати що-небудь написати, і не доведеться також намагатися з’ясувати тизер мозку. Я одного разу провалив інтерв'ю, тому що вони хотіли, щоб я використовував регулярний вираз, і я відповів, що для цієї проблеми regex - це надмірність, і python має вбудовані можливості для цього. Я не хотів там працювати.
Крістофер Махан

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

20

Почніть з надання їм FizzBuzz для вирішення. Це повинно викреслити найгірше з них.

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

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


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

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

1
@Andrey - Розмовна частина полягає в тому, щоб зрозуміти їхній процес мислення. Ви хочете побачити, як вони думають про проблему і підходите до її вирішення. У вас є кращий варіант?
Oded

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

4
Навіть як відвідувач школи, яка має декількох недавно визнаних професіоналів CS, я вважаю, що тривіальний fizzbuzz - це прекрасний фільтр. Більшість людей, з якими я закінчив, напевно, не могли вирішити це за розумну кількість часу. Ті люди намагалися знайти роботу чи ні. Я думаю, що після joelonsoftware.com/articles/GuerrillaInterviewing3.html це добре.
Ріг

14

Просто шукайте пристрасть до роботи.

Щоб цитувати Джоеля, шукайте людей, які " Розумні, і робіть справи ".

Решта не має значення


7
Проблема в тому, що ви не можете сказати, чи вони розумні.

4
@Chad: пристрасть до навчання не "робить справи". Щоб дізнатися, чи хтось може щось зробити, ви повинні попросити їх щось зробити.
Кевін Клайн

2
@kevin cline, підмітив мою публікацію. Їм потрібно захоплюватися роботою, як правило, це проявляється бажанням вчитися. Так, це потребує деяких питань, розмова повинна витікати, це не повинна бути лише низка питань. Але щоб дізнатись, чи досягають вони справи, попросіть приклади, де у них була перешкода та як вони її подолали. Кожна людина потрапляє на дорожні блоки на своїй роботі, будь то з технології, людей, процесів, але розумна людина, яка все робить, знайде спосіб її подолати і зможе детально пояснити це, достатньо, щоб продати вас на їх здатність.
CaffGeek

3
@mouviciel не в моєму досвіді. Деякі з найрозумніших програмістів, яких я знаю, дуже екстравертні.

4
Якщо ви не можете сидіти в кімнаті з кандидатом на розробник і розібратися, чи вони розумні чи ні, знайдіть когось, хто зможе.
JeffO

13

На основі мого 25 років програмування (який, правда, включає лише 5 або 6 випадків найму інших програмістів):

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

  • Пристрасний до технологій

  • Програми як хобі

  • Якщо вам буде запропоновано, викликте вухо на технічну тему

  • Значні (і часто численні) особисті побічні проекти протягом багатьох років

  • Вивчає нові технології самостійно

  • Думав про те, які технології кращі для різних звичаїв

  • Дуже незручно щодо ідеї роботи з технологією, яку він не вважає "правильною"

  • Ясно розумний, може великі розмови на найрізноманітніші теми

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

  • Має кілька прихованих «айсбергів», великих особистих проектів під CV-радаром

  • Знання великої кількості різноманітних непов'язаних технологій (можливо, їх немає на резюме)

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

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

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

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

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

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

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

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

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

Крім того, я б запропонував:

  • Тест FizzBuzz (або щось подібне для перевірки базової здатності писати алгоритм.
  • Більш тверда версія тесту FizzBuzz (щоб довести їх до точки відмови чи майже до відмови.)
  • Обговоріть їх код і подивіться, чи готові вони бути самокритичними і шукайте вдосконалення (чого, мабуть, не встигли зробити за короткий термін на місці тесту), наприклад:
    • хороші назви змінних (у мене були дуже досвідчені кваліфіковані кодери, які використовують такі змінні у виробництві, як "прапор" (WTF ??)
    • модуляризація.
    • Передбачаючи проблеми та виконуючи "захисне кодування"
  • Бажання бачити "недоліки" як можливості для вдосконалення. Я думаю, що найкращі кодери завжди непомітно дивляться на недоліки в попередньому коді. Вони не настільки егоцентричні, щоб думати, що виявити їхню ваду - це особиста боротьба. Вони розглядають це як можливість зробити краще. (Ті, хто не може дивитись на недоліки або непомітно, або перебувають у захваті, бачачи недолік (і стають супер невпевненими в собі, або, щоб уникнути просто цього, вони ігнорують недоліки).
  • Чи можуть вони налагоджувати?
  • Чи можуть вони провести тестування? (Я говорив із занадто великою кількістю програмістів, які кажуть "QC робить це". Я не говорю про тестування, я кажу про тестування: ви пишете функцію, чи працює вона? Чи докладаєте розумні зусилля, щоб впоратися з цим ймовірні проблеми (введення NULL тощо)? Якщо ви не можете цього зробити, як дізнатися, коли закінчите?
  • Чи мають вони хороші навички спілкування? (як мінімум: добре розуміння та знання себе про те, коли вони цього не розуміють, та готовність сказати "я не розумію, будь ласка, поясніть це ще раз".

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


10

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

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

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


7

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

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

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


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

3
Занадто багато часу? Хтось повинен буде поговорити з кандидатами. Жоден письмовий тест не буде працювати. Зміст тесту швидко стане загальнодоступним, і кандидати прийдуть із запам’ятованими відповідями.
Кевін Клайн

10
@kevincline: Точно, ви повинні з ними поговорити. Я брав інтерв'ю в Xerox (ще в 70-х роках), і мене запитали, як я буду обробляти зіткнення в алгоритмі хешування. У мене не було багато формальної школи з програмування, але я займався цим близько 5 років, тому я сказав, що не знаю, що таке хеш. Мій інтерв'ю пояснив це мені, потім повторно задав питання. Ми продовжували більше години, коли я виявив і вирішив кілька типів проблем зіткнення. Він сказав мені, що якщо я можу це зробити за годину, то я можу впоратися з усім, що вони кинули на мене. Я влаштувався на роботу. Тому що він розмовляв зі мною.
Пітер Роуелл

@PeterRowell Саме таким має бути все. +1
Хірон

3

Читання цього питання та деякі отримані відповіді спонукали мене написати статтю, яка, на мою думку, може зацікавити:

Незвичайні практики підбору персоналу при наймі розробників програмного забезпечення

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

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


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

1
@sleske, я погоджуюся в принципі, особливо якщо на всіх інтерв'ю відвідують одні і ті ж люди. Тому краще поділитися тягарем, щоб знайти найкращий підхід як для компанії, так і для команди, і дає вам можливість дізнатися на спостереженнях інших. Погані співбесіди не будуть йти далі, але чим більше зацікавлених сторін із зацікавленням кандидатом, тим більше інтерв'ю вам може знадобитися, тому незвично проводити 3 чи навіть 4 інтерв'ю в дуже широких командах. Забагато більше, хоча б створило враження, що вони страшенно неорганізовані. Він також платить розповісти кандидату про кількість попередніх співбесід.
С.Робінс

@ s-robins цікаві думки, хочу лише поглянути на деякі аспекти мого питання. Через непідконтрольну нам причину ми не можемо відібрати наших кандидатів на основі звичайного процесу підбору персоналу, натомість кандидати приходять лише і нам потрібно сказати, чи має він / її правильні навички / ноу-легед для прийняття на роботу. Можливо, в нормальних процесах набору персоналу такі речі трапляються не надто часто. але в нашому становищі нам потрібно розібратися в цій ситуації.
Рафаель

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

@ s-robins ви добре зрозуміли ...
Рафаель

1

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

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


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

2
@Rafael norvig.com/21-days.html . Як я вже говорив, це залежить, якщо ви шукаєте молодшого програміста чи старшого.
BЈович

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

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

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

1

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

Подумай над цим. Якщо питання FizzBuzz усуває 199 із 200, то це просто усунуло сотні інтерв'ю. Ви справді збиралися опитати сотні перспектив?

Просто здається, що зменшення прибутку після FizzBuzz. Це припущення, що 199/200 навіть приблизно близько. І я вважаю, що ТВОЙ час теж цінний ...


2
Страшно, наскільки FizzBuzz є стандартним тестом для оцінки компетентності програміста. Однак це перевірений і справжній тест - я не можу сказати, скільки програмістів з
рівнями

0

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

Такі приклади дурного простого питання - це питання про рекурсію, наприклад, у вас є список, і ви повинні надрукувати його зворотним порядком без використання циклу. Просте питання регулярного вираження, якщо регулярно виражається регулярний вираз у вашій розробці. Питання про біти та байти при використанні C ++ (напишіть шаблон, який приймає char до довгого і роздруковує двійкове представлення. Спеціалізація не потрібна, просто використовуйте sizeof (), щоб визначити бітну довжину)

Це займе у вас приблизно <= 3 хвилини на запитання


0

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

Цього мені достатньо, щоб оцінити здібності програміста як програміста.


0
  1. Чи можуть вони захищати те, що вони стверджують, що знають? Вони ставлять це на резюме / резюме як навичку або щось, що вони зробили в іншому проекті. Подивіться, наскільки глибоко вони можуть піти на цю тему.
  2. Чи можуть вони навчитися чомусь новому? Поговоріть про високотехнологічний аспект технології, яку ви використовуєте, або щось специфічне для ділового представника, в якому ви працюєте, і подивіться, чи можуть вони зрозуміти тему. Вони задають розумні запитання? Чи можуть вони придумати аналогію? Це схоже на те, що вони зробили в іншій галузі чи технології?

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

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


0

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

Перше прополка - це резюме. Я шукаю одне, що є багато заявленого мовного досвіду, і нічого не можна описати, що вони зробили на цій мові. Я бачив резюме, яке в значній мірі стверджує, що вони знають кожну мову, яку коли-небудь винайшли, але все ж їхній досвід показує, що вони працювали лише з Access і Visual Basic. Ті йдуть прямо у смітник. 10 сторінок резюме йде прямо на смітник (особливо десять сторінок резюме від людей, які мають менше ніж 2-річний досвід роботи, які я отримав). З останніх дипломів коледжу з невеликими сумнівами ви повинні бути дуже прискіпливими до того, як вони себе представляють. Кращі кандидати обережні зі своїми резюме, у них немає помилок. Ви справді шукаєте когось, хто так мало піклується, щоб він не покладався перечитати своє резюме?

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

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

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

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


-1

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

Якщо вона виходить в літаючих кольорах, вона в!

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