Зразки коду та інтерв'ю? [зачинено]

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

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

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

Зрештою, вартість нашої компанії та вигода для кандидата від плагіату дуже мінімальні.

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

То що нас відрізняє? Чому так важливо поставити когось перед комп'ютером і змусити їх кодувати злиття даних або факторний калькулятор, іноді без доступу до тих інструментів, якими ми користуємося щодня, як Інтернет? Що не так з ідеєю кодового портфоліо?

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

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

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

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

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

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

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

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

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

Кожне інтерв'ю розробника, яке я роблю, передбачає відвідування дошки, щоб реалізувати вирішення простої проблеми. Однак є правила:

Заявник повинен поговорити через впровадження, як вони це роблять.

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

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

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

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

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

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

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

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

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

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

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

• що зразки легко підробляються

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

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

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