Как оценивают тестовые задания джуниор-разработчиков: секреты компаний
Открываем занавес тайны для всех, кто хочет попасть на следующий этап собеседований
Количество вакансий для кандидатов без опыта за полгода выросла почти вдвое. В топе позиций для джуниоров, на которые больше всего отзываются: 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 % результата.
