У мене дилема. У мене є кандидат на посаду старшого розробника програмного забезпечення.

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

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

Редагувати:

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

Тож ми зробили пропозицію.

Дякую всім за розуміння.

Як завжди...

Це залежить

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

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

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

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

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

Якщо тест не зміниться, пропустіть його.

Я не бачу вагомих аргументів пропустити тест. Тому слід зберігати його.

Якщо ви вірите, що кандидат буде брати участь у тестуванні, це говорить саме по собі.

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

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

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

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

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

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

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

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

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

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

Робіть технічні, перш ніж когось наймати.

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

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

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

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

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

Переверніть його.

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

Потім позначте деякі відповіді на власні запитання як "технічне випробування зроблено".

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

Крім того, наскільки здатні ви могли б сказати, що ви виконуєте роботу, яку цей тест розробив для оцінки?

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

Особисто я вважаю, що це хороша політика, і я рекомендував би її для вашої ситуації.

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

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

Потім подивіться на послідовність світлофорів. Якщо вони хороші розробники TDD , ви повинні отримати хороший повторний червоний / зелений прогрес.

^{Якщо ви хочете пограти з кібер-доджо, у автора є приємна онлайн-версія тут .}

Ще одне питання - скільки впевненості маєте у своєму відділі кадрів.

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

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

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

Ви неодноразово повторювали, що терміни наступають - я припускаю, що ви знаєте про закон Брука.

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

Удачі з наймом та проектом!

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

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

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

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