Чи варто виконувати тестові завдання. Думки розробників

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

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

Аргументи проти

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

Тестові завдання, відірвані від життя

Олександр Левінсон, ASP .NET Developer

У 2014 році, коли почалась війна, я втікав з Донецька і втратив роботу. Досвіду в мене багато: я почав програмувати в 15, а зараз мені 50. Я оселився в невеликому місті, став шукати роботу віддалено, і на той час це було викликом.

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

Іноді тестове дають «приблизно на 4 години», але коли робити його на совість, то не факт, що вистачить 2–3 дні. Навіть у тому, що ти знаєш, бувають речі, на які спочатку не звернув уваги. Ніхто не може сказати, що вміє все. З’являються нові мови, технології, підходи. Був випадок, коли відповів, що можу взятися за завдання, але виконуватиму його довше, бо треба розібратися в кількох незнайомих технологіях. На мої умови погодилися, але вже наступного дня HR запитала, коли буде робота. Я відповів, що, мабуть, вже ніколи, раз такий підхід. На мою думку, ІТ в Україні сьогодні — це переважно «галерна промисловість», власники компаній не завжди зацікавлені в хороших фахівцях. Часто вони шукають просто певний набір навичок, аби «веслувати далі».

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

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

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

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

Дивні аргументи в інтерв’юерів

Анна, Middle .NET Developer

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

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

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

Коли пізніше та компанія захотіла дати мені офер, але «на інших умовах» (типу я не дотягую до бажаної зарплати), хотілося сміятися в голос. Ввічливо відмовилася.

Роботодавці та кандидати можуть обманювати

Тимофій Воробйов, Senior freelance PHP Developer

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

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

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

Невелике завдання краще пропонувати виконати в реальному часі, ніж давати його додому. Особливо в умовах, коли деякі початківці роблять їх, як в університеті: знаходять фахівця, у якого немає грошей, і пропонують йому виконати завдання замість себе. У мене був схожий випадок. На співбесіду прийшла дівчина, яка претендувала на позицію адміністратора вебсайту. Їй необхідно було володіти базовими навичками HTML. Резюме було хороше, але коли я запропонував написати на місці простенький HTML-код, вона відмовилася. Сказала, що завжди працювала з якимсь онлайн-редактором, який те робив сам, а тому не розуміє, навіщо їй цим займатися. Це очевидно був блеф«.

Це приниження для програмістів

Артем Комісаренко, Software Developer у Zultys

У 2009 році, коли почалася фінансова криза, я опинився без роботи. Досвіду в мене було років зо два, довелося відсилати резюме куди тільки можна. Пам’ятаю, в одній з компаній тестове було елементарне, на рівні «продемонструвати володіння мовою і стандартною бібліотекою». Я вилизував його кілька годин, надіслав і отримав у відповідь: «Погано». Коли спробував перепитати чому, мені відповіли, що там є memory leaks. Їх там не було, та в мене є певні здогадки, чому так подумали, але який сенс сперечатися? Я взагалі доволі гоноровий: доводити, що не верблюд, тим, кого не поважаю, мені не цікаво. І це ж мої потенційні майбутні колеги, я хотів би у них чогось повчитись, а не оце ось все.

Другий епізод із тестовим трапився в офісі. Я тоді жив у Харкові та поїхав у Київ на інтерв’ю нічним потягом. Він приїздив рано, тож я поблукав трохи містом перед інтерв’ю. Співбесіда була дуже «гарячою» і тривала дві години, якщо не довше. Я бачив, що сподобався, ми багато сперечалися і говорили, як раптом виявилося, що в них ще є тестове, яке треба виконувати в офісі. Не дуже складне, але об’ємне — на кілька годин. Причому я такого ще не робив: треба було читати документацію, розбиратися, а потім писати. У місті на ніч я залишатися не планував, тож пішов пообідати, а коли повернувся і сів за комп’ютер, зрозумів, що абсолютно виснажений через співбесіду, тиняння містом, нічний переїзд і взагалі оце все. Відмовився та поїхав додому.

Коли я шукав роботу наступні рази, у 2012 та 2013 роках, моє резюме вже було цікавішим і позиції фільтрував. Усіх з тестовими я відправляв у кінець списку, до якого так і не доходив. Нині я вважаю тестові завдання елементом приниження програмістів-початківців. Коли тобі кажуть «ми вам передзвонимо», а насправді зворотного зв’язку не дають. Крім того, тестові ще й неефективні, якщо дивитись з боку тих, хто наймає. Я сам проводив співбесіди й розумію, що коли ви не Google і людина погодилася виконувати тестове, значить, її більше ніхто не хоче брати, що є поганим знаком.

Іноді тестове дають в офісі компанії, як було в мене, але тоді на результат може вплинути хвилювання чи втома. Водночас часто причиною звільнення з роботи є вигорання через погані умови праці чи конфлікт, а тут ви людину садите на кілька годин «педалити» як на екзамені. Звісно, побачити, як людина пише, варто. Для цього можна давати невелику задачку, на пів години прямо на інтерв’ю, але треба пам’ятати, що коли хтось приїхав з іншого міста чи прийшов на співбесіду з роботи, то може бути загальмованим і це нормально. Найбільше ж люди, як на мене, розкриваються під час розмови про попередні проєкти: що там було цікавого, перед якими труднощами поставали тощо. Є, звісно, патологічні брехуни, та їх небагато, вони видають себе на деталях. Зрештою, є випробувальний термін і звільнити ФОПа взагалі не проблема.

Аргументи за

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

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

Добре для тих, хто боїться співбесід

Ігор Янішевський, Software Developer в Eyeo GmbH

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

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

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

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

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

На мою думку, тестові необхідні розробникам усіх рівнів. На співбесідах ставлять типові питання, їх можна вивчити, а коли людина приходить на роботу і в неї від початку все складається погано через те, що ніхто не перевіряв, як добре вона пише код чи взаємодіє з іншими — такого нікому не хочеться. І що з того, що у резюме написано Senior? Сьогодні сеньйорами стають у 23. Попередня компанія могла підвищити спеціаліста до цього рівня, лише щоб продати клієнту, а не через відповідний досвід. Я і сам так робив: підписувався сеньйором у своєму резюме, якщо мав цей статус у минулій компанії, хоча може й на надто дотягував. Звісно, так не всюди, але явище досить поширене. Та й сеньйори бувають різними, все одно потрібні тестові.

Тестові — це досвід, що можна вказати в резюме

Денис Гришко, Junior Front-end Developer

У мене було багато тестових, за півтора місяця я відгукнувся на понад 250 вакансій. Усі зробити я не міг, тому обрав найцікавіші. Я знав, що основою є JavaScript, і розумівся на одному з фреймворків — React. Та на ринку популярні ще два — Vue.js та Angular, тому подавався і туди. Як на мене, якщо знаєш основу, з усім можна розібратись. У таких випадках я просто просив трохи більше часу. Для мене це був виклик, вихід із зони комфорту.

Спробувавши, я вже записував собі в резюме, що вмію працювати з тими технологіями. Чому ні? Якщо застосовував їх на практиці, значить, орієнтуюся і можна зазначити це. Сьогодні багато людей боїться подаватися на вакансії, бо надто багато критеріїв та вимог. У сучасних реаліях ідеального кандидата не знайти. Тому якщо розумієш, що на 50–70% це твоя вакансія, то варто відгукнутися. А за тестовим уже зрозумієш, зможеш працювати чи ні.

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

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

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

Не факт, що, якби я про себе не нагадував, мене б не забули. І тепер усім раджу: коли надіслали резюме, завжди намагайтеся взяти контакт, бажано прямо телефонувати.

Шанс потрапити у професію

Василь Жук, Senior Back-end Developer у Digital Pulp

Якби не тестове, я б не потрапив у професію. Так, я з дитинства цікавився комп’ютерами, на третьому курсі створив перший сайт. Робив сайт і для Могилянки, де вчився, але просто тому, що міг. Коли ж вчився на фінансиста і почав шукати першу роботу, то й не знав, що можу зайти в серйозний ІТ-світ. Вперше мені це підказали на співбесіді в конторі, що займалася впровадженням ERP, системи управління підприємствами. Фінансовий тест я завалив, але на інтерв’ю звернули увагу на мій досвід програмування і запропонували спробувати себе програмістом.

Я пропустив це повз вуха та надумав піти у тестувальники — у багатьох моїх друзів вийшло. Та коли прийшов найматися, голова ІТ-відділу сказав: «Слухай, ми можемо взяти тебе тестувальником за 800 баксів на місяць, але душа в тебе лежить до іншого, тому в результаті матимемо нещасного програміста». Та круто, але як бути з тим, що я не маю професійної освіти? Він мені відповів, що якщо складу тестове завдання, то нікого це не хвилюватиме.

Так я вперше дізнався про тестові завдання і те, що вони важливіші за диплом. Це освіжило мені голову і я знайшов роботу за день, успішно пройшовши чотири співбесіди. На першій мені не сподобалось: там були молодші за мене типи, які ставили питання, на які я не знав відповіді. Коли їхав на другу співбесіду, загуглив. Виявилося, це були технічні питання, теорія. Сьогодні я вже знаю, що це не надто хороший підхід до підбору людей. Друга співбесіда була у компанії, де в корпоративній культурі закладені зустрічі, на яких розробники одне одного навчають. Хтось освоїв нову технологію — розповів іншим. Хлопчина, який мене інтерв’ював, був фанатом своєї справи. Він розумів, що я не маю бази, а тому моє тестове було таким: він мене питав, що б я робив, якби був інженером. Коли я чогось не знав, то здогадувався. Це було схоже на колоквіум, і мені сподобалось.

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

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

Тестові бувають різні. Можуть попросити за допомогою рекурсії написати піднесення числа в степінь — це легко загуглити, але такої можливості немає. А буває і завдання на день-два, коли треба зробити цілу програму. Колись читав історію хлопця, якому як тестове завдання запропонували створити 3D-змійку, повноцінну гру, де можна перемикати камеру в першу особу змійки та спостерігати за нею з різних ракурсів. Усе це прикольно, але звучить підозріло. Потім хтось може розмістити цю гру на App Store, тож хлопець сказав «до побачення».

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

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

Ще один підхід — запропонувати описати архітектуру (або підхід) під конкретний кейс. Мені цей варіант подобається, коли я сам інтерв’юю. Комбінуючи код, за допомогою «гугла та якоїсь матері», програмувати можна легко, а розробити архітектуру для нестандартної задачі — це вже інша річ. Висновок: джуніорів можна перевіряти за знаннями API, мідлів — за вмінням алгоритмізувати, а сеньйорів — за побудовою архітектури".

Все про українське ІТ в телеграмі — підписуйтеся на канал редакції DOU