Досить часто (~20% в Україні) компанії, що розміщують вакансії для розробників програмного забезпечення вимагають виконати тестове завдання. Тому я вирішив висвітити цей момент, оскільки ставлюся до подібних вимог переважно негативно.
Мій досвід
Я працював у декількох продуктових та аутсорсингових компаніях на позиціях Ruby Expert, консультантом, Team/Tech Lead, Application Architect та Solutions Architect, усі з яких передбачають проведення співбесід та побудову команд. Також я провів близько сотні співбесід та проходив близько пари десятків співбесід і тому вважаю, що маю достатній досвід для того, аби писати на цю тему.
Чому я вважаю тестові завдання анти-патерном?
- Із ~50 співбесід, що я проводив до того, як зрозумів, що тестові завдання – це дурня (так, усвідомлення цього зайняло досить багато часу) лише п’ятеро людей погодилися на виконання досить простого тестового завдання. Тестові завдання банально відсіюють кандидатів, які не бажають гаяти час на неоплачувану роботу.
- Тестові завдання досить синтетичні і тому не відображають повною мірою майстерність кандидатів та їх здатність виконувати реальні, значущі для бізнесу завдання з розробки ПЗ.
- Тестові завдання – це карго культ. Дуже багато компаній дають тестові завдання та проводять співбесіди у той чи інший спосіб просто через те, що звідкілясь дізналися, що так роблять у Google, Facebook, Apple, Microsoft, … Вони копіюють без розуміння наративу та проблем, які стоять за тими чи іншими процессами найму у потужних та розпіарених компаніях. Крім того, мало хто з них може запропонувати заробітню платню у такому ж розмірі. Іншими словами, більшість компанії займають повною дурнею.
- Варто зазначити, що у більшості західних країн звільнити працівника досить складно та затратно. Через це вони перестраховуються через створення більш складних процесів перевірки кандидатів. Такі практики, зрозуміло, не є релевантними для України, де більшість розробників працевлаштована як фізичні особи – підприємці, звільнення яких відбувається елементарно і за необхідності день у день.
- Досить рідко буває так. що технічний стек компанії цілком співпадає з технічним стеком кандидата. У такому випадку компанії дають тестове завдання через те, що не бажають інвестувати у розвиток працівників та бажають аби вони вивчили ту чи іншу нову для себе технологію у свій власний час. Виконання таких завдань може затягнутися на тиждень, або навіть два тижні неоплачуваної роботи і без жодної гарантії працевлаштування. Якщо компанія знайде кандитата, який вже має досвід, наприклад, з Ruby on Rails, то ви отримаєте відмову, навіть якщо маєте більший досвід розробки загалом та освоїли новий для себе фреймворк лише за декілька днів.
- Тестові завдання маєть незрозумілі критерії оцінки. Наприклад, одного разу я виконав одне тестове завдання просто тому що воно здалося мені досить цікавим. Я витратив власний вихідний день, а потім чекав на відповідь півтора тижні аби отримати відповідь (далі пряма цитата) “Отримала відповідь від команди, на жаль, на даному етапі ми не можемо запропонувати рухатись далі за результатами завдання, оскільки представлене рішення не відповідає вимогам якості команди. Одне з зауважень, те що деякі частини задачі краще було б реалізувати простішим способом.” без жодних детальних пояснень. Досить часто рішення приймаються на основі власних суб’єктивних вподобань, і без врахування того, що стиль/підхід може бути підігнано під час парного програмування чи т.з. code review.
- Вірогідність того, що вам нададуть розгорнуту відповіді з коментарями до коду дуже мала. Лише від одного розробника я чув позитивний відгук про відповіть на тестове завдання і це був той кандидат, який проходив співбесіду і отримував тестове завдання від мене. Усі мої знайомі з якими я спілкувався з приводу проходження ними співбесід були не задоволені якістю зворотнього зв’язку.
- Є велика вірогідність, що тестові завдання дають для затягування часу, аби компанія мала час на пошук більш вдалого кандидата, поки підходящий кандидат знаходиться на гачку – тестовому завданні, а не проводить співбесід з іншими компаніями, які не вимагають виконання тестового завдання.
- Дуже часто компанії поводяться не етично та влаштовують співбесіди не заради найму, а заради вивчення ринку та конкурентів. Тестові завдання у такому випадку – це просто додатковий засіб розвідки чи маскування.
Що замість тестових завдань?
Раніше я давав досить прості тестові завдання, але їх мало хто брався виконувати та ще менше поверталося з рішеннями. Я зазвичай давав одне з двох наступних тестових завдань: реалізація структури RadixTree та назвемо це Монте-Карло симуляцією для парадоксу Монті Голла коли кандидат не мав нічого продемонструвати на Github.
Особисто для мене значно кращим показником майстерності, спроможності самостійно щось вивчати і проектувати та захвату від програмування є наявність бажано декількох репозиторіїв у публічному доступі. В решті решт, якщо розробник не здатен вирішити програмуванням навіть власних проблем, то з чого тоді можна зробити висновок, що від здатен вирішити чужі?
Отже, моя порада розробникам, що шукають роботу, наступна: Створюйте публічні репозиторії з т.з. pet-проєтами, PoC для ідей власного бізнесу, власні бібліотеки, фреймворки чи стеки технологій та надавайте посилання на них тим, хто проводить співбесіди, а на вимогу чи прохання виконати тестове завдання відповідайте відмовою, якщо тільки виконання тестового завдання не оплачується як робота.
А порада тим, хто проводить співбесіди наступна: цінуйте час інших людей та запитуйте їх про приклади коду, якими ті можуть похизуватися. Відкритий код надасть вам значно більше інформації про кандидата, аніж виконання будь-якого тестового завдання.
Залишити відповідь