Тест кодування до скринінгу - як довго це розумно? [зачинено]

EDIT

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

Заради тих, хто все ще зацікавлений, я намагаюся дати короткий виклад дискусії, що виникла з цього питання:

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

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

Однак я знайшов усі ваші відповіді цінними і дякую за те, що поділилися.

ОРИГІНАЛЬНА ПОСТ

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

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

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

Чи доцільно від компанії очікувати, що я проведу 4 години, працюючи над їхнім манекеном, у вільний час, ще до того, як вони привітаються зі мною? (рекрутер надіслав мені тест кодування)

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

Що я прийшов до висновку з цією компанією, це те, що:

1) Моя мотивація не є хорошою, і, ймовірно, вони шукають когось іншого

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

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

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

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

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

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

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

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

Ні, не типово , чому ви вирішуєте їхні проблеми безкоштовно? (4 години)

1 година типова для тесту на програмування. У минулому нашому тесті програмування було 4 питання. Перші 3 запитання займали 1/2 години, останні 1/2 години. Ми також дали тест існуючим найманим працівникам в будинку, щоб переконатися, що ми опинилися в очікуваному терміні, і тест був справедливим і скоригованим відповідно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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