Питання Joel Test №11: "Чи пишуть нові кандидати під час інтерв'ю?". Які аргументи «за» і «проти», щоб попросити нових кандидатів написати код під час співбесіди та прийняти рішення про нього?
Відповіді:
Я не бачу мінусів. Інтерв'ю має багато частин, і кандидата слід кілька разів схвалити «по ланцюжку».
Я інтерв'ю ~ 10 людей щотижня. Я дуже, дійсно, ДУЖЕ оцінюю той факт, що HR виконав усі фонові роботи та подав мені багато записок. До того моменту, коли вони до мене потрапляють, настав час скласти їхні тести.
Тести повністю залежать від позиції. Як правило, я намагаюся пробувати:
Загальна навичка програмування. Чи можете ви ефективно використовувати операторів? Чи можете ви уявити систему числення, яка має радіус, який не дорівнює 10?
Чи знаєте ви, як робити те, що ми вас наймаємо?
Оцінка ваших внесків у будь-які проекти з відкритим кодом, які ви перерахували
Я намагаюся тримати це коротко і весело. Коли я заходжу в офіс, я хапаю відповіді, переглядаю їх, а потім провожу вторинну співбесіду. Щоб прийняти на роботу, зазвичай потрібно пройти три співбесіди.
Я також оцінюю, наскільки добре ви будете поєднуватися з командою, яка буде приймати вас. Ця команда розраховує на те, що я можу це зробити ефективно.
Одне питання - відповісти на запитання в мета-формі, інше - насправді виробляти код. Якщо я збираюся наймати вас, мені справді потрібно бачити, як ви виробляєте код.
З вибаченнями Скотта Вітлока:
Мінуси:
Плюси:
Якби ви збиралися наймати жонглера, вам би не до душі, щоб він не мав на вас жонглювати. Або музикант, у якого ви проходили б прослуховування. Інакше ви отримуєте такі речі, як дивовижний йо-йо "майстер" K-strass .
Прогулянка через щось на дошці - це програміст, еквівалент швидкого демонстраційного демонстрації.
Я думаю, що це дуже корисно, і я завжди це роблю, але оскільки переваги були охоплені настільки добре, я збираюся обговорити лише (очевидні) негативи.
Я думаю, що тести на коди навряд чи дадуть помилкові позитиви: шанси низькі, що той, хто насправді не може написати код, зуміє підробити його в інтерв'ю, принаймні, якщо у вас є шкала питань, що збільшують труднощі. (Мабуть, найімовірніший сценарій - це їх обман, запитуючи друга, якщо це не інтерв'ю віч-на-віч.)
Проблеми більше стосуються хибнонегативної сторони: чи приведуть кодові тести до відхилення людини, яка насправді є найкращим кандидатом?
Страх сцени
У вас може бути хтось, хто насправді хороший розробник, але дуже нервує це інтерв'ю, і вони, по суті, переживають сценічний переляк. Виконання під тиском певною мірою важливо, але боротьба зі сценічним переляком не є такою ключовою частиною бути програмістом (порівняно з іншими професіями), і було б прикро відкидати того, хто сильно страждає від цього. Це може скластись: якщо людина не зможе відповісти на питання, на яке вони знають, що їм слід відповісти, вони можуть посилитися. Або, як і в цьому питанні , вони відчувають, що не можуть говорити і кодувати одночасно.
пом'якшення наслідків. Почніть з деяких питань, що ознайомлюються з вами про їхню основу, цілі тощо, перш ніж переходити до технічних питань. Можливо, почніть з легших технічних питань, щоб вони набули деякого імпульсу. Не будьте хуй під час інтерв'ю (кайфуючи про крапки з комою тощо).
Це галаслива міра
На цікаві кодові запитання може бути більше однієї правильної відповіді. Якщо одна людина пише правильну відповідь, а інша пише правильну та більш ефективну відповідь, то скільки ваги ви повинні надати цьому?
Якоюсь мірою це нагадує проблему з деякими "головоломками" питань: людина або має розуміння, або ні, і ви отримуєте майже бінарний результат. Інтелект, ймовірно, впливає на ймовірність мати це розуміння, але вибірка лише декількох разів дає тобі міру.
Це мене турбує щодо питань щодо коду (хоча я все ще використовую їх.) Найкраще пом’якшення, яке я можу придумати, - це якнайбільше мати пандус можливих рішень: людина може принаймні написати грубу грубу відповідь або відповідь на частина проблеми. Усвідомлення того, що краще, ніж нічого, є доброю ознакою. Тоді, якщо вони виявлять більше, вони можуть зробити це більш ефективним або більш елегантним кодом. Наскільки це можливо, уникайте задавати запитання, які отримують двійкові відповіді.
Це насправді не репрезентативно
Програмування не є завданням вирішувати десятихвилинні алгоритмічні задачі одна за одною: набагато більше роботи над розумінням та проектуванням великих систем та зосередженням уваги на тривалий період часу, нічого не кажучи про міжособистісні навички. Питання з кодом насправді цього не перевіряють.
Але питання з кодом - це не єдине питання, яке ви збираєтеся задати: ви можете подивитися на їх передумови, посилання на них, роботу з відкритим кодом (якщо такі є), знайти докази стійких зусиль, творчості, міжособистісних навичок.
Знання, як вирішувати невеликі алгоритмічні задачі та як звести їх до коду, є необхідною, але недостатньою умовою: якщо ви не можете вирішити невеликі проблеми і не можете написати нетривіальний код, то все велике мислення в світі не є збирається зробити вас продуктивним розробником.
Хто-небудь міг це вирішити
Ні, мабуть, ні. Як зазначає відомий пост FizzBuzz , проблеми, які ви можете подумати, є тривіальною пасткою не тільки нових випускників, але й людей з багаторічним досвідом роботи в галузі. Я не знаю чому. Або тест коду - це погана міра (яка можлива, хоча я думаю, що це малоймовірно), або вони не дуже сприяли проектам у своєму резюме, або вони багато робили, скопіювавши та вставивши алгоритмічний код (який можливий.)
Варто визнати, що ви дійсно можете багато зробити, не написавши жодного алгоритмічного коду. Люди заробляють багато грошей на додатках, цінність яких полягає у графіці чи логіці бізнесу, а не в тому, що ви можете назвати "програмуванням", і це добре. Але, якщо вам потрібні програмісти, це не дуже добре.
Це може бути не правильно відкалібровано
Якщо ви поставите питання, відповідь може вам дуже здатися легкою. Однак, якщо вам задають будь-яке інше порівнянне запитання, або питання, яке не перекошене у ваших власних інтересах та передумови, це може бути набагато складніше.
пом’якшення: запустіть тести над деякими розробниками, яких ви вже знаєте, і подивіться, як вони працюють. Можливо, хтось із вашої команди, який ви знаєте дуже розумний, матиме проблеми з одним із них, і ви можете подумати про його коригування. Можливо, вони придумають кращу чи іншу відповідь.
Це занадто схоже на дрібниці
Я думаю, що питання коду, безумовно, можуть потрапити до дрібниць, якщо ви наполягаєте на тому, що люди знають напам'ять незрозумілі API, або досконалість синтаксису, або пам'ятати точне визначення нетривіального алгоритму. Всі вони розумні, щоб розібратися в документах, пошуку в Інтернеті чи помилках компілятора, і вони мають невелику кореляцію з реальними знаннями. Навіть не знаючи, де може бути API, - це, мабуть, підказка, яку людина останнім часом не використовував, але це не обов'язково проблема, якщо вони не лежать на своєму резюме.
Тож відповідь на це досить проста: не задавайте тривіальних питань і не зациклюйтесь на дрібницьких помилках. Нагадуйте кандидату, як називається API, або дозвольте їм переглянути; виправити синтаксичні помилки; не перевіряйте, чи люди запам'ятовують визначення даних даних.
Як ти порівнюєш?
Якщо у вас є два кандидати і обидва відповідають на питання, як ви обираєте між ними? Ви можете вибрати того, хто швидше закінчив, але, можливо, там ви почнете збирати зайців над черепахами. Ви можете зробити ще один раунд і задати набагато складніші запитання, але в цьому я і не впевнений. Можливо, ви просто даєте їм обидва A + і намагаєтесь вибрати між ними за іншими критеріями (або намагаєтесь знайти гроші, щоб найняти обох.)
Я можу подумати про те, що важко «кодувати вголос» перед іншими людьми. Мені важко навіть друкуватись з кимось, хто дивиться через моє плече, і я не один. Я помічаю, коли хтось закликає мене до своєї робочої станції, щоб допомогти в чомусь, вони раптом починають робити помилки, вибираючи неправильне заповнення коду, навіть роблячи відверті помилки - жодної з яких вони не зробили б, якби я не сидів там. Чорт, я бачив, як люди починають використовувати меню для операцій вирізання та вставки, тільки тому, що вони були під спостереженням. Це не нормальна поведінка, і кодери, про які я говорю, - відмінні програмісти і до того ж досить розумні.
Нещодавно у мене було інтерв'ю, в якому інтерв'юер запитав мене, як я кодую конкретну операцію, і він сказав: "Просто покажіть мені математику". Ну, я повинен був подумати над проблемою спочатку, перш ніж перейти до математики, щоб змусити мене підшиватись та завивати. Те, що я спершу відклав на білій дошці, бентежило, і я відчував, що втрачаю в той момент. Зрештою, я отримав момент А-ха і знайшов відповідь (насправді, коли мені нарешті прийшло в голову те, що він насправді запитував), але "безлад", який я зробив ще до того, як потрапити, змусив себе почувати себе дуже некомфортно. Тим не менш, я влаштувався на роботу, але якби інтерв'юер був менш терплячим, я б його не мав.
Я думаю, якщо ви даєте респондентам завдання кодування, дайте їм трохи часу, щоб опрацювати його на комп’ютері, можливо, навіть у знайомому їм IDE. Дозвольте їм написати код для вас, а потім поговоріть про нього. Запитайте їх, чому вони робили речі певним чином і чи не може бути кращим інший спосіб. Ви дізнаєтесь більше з цього процесу, ніж попросивши їх (образно кажучи) заглянути в чашку прямо перед вами.
Мінуси: Немає. Будь-який час, який Ви витрачаєте на налаштування ПК, розробку тестування коду та його перегляд, в майбутньому врятує непересічний головний біль.
Плюси: "Довіряй, але перевіряй" - Рональд Реган. Так багато разів я бачив і чув, як люди нарешті відпускають з місця, де в інтерв'ю ви могли б подумати, що ви отримаєте рок-зірку. Доказ - у пудингу; Я хочу побачити, що вони можуть зробити. Він буде представляти те, що станеться, коли ви вкладете час і гроші, наймаючи когось і наклавши на них новий проект.
Мінуси:
Плюси:
Коли я брав інтерв'ю щодо своєї теперішньої роботи, мені дали список запитань, щоб написати код рекрутером. Я був дуже вражений, тому що питання, очевидно, написав хтось, хто глибоко знав SQL, тому він працює обома способами.
Ви дуже хочете, щоб людина написала код на інтерв'ю - ще краще, змусьте їх парувати програму з членом вашої команди протягом X кількість часу (що б ви могли комфортно собі дозволити за час / робочу силу).
Це майже один з єдиних способів визначити, чи може ця людина кодувати чи ні.
Я трохи віддаю перевагу програмуванню пар, оскільки це покаже їх командну роботу, дає їм справжню IDE для роботи і дозволяє їм працювати над «реальною» проблемою (інша людина в парі може провести їх повз будь-яких екологічних особливостей, що опитуваний ніколи не могли розумно знати про це).
Ми почали використовувати цю політику найму і дуже задоволені результатами.
Ви судите птицю за її пір’ям, а програміста - за його кодом.
Коли я розпочав роботу з поточною компанією, над якою працюю, вони попросили мене написати якийсь код C, який генерує або перевіряє біт парності деякого бінарного вводу (залежно від того, чи кодуєте ви чи декодуєте). Це було питання інтерв'ю саме тому, що такі проблеми вирішуються під час роботи. Звичайно, я думаю про те, щоб не перевірити паритет, а скоріше працювати на низькому рівні.
На сьогодні всі відповіді (які я прочитав) не стосуються того факту, що тест Джоеля НЕ (просто) перелік найкращих практик для підприємців, а контрольний список для полегшення вашої оцінки потенційного роботодавця .
Річ у тому, що якщо вони ретельно перевіряють свої кандидати, то, ймовірно, наймають людей, які знають їхні речі ... це означає для вас
замість виправлення помилок після них ...
Я б сказав:
Плюси
Мінуси
Reverseметод чи подібний, або для письмових тестів, такі як" Які аргументи Fooметоду Barкласу ", коли будь-який ідіот міг би Google або використати документацію) на відміну від питань архітектури / дизайну, які показують кандидат може все зробити і вирішити бізнес-проблеми .Одне з профі - це те, що це показує, що хтось має базові знання з програмування чи будь-чого іншого (востаннє, коли я стикався з цим, я був здивований, наскільки базовим було питання SQL). Він також може послужити основою для технічного обговорення, запитуючи, чому кандидат робив таке і таке, і як це можна вдосконалити.
На інтерв'ю потрібен час, який можна використати і для інших речей. Більше того, написання коду на дошці не є природним середовищем, і деякі люди матимуть з цим все більш і менш серйозні проблеми. Це може змусити вас пропустити розробника, який просто нервує без нормальних інструментів чи посилань.
Програмування - це високо технічна майстерність, що має безліч чітких "результатів". Кандидат може або не може їх доставити. Тож немає жодних «мінусів» у питанні технічних питань. Це повністю для того, щоб сказати: "покажіть мені якийсь код для цієї програми або" покажіть мені код програми, про яку Ви ВЖЕ написали ".
Якщо це не робити, це може призвести до такого результату, як: Багатий чоловік опитав репетитора, щоб навчити своїх дітей грати в шахи (як розумову вправу). Вихователь відкрив картату дошку і заговорив про 64 квадрати, але не торкнувся шахової фігури. Натиснувши час, батько все одно найняв вихователя. А вихователь навчав дітей грати в КОНТРОЛИ.