Як оцінюють тестові завдання джуніор-розробників: секрети компаній
Відкриваємо завісу таємниці для всіх, хто хоче потрапити на наступний етап співбесід
Кількість вакансій для кандидатів без досвіду за пів року зросла майже вдвічі. В топі позицій для джуніорів, на які відгукуються найбільше: Java- та JavaScript-розробники.
Загальна конкуренція на Djinni цього літа — 9,16 кандидата на одну вакансію. Серед розробників-початківців — 168.
robot_dreams відхилить для вас завісу — як насправді компанії оцінюють тестові завдання розробників і що робити, аби саме вас покликали на фінальне інтерв’ю до компанії мрії.
Як оцінюють тестові
Майже всі опитані нами компанії зазначають, що відбір серед джуніорів-розробників відбувається набагато складніше, ніж серед більш досвідчених кандидатів, адже конкуренція досить висока.
Ось приклад, який вигляд має ТЗ на тестове завдання для розробника від геймдев-компанії Stan's Assets from KAPPS:
• завдання має бути виконане за час, менший ніж робочий день (до 8 годин);
• чітко сформульоване завдання, вказано основний критерій оцінювання, тобто на які аспекти звертатимуть увагу більше, а на які — менше;
• вимоги до графіки мінімальні, але не відсутні, адже візуал формує цілісну картину;
• прохання додати до виконаного ТЗ супроводжувальний лист, де кандидат може зазначити й пояснити обрані ним рішення;
• виконання ТЗ сприймають як звичайний таск із таск-трекера, що видав PM.
Коли тестове отримане, у компанії звертають увагу на:
- Супроводжувальний лист (зазвичай це wiki в репозиторії).
- Проєкт у репозиторії:
- Проєкт з ТЗ має бути на будь-якому сервісі контролю версій, наприклад, GitHub.
- Як зроблені та підписані коміти.
- Базовий розгляд Unity-проєкту в редакторі:
- Завантажують та перевіряють проєкт на помилки компіляції, errors та warnings у консолі.
- Проєкт повинен мати базовий цикл роботи: початок, core feature, екран перемоги/програшу та рестарт (автоматичний або мануальний).
- Звертають увагу і на структуру проєкту (папки та файли). Рев’ю контенту та його менеджменту: сцени, префаби та інші асети.
- Код-рев’ю:
- Стиль коду та конвенція, Assembly Definitions, name spaces.
- Назви класів, назви методів, модифікатори доступу, виділені абстракції.
- Ініціалізація проєкту, залежності між сутностями, вирішення залежностей.
- Оцінка реалізації скриптів що напряму пов’язані з головною фічею ТЗ.
- Створення списку питань щодо проєкту, якщо остаточне рішення стосовно кандидата ще не сформовано:
- Сам факт виконання поставленого завдання.
- Чистота коду.
- Алгоритмічна складова рішення. До прикладу, наскільки ефективно кандидат формує вибірку об’єктів і опрацьовує їх.
- Розуміння того, як працює Unreal Engine. Наприклад, чи знає кандидат про існування неймінг-конвенцій, чи розуміє він базові ієрархії та призначення класів фреймворку, які мають або можуть бути задіяні під час виконання завдання.
В іншій геймдев-компанії, Pingle Game Studio, також зазначають, що передусім важливий вже сам факт виконання поставленого завдання, а також чистота коду, алгоритмічна складова рішення та розуміння того, як працює Unreal Engine:
«Нам важливо побачити, наскільки ефективно кандидат формує вибірку об’єктів і опрацьовує їх. Що стосується Unreal Engine, нам цікаво, чи знає кандидат про існування неймінгу конвенцій, чи розуміє базові ієрархії та призначення класів фреймворку, що мають або можуть бути задіяні під час виконання завдання».
В компанії Unidatalab (розробляють ШІ-рішення) зазначають, що стосовно тієї частини вимог, яка сформульована однозначно, важливо, щоб їх було виконано на 100 %, оскільки це моделює виконання реальних завдань і демонструє уважність та організованість розробника.
До того ж у компанії звертають увагу:
- на якість та загальну читабельність (readability) коду;
- правильне використання інструментів мови, дотримання стилю (code style).
Тобто чистота коду — must have?
«Чистий код — дуже важливий аспект. Стан коду — це показник того, наскільки з кандидатом буде комфортно працювати іншим девелоперам команди. Можливо, якби нашою специфікою було виконання тестових завдань для партнерів індивідуальними розробниками, то чистота коду не мала б жодного значення». Едуард Корогодов, UE Developer у Pingle Game Studio
У Stan's Assets from KAPPS у поняття чистого коду закладають:
- Однаковий стиль коду та конвенції у проєкті. Точно наявні чіткі правила і вони виконані для назви класів, інтерфейсів, методів, полів, властивостей, однакові відступи тощо. Не так важливо, які саме ці правила, а важливе їх дотримання. Тим паче наразі будь-яка сучасна IDE з коробки має базову конфігурацію та підсвічує будь-які невідповідності.
- Наявність самодокументованого коду, тобто постійні коментарі не потрібні. Загалом компанія не проти коментарів у коді, якщо це якісь специфічні імплементації (наприклад, математичні моделі, закони) чи важливі місця. Але це не означає, що коментарі мають бути усюди, адже це тільки погіршить читабельність коду.
- Використання принципів та популярних патернів, що підходять для проєкту. Адже створення велосипедів для кожного завдання ускладнить як читабельність коду, так і його підтримання іншими розробниками.
- Чіткі та зрозумілі залежності сутностей. Код «чистий» з погляду його зв'язності у проєкті. Які патерни було використано для вирішення залежностей і яким чином.
В Unidatalab також наголошують, що чистий код є індикатором розуміння самим автором реалізованого ним рішення. Доволі часто розробники вдаються до практики копіювання готових рішень або хаотичних змін у коді, доки не буде отримано бажаного результату, без цілісного розуміння написаного ними коду.
Чи треба робити щось понад зазначеного у тестовому?
В Unidatalab зазначають, що виконати умови ТЗ важливо, але певна невідповідність допустима, якщо інші аспекти це компенсують. У будь-якому разі, якщо тестове прийняли, то на технічному інтерв’ю буде змога обговорити його та запропонувати якісь покращення — що піде в плюс під час оцінювання кандидата.
У Stan's Assets from KAPPS кажуть, що важливо чітко виконати ТЗ, але водночас додаткові пропозиції можуть схвалювати:
- Відповідність виконаного завдання вимогам ТЗ — це оцінка, наскільки людина може зрозуміти поставлене завдання і виконати його в тому вигляді, якого очікують. Тобто це саме те, чим більшість часу займається розробник на проєкті.
- Виконання всього ТЗ є достатнім, бо якби в реальному завданні треба був творчий підхід, це б обов’язково зазначили.
- Пропозиція поліпшення завдання імпонує. Це показує залученість кандидата у завдання, його зацікавленість. Тут важливо не перемудрити або навіть узгодити це покращення перед виконанням. Адже у реальному проєкті зазвичай, якщо поставлено А, то ніхто не очікує там побачити Б, якщо це не було узгоджено з менеджментом.
Якщо покращення має якийсь «спортивний» сенс (наприклад, реалізація має покращений перфоманс, порівняно з базовим рішенням, але не погіршує спосіб його використання) або має ціль з реального життя (наприклад, кандидат заздалегідь подбав про можливість розширення функціонала і зробив додаткову декомпозицію і більш гнучко розподілив відповідальності у системі), то це виділить кандидата з-поміж інших.
Едуард Корогодов, UE Developer у Pingle Game Studio, зазначає, що виконання, яке перевищує вимоги, — це сигнал, що до кандидата треба придивитися уважніше.
Наприклад, якщо кандидат показав певні знання в рендері, ігровій логіці або інших аспектах, і вони перевищують рівень, на який кандидат претендує, то це привід сфокусуватися на таких моментах під час співбесіди. Це може впливати навіть на те, як швидко кандидат отримає наступний апгрейд в ролі вже нового працівника.
Софт-скіли перевіряють навіть під час тестового
«Вміння кандидата пояснити свої думки та зрозуміти поставлене завдання — це фундаментальний критерій оцінки. Адже джуніор — це спеціаліст, з яким інші розробники в компанії будуть проводити особливо багато часу: допомагати розвиватися, вчитися, робити рев’ю, тобто дуже багато спілкуватися». Stan's Assets from KAPPS
Софт-скіли показує не тільки чітке виконання завдання. Стежте, щоб коментарі до коду були достатньо детальними, технічними та зрозумілими. А коли називаєте класи, інтерфейси та методи, використовуйте англійську, щоб код не перетворився на комічний текст.
«Кандидат має розуміти, що таке добре документований код. Під час перевірки тестових завдань коментарі в коді — це важливий показник, адже за ним можна зрозуміти, наскільки кандидат відчуває потребу і доцільність коментування свого коду для полегшення роботи команди», — каже Едуард Корогодов, UE Developer у Pingle Game Studio.
Розробник зазначає, що екстремумами основних помилок зазвичай є або повна відсутність коментарів, або коментування кожного рядка коду. Коментарі мають бути, але доцільні.
В Unidatalab також очікують, що код буде self-documented, тобто буде зрозумілим сам по собі та не потребуватиме документації. Втім, якщо надано додаткові коментарі, це не буде мінусом.
Чи можливо отримати другий шанс
Інколи буває так, що тестове могло бути виконане неідеально, але кандидатам дають другий шанс. Як стати таким кандидатом? У нашому опитуванні думки компаній розділилися 50/50 — ті, хто майже завжди дає другий шанс, і ті, хто продовжує пошук серед інших претендентів.
У Stan's Assets from KAPPS кажуть, що ставити хрест на кандидаті не хочеться ніколи:
«Усі люди помиляються, тому, якщо ми приходили разом з кандидатом до того, що ми також якось негативно повпливали на якість виконаного ним завдання (наприклад, воно було поставлене нечітко) — ми змінювали завдання або проводили додатковий дзвінок, зважаючи на всі поправки».
Pingle Game Studio також дуже лояльні до джуніорів і зазначають, що давали не лише другий, а й третій шанс:
«Зазвичай таке трапляється, коли ми бачимо цікаве виконання, яке максимально наближене до коду, який за якістю не поступається такому, що пройде рев’ю в прод. Але при цьому, наприклад, допущено помилки в інших місцях. Тоді, залежно від характеру цих помилок, ми застосовуємо підхід код-рев’ю, коли лід вказує на помилки та надсилає код на доопрацювання з певними коментарями».
А якщо є сумнів, що коментарі ліда були незрозумілими або занадто абстрактними, і це призвело до повторного відбракування коду, то компанія готова надати кандидату і третій шанс:
«Ми ніколи не надаємо відповідь, як-от «Все погано, людина нам не підходить». Ми чітко фіксуємо всі помилки, через які не впевнені у кандидаті, добираємо список ресурсів і надаємо всю цю інформацію, щоб у людини була можливість якомога швидше спробувати виконати тестове завдання повторно після вивчення рекомендованих ресурсів. Тож другий, третій, четвертий тощо шанс — це те, що надається завжди, відмінність тільки в рекомендованому часі між тими шансами».
В Unidatalab та ще одній ШІ-компанії Competera зазвичай інша практика. У компаніях зазначають, що тестове завдання — один з первинних фільтрів, і якщо кандидат його не посилив, то кандидатуру не розглядатимуть. Втім, у компанії кажуть, що це не означає, що у майбутньому не може бути повторних спроб.
Поради для джуніорів від компаній
«Не вважайте, що зроблений за туторіалом проєкт — це гарантія знань. Розбирайте імплементацію семплів, які доступні у маркетплейсі. Використовуйте туторіальні проєкти винятково для натхнення або підказок. Натикайтеся на свої помилки, вивчайте і виправляйте їх. Це дасть фундаментальні знання і розуміння, а копіювання туторіальних проєктів — ні». Едуард Корогодов, UE Developer у Pingle Game Studio
Поради для джуніорів-розробників від Stan's Assets from KAPPS:
- Якщо починаєте вчити нову технологію чи стек, обов’язково розв’яжіть прикладну задачу. Адже будь-яка реальна задача підкине вам безліч цікавих запитань і проблем, аніж готовий туторіал чи курс. А ще краще — викладіть розв'язання цієї задачі у Git.
- Спробуйте проаналізувати, чи легко ви знаходите спільну мову з людьми, як реагуєте у складних ситуаціях. Спробуйте покращити свої софт-скіли, щоб на співбесіді ви були на одній хвилі з інтерв’юером та легше будувався діалог.
- Об’єктивно оцінюйте особисті навички, щоб розуміти свої сильні та слабкі сторони. Краще знати меншу кількість технологій у своєму стеку, але володіти ними більш професійно, ніж мати в резюме величезний стек, знаючи про них лише базові речі.
- Беріть участь у джемах та змаганнях з розробки ігор та застосунків. Цей досвід надасть вам багато переваг, цікавих знань, нових корисних знайомств та можливість бути поміченим крутими компаніями.
Також, якщо плануєте йти саме в геймдев, Stan's Assets from KAPPS радять вивчати мову програмування C#. Це фундамент, на якому потім набагато легше будувати свої знання щодо більш специфічних технологій. Це не означає, що джуніор повинен розуміти усі тонкощі. Але маючи ці знання, він зможе спиратися на них і легше вибудовувати причинно-наслідкові зв’язки.
В Unidatalab додають: не намагайтеся вразити інтерв’юерів — чи в тестовому завданні, чи на співбесіді. Чесну відповідь «не знаю» або «не впевнений» сприйматимуть набагато краще, ніж спробу продемонструвати знання там, де їх немає.
І зайвий раз не хвилюйтеся :) Адже софт-скіли є важливим критерієм в оцінці кандидата, і якщо вам вдасться приємна і невимушена розмова, то це вже буде 50 % результату.
