Как подходить к тестовым заданиям: советы от тех, кто их проверяет
Зачем нужны тестовые задания, как их оценивают и как с их помощью хорошо себя зарекомендовать, особенно если вы пытаетесь обойти конкурентов на вакансию Junior? Об этом мы расспросили IT-специалистов, которые в своих компаниях ответственны за проверку таких заданий.
Максим Ковтун, Chief Software Architect в Sigma Software
Процесс найма сотрудников — это воронка, каждый этап которой призван отсеять часть кандидатов. Цель воронки — оптимизировать процесс и затраты на найм.
Представьте, что на входе у вас 100 кандидатов, и вы просто приглашаете каждого на техническое собеседование и потом на повторное с руководителем. Если собеседования длятся по часу и в них участвует по два собеседующих, то вы потратите 400 часов на обработку кандидатов. После собеседований вы понимаете, что у части кандидатов вообще нет нужного вам опыта, часть не владеет нужной технологией, часть не разделяет ваши ценности, часть не может написать код, но на каждого вы потратили по 4 часа.
Возникает вопрос: а могу ли я узнать неподходящих мне кандидатов, потратив меньше четырех часов? Наверное, я могу посмотреть резюме кандидата и понять, есть ли у него нужный мне опыт. Это займет
Если из резюме и общения с кандидатом мы не увидели, что кандидат может писать код, решать задачи, проектировать модули системы, мы даем тестовое задание.
Начинающим программистам мы предлагаем несложные алгоритмические задачи, суть которых обычно сводится к написанию одной или нескольких функций. Это задачи уровня Fizzbuzz. Но как бы удивительно это ни было, все еще попадаются специалисты с немалым стажем, которые не могут решить Fizzbuzz.
Более опытным даем задачи на дизайн классов или структурный дизайн приложения (будет состоять из таких-то проектов, зависимости будут такие, модули будут подключаться динамически/статически, зависимости будут инджектиться вот так-то).
Как оцениваем тестовые работы. Мы стараемся детально указывать в тексте задания критерии оценки. Обращаем внимание кандидатов на то, что важно для нас, указываем, что нужно сделать обязательно, а какие вещи будут плюсом.
В отличие от решения практических задач на собеседовании, где мы больше смотрим на ход мыслей, а не результат, решение тестового задания происходит не в такой напряженной обстановке. А значит, ничто не мешает кандидату решить задачу правильно и полностью. Поэтому при оценке важны корректность и полнота решения.
Также важна эффективность решения с точки зрения алгоритмической сложности, количества кода и затраченного времени.
Дальше мы оцениваем, насколько написанный код близок к коммерческому исполнению, а не просто является лабораторной работой. Здесь мы смотрим на стилистику кода, обработку исключительных ситуаций и ошибок, валидацию аргументов, обработку edge-кейсов.
Если у задачи есть пользовательский интерфейс, будь то веб-страничка или просто консольная программа, смотрим, насколько это дружественно пользователю. Мы не требуем клевый дизайн или юзабилити. Но если программа выводит пользователю какой-то текст, то хорошо, если этот текст будет понятен не только программисту, написан без ошибок и с большой буквы :)
Какие бывают ошибки. Самая распространенная ошибка — это сразу бросаться писать код, не прочитав задание целиком и не вдумываясь в написанное. Доходит до абсурда, когда в требованиях к задаче написано, например, не использовать Linq, а в коде он использован. Или явно требуется представить данные в древовидной структуре в памяти, а вместо этого данные лежат в плоской коллекции. Сделать не так, как явно требуется в задаче, — это грубый фейл. После него сложно воспринимать кандидата позитивно.
Вторая ошибка, которая мешает выполнить задание успешно, — не задавать вопросы. Если что-то в формулировке задачи не понятно или есть сомнения, мы всегда предоставляем кандидату возможность пообщаться с техническим специалистом, который будет проверять тестовое задание. Это не занимает много времени, и лично я такой ход воспринимаю очень позитивно. Для меня это признак того, что для специалиста важно выполнить поставленную задачу, а не просто сделать что-нибудь. В работе эта проблема тоже очень актуальна, поэтому мы обращаем на это внимание.
Как кандидату хорошо себя зарекомендовать. Тестовое задание — это лучшая возможность представить себя. В отличие от собеседования и практической задачи, тестовое задание выполняется без присутствия чужих людей, не в чужом офисе, без стрессовой обстановки и часто без ограничений по времени. Представьте, что вы делаете просто одну из задач на работе.
В тестовой задаче какие-то моменты могут быть условными или не требовать реализации. Обозначьте их явно, напишите комментарий в коде или в письме: «Эту функцию не реализовал специально, так как условием задачи не требуется».
Покажите, каким бы был результат реальной задачи, написали ли бы вы комментарии в коде, покрыли бы вы код автотестами, обрабатывали ли бы ошибки.
Если вы делаете что-то экстра (например, DI контейнер для одного интерфейса), чтобы продемонстрировать, что вы это умеете, то напишите явный комментарий — дабы не казалось, что вы перемудрили. Или напишите: «В задаче такого размера DI использовать контейнер нет необходимости, но если тут будет ..., то я бы его использовал».
Если вы смогли продемонстрировать, что способны решить поставленную задачу и что качество вашего решения и кода соответствует требуемому уровню, то вы дали понять, что можете выполнять нужную работу. И пройти собеседования вам будет на порядок легче, ведь основное вы уже сделали :)
Алексей Стягайло, QA Automation Tech Lead в KeepSolid
Тестовое задание дает возможность получить первое впечатление о том, как человек мыслит, насколько вдумчиво он читает задание и выполняет все его требования перед собеседованием.
По тестовому заданию можно судить, как человек будет относиться к рабочим задачам. Во время собеседования не всегда получается это понять из-за ограниченности времени общения.
Для QA Automation в тестовом задании я описываю определенный user case на одном из наших ресурсов и ставлю задачу написать автотест для этого сценария. Это позволяет сразу проверить умение создавать тест-кейсы, находить элементы и писать автотесты на основании тест-кейсов.
Как оцениваем тестовые работы. Тестовое задание не должно быть очень большим или сложным. Его выполнение должно занимать от силы 4 часа. В первую очередь я проверяю, все ли требования были выполнены, является ли результат работы автотестом или просто набором скриптов.
Какие бывают ошибки. Основная проблема — кандидаты не внимательно читают задание. Если вы взялись за выполнение тестового задания, то внимательно ознакомьтесь с его содержимым. Задайте уточняющие вопросы, так как те, кто будут проверять ваше тестовое задание, хорошо знают, что они хотят увидеть.
Еще одна проблема — не качественное выполнение задания. Например, использование рекордеров для записи сценариев действий в браузере. Если автотест записан с помощью рекордера — это сразу видно. Я такие работы даже не рассматриваю.
Есть еще умельцы, — их мало, но они есть, — которые прибегают к помощи друзей и выполняют тестовое задание не сами. На собеседовании с помощью нескольких вопросов это легко выясняется.
Как кандидату хорошо себя зарекомендовать:
- Внимательно читайте тестовое задание.
- Находите элементы сами. Грамотно написанный XPath (там, где это необходимо) поможет вам выделиться среди других кандидатов.
- Не используйте рекордеры, пишите код сами. На будущей работе вам в любом случае придется это делать.
- Постарайтесь представить ваше тестовое задание как полноценный проект, а не набор скриптов, даже если он будет содержать всего 100 строк кода.
Сергей Филоненко, Tech Lead of Design Department в CHI Software
Тестовое задание нужно, чтобы посмотреть на человека «в поле».
Можно бесконечно восторгаться удачными градиентами его портфолио и читать в CV, что он владеет Sketch на 86%. Но понять, как он думает и думает ли в принципе, можно лишь по тестовому.
Из недавних тестовых на позиции UX-дизайнера: джуниору предлагали придумать новый главный экран десктопного приложения, которое распознает лица. Миддлу давали не самый лучший wireframe мобильного приложения для записи экрана с просьбой улучшить UX и отрисовать UI.
Как оцениваем тестовые работы. Обращаем внимание, насколько кандидат смел и рационален в своей мысли. Проводил ли он ресерч конкурентов, написал ли два абзаца сопроводительного текста, чтобы обосновать свои решения, заморочился ли с презентацией результатов.
Можно кинуть линк на архив, в котором папка с тремя джипегами, а можно собрать прототип в Invision с итерациями между экранами. Однако стоит заметить, что если джипеги в папке окажутся более осмысленными — возьмем первого.
Какие бывают ошибки. Зачастую кандидаты делают тестовые задания в нерабочее время на домашнем лэптопе перед сном или же на работе в обеденные перерывы подходами по 20 минут. Отсюда все беды. Многие недооценивают его важность, особенно если это шестое тестовое за неделю. Нужно больше любви. И внимания.
Как кандидату хорошо себя зарекомендовать. Задача кандидата — показать, что он попытался разобраться в доменной области, составил портрет пользователя, то есть подошел к решению задачи комплексно. Ну и об UI-составляющей не стоит забывать. Все мы визуалы — и надо, чтобы красивенько, выровнено и без lorem ipsum.
Іван Попович, Scrum Master/Senior Software Engineer у Conscensia
Ми проводили різні варіанти інтерв’ю — і на власному досвіді переконалися, що теоретичні навички кандидатів не завжди збігаються з практичними. Тому вирішили розробити невеличке тестове завдання, виконання якого потребуватиме необхідних на нашому проекті навичок і вмінь.
Специфікою нашого завдання є те, що ми не даємо його наперед. По-перше, таке не усім підходить, бо для цього потрібно витратити свій вільний час. По-друге, якщо чесно, то невідомо, хто і яким чином його насправді виконував. Тому ми пропонуємо маленьке тестове завдання, яке потрібно виконати безпосередньо на співбесіді. Для цього залишаємо кандидата самого на 15 хвилин.
Оскільки час обмежений, то завдання має бути простим для розуміння, але показувати глибину знань. Тому ми написали невеликий кусок коду: інтерфейс і клас, який його реалізовує. Цей клас й інтерфейс представляють одну зі структур даних. Вона реалізована синтаксично правильно — щоб кандидат не відволікався на синтаксис та перевірку одруків, але має багато недоліків. Загалом завдання поміщається на одному листку А4.
Кандидату потрібно зробити code review і сказати, чи така програма взагалі працюватиме, що можна зробити інакше, що оптимізувати.
У нас нема окремих завдань на різні позиції, проте помилки й недоліки мають різні рівні складності. Деякі очевидні, деякі потребують застосування глибших знань і досвіду. Ми не даємо різні завдання кандидатом різного рівня, а орієнтуємося на глибину відповідей.
Як оцінюємо тестові роботи. Перед початком роботи над завданням ми даємо кандидату питання для аналізу — свого роду план, на що треба звернути увагу. Наприклад, яка це структура даних, чи буде вона правильно працювати, чи буде коректно працювати в багатопотоковому середовищі, чи правильно вона реалізована з точки зору принципів SOLID, чи відсутні memory leaks.
По цим же критеріям і спілкуємося з кандидатом. Часом трапляються люди, які вражають своїми розгорнутими відповідями. Бували навіть такі, що вказували нам на покращення, на які ми самі не звернули увагу.
Які бувають помилки. Найчастіша помилка — кандидати використовують не весь запропонований час і не заглиблюються в питання. Знайшли
Наше завдання орієнтоване на те, щоб оцінити як конкретні речі, так і побачити ситуацію на більш високому, архітектурному рівні. Не всім вдається зрозуміти, чи буде працювати конкретний метод, і водночас оцінити структуру в цілому і зрозуміти, як варто її покращити — наприклад, розділити на підкласи, виокремити інтерфейси.
Як кандидату добре себе зарекомендувати. Важко придумати золотий алгоритм. Моя порада — уважно читайте завдання. Адже правильне його розуміння — це вже половина відповіді. Після цього розробіть у себе в голові план, як виконувати code review — для прикладу, можна почати від конкретного і рухатись до глобального.
Варто бути уважним до деталей, але не забувати також дивитися на код на вищому рівні — щоб зрозуміти, чи буде зручно іншим користуватися такою структурою даних.
Але ці поради стосуються конкретно нашого завдання. Назагал, треба просто добре розуміти код, критично мислити і вміти реалізувати всі свої ідеї.
Дмитрий Андрусенко, Senior .NET Developer в DataArt Kyiv
Политика давать или не давать тестовые задания зависит не только от компании, но и от конкретного офиса. В зависимости от текущих потребностей и ситуации на рынке эта политика может меняться.
Если по итогам технического собеседования остаются сомнения насчет уровня кандидата, как правило, ему предлагают решить практическое задание.
Обычно тестовые задания на Junior, Middle или Senior-позиции отличаются незначительно. Разница в том, как оценивается результат и на что эксперты обращают внимание.
Большинство заданий универсальны и позволяют изменять перечень технологий, не меняя сути самого задания. Например, одно и то же задание может даваться с требованиями реализовать DAL на ADO.NET, Entity Framework, NHibernate и т. д., в зависимости от того, знание какой технологии вызвало сомнения при устном собеседовании.
Сами задания меняются вместе с требованиями рынка. Сегодня задания охватывают Web, DAL, SQL. Для Back-end разработчика могут быть ограничены требования к UI, либо вообще ограничен скоуп задачи до создания сервиса, методы которого будут проверяться вызовами из простого консольного приложения. Для Front-end разработчика, наоборот, требования по DAL и SQL могут быть сведены до создания стабов, возвращающих предопределенные значения.
Как оцениваем тестовые работы. Оценка во многом зависит от уровня, на который претендует кандидат.
Для Junior-позиции может быть достаточно, чтобы работал базовый функционал (Happy Path). В остальном код, скорее, служит для оценки, как много времени и усилий потребуется, чтобы закрыть критические пробелы в знаниях кандидата и доучить его до уровня Middle.
Для Middle-позиции, помимо работы кода, будут учитываться и его структура, и стабильность работы при отклонении от Happy Path. Наличие серьезных дыр, вроде передачи пароля пользователя открытым текстом в GET-запросе, уже повлияет на конечную оценку кандидата.
Для Senior-позиций дополнительно оценивается работа с требованиями, архитектура, работа с нефункциональными требованиями. При этом вовсе не обязательно, чтобы решение Senior-кандидата содержало больше функционала, чем решение специалиста уровня Middle. Достаточно, если места, требующие дополнительного внимания, будут снабжены комментариями, описывающими при каких условиях и что нужно будет добавить или изменить.
Например, если в задании есть sensitive data, вроде пароля, пин-кода или номера паспорта, то от Senior-разработчика мы ожидаем как минимум уточняющего вопроса о необходимости шифровать эти данные. То есть он должен отнестись к задаче, как к требованиям реального клиента: обнаружить потенциальные проблемные места и предложить решение.
Суть оценки тестового задания сводится к ответу на вопрос: какие риски и с какой вероятностью стоит ожидать при найме этого кандидата на конкретную должность и какова ожидаемая польза от сотрудничества с ним. Именно с этой точки зрения рассматриваются все «косяки» и «классные фичи», обнаруженные проверяющим. Поэтому одна или даже нескольких грубых ошибок — это еще не повод отказать кандидату. Проверяющий только формирует свое мнение по основному вопросу и излагает рекомендации в отчете. Конечное решение принимаем уже по совокупности всех отзывов о кандидате.
Какие бывают ошибки. Во-первых, отсутствие анализа требований перед началом работы. Нужно ли шифровать sensitive data? Нужно ли делать юнит-тесты? Необходимо ли предусмотреть защиту от различных атак: injection, cross-site и других? Если одну и ту же задачу можно реализовать разными способами с разными временными затратами — какой из них выбрать? Как трактовать те или иные требования в постановке задачи?
Просто задав подобные вопросы, можно в разы уменьшить время на написание кода. Как бонус — вместо попытки угадать ожидания проверяющего, можно их просто согласовать. Часто бывает так, что кандидат поднял конкретный вопрос и предложил вариант его решения — тогда проверяющий будет готов снять этот вопрос с повестки и разрешит не тратить время на реализацию решения.
Во-вторых, неправильная оценка объема работ. Иногда кандидаты придумывают дополнительные требования, которых нет в задании. Например, включают в проект IoC, когда он не помогает упростить решение задачи. Или добавляют 100% покрытия юнит-тестами или динамическую локализацию. В таких случаях они в ущерб основному функционалу тратят время на то, что никак не будет оцениваться.
В-третьих, отсутствие элементарной проверки Happy Path перед тем, как отправить задания на проверку. Иногда присланное решение оказывается нерабочим из-за какой-то опечатки, что легко было бы обнаружить, просто запустив код.
Наконец, обфускация кода или просто использование неинформативных имен переменных и методов. Это сильно затрудняет понимание кода.
Как кандидату хорошо себя зарекомендовать. Главное — не бойтесь и не стесняйтесь задавать любые вопросы по заданию еще до начала написания кода. Это сэкономит ваше время и поможет точнее выполнить задание.
Старайтесь не добавлять в задание ненужных допущений и ограничений.
Если не хотите или не успеваете сделать тестовое задание, не стоит браться и потом исчезать бесследно. Лучше сразу отказаться от его выполнения. Так, по крайней мере, вы останетесь в пуле кандидатов на будущие вакансии. Если вы получили задание и пропали, вряд ли вас снова пригласят на собеседование.
Виталий Валявский, Programmer в Luxoft
Компания работает с клиентами из разных отраслей, потому сразу уточню, что на разных проектах и для специалистов разного уровня тестовые задания отличаются. Например, недавно на одном из проектов в сфере энергетики мы проводили собеседования с потенциальными интернами. Чтобы выбрать одного из трех приблизительно одинаковых по уровню кандидатов, мы предложили выполнить тестовое задание. В соответствии с ТЗ написать приложение на UI-движке на выбор — Swing, Java Fx или SWT. Так мы можем оценить способность кандидата выполнить задание в ограниченный срок (3 рабочих дня) и увидеть качество написанного им кода.
Как оцениваем тестовые работы. Каждый член команды, участвующий в техническом интервью, знакомится с заданием. Затем мы коллегиально обсуждаем полученные результаты и принимаем решение.
В случае с интернами мы оценивали, запустилось ли приложение, работает ли оно без сбоев, насколько правильно оно реализовано в соответствии с техническим заданием. Также смотрели, насколько качественно написан код: как сформированы доменные объекты, названы пакеты, классы и переменные, читабелен ли код, отсутствуют ли явные антипаттерны.
Какие бывают ошибки. Чаще всего кандидаты просто не тестируют свой код и не проверяют его на читабельность. Естественно, это встречается гораздо реже при собеседовании более опытных специалистов.
Как кандидату хорошо себя зарекомендовать. Во-первых, проверяйте свою программу на работоспособность. Можно скачать свой проект из системы контроля версий, запустить и проверить его в соответствии с техническим заданием.
Во-вторых, анализируйте свой код на читабельность и не забывайте соблюдать Java code conventions или другие рекомендации к стилю кода.
Алексей Чикалов, Lead Software Engineer в EPAM
Цель тестового задания, как и любого вопроса на интервью — определить, насколько кандидат подходит на текущую открытую позицию, отвечает ли требованиям. Тестовое задание помогает выявить сильные и слабые стороны кандидата, увидеть, как он справляется с анализом требований и решением задач, задает ли вопросы. Помимо качества кода, видны и навыки self-менеджмента — например, стрессоустойчивость. Иногда пара строчек кода скажет о кандидате намного больше, чем полуторачасовая беседа.
Некоторые кандидаты отказываются от прохождения тестового задания — в основном, это специалисты уровня Senior. В таких случаях мы показываем кандидату распечатку с кодом плохого качества. Там нарушены какие-либо базовые принципы: SOLID, YAGNI, DRY, KISS, а также неправильная стилистика кода. Мы просим проанализировать код, рассказать, что он думает о качестве, и предложить способы его улучшения.
Задания зависят от позиции, на которую претендует кандидат. Если это Junior-разработчик и у него нет практического опыта, он должен хорошо разбираться в теории. Такому человеку даем задачу, связанную с базовыми принципами ООП и SOLID. Например, задизайнить какой-нибудь класс или взаимодействие между ними. Классы и требования могут быть разными, но смысл всегда один и тот же.
Кандидатов, которые в резюме указывают опыт с SQL, просим написать небольшой запрос. Например: «Есть продукты и категории. Надо выбрать, в каких категориях есть продукты, в каких нет». Далее возможно усложнение задачи.
Во время интервью на Senior-позицию часто даем задание разработать API согласно архитектурному стилю REST. Просим сохранить сущность с набором полей, вычитать ее, изменить и удалить. Решение этой задачи, как правило, разбивается на три этапа:
- построение URL-запроса и описание методов HTTP-запросов, которые будут использованы, а также проработка возможных ответов сервера на каждый запрос;
- написание класса Controller;
- поиск сущности по множеству ID или по каким-либо критериям — если кандидат справился с предыдущими этапами.
Задание должно быть построено так, чтобы его можно было легко усложнить, если кандидат справляется быстро, или упростить, если у человека возникают трудности.
Как оцениваем тестовые работы. Прежде всего, мы оцениваем то, как ведет себя кандидат, получая и выполняя задание. Конечно же, проверяем качество кода. Смотрим, как он написан, как организован, соответствует ли изначально поставленной задаче.
Для Senior-специалистов мы часто ставим ограничение по времени — проговариваем это во время постановки задачи. Скажем, 10 минут. Для нас важно наблюдать за тем, как человек распоряжается этим временем, следит ли за ним вообще, что делает, когда не успевает. Если человек уходит в себя, мы просим озвучивать мысли вслух, чтобы понять — мы просто теряем время или человек готовиться к прыжку, чтобы за последние несколько минут выдать готовое решение.
Не обязательно предоставлять готовое решение на 100%. Иногда достаточно иметь хорошую идею и четко ее проговорить.
Какие бывают ошибки. Первая ошибка возникает, когда кандидат не хочет выполнять тестовое задания, но при этом не отказывается от него. Так мы просто тратим время, хотя человек мог с самого начала сказать, что он не рассчитывал на тест. Конечно, выполнение задания добавляет кандидату баллов. Но отказ от выполнения тестового не влияет на решение о сотрудничестве, если перед этим кандидат себя отлично показал.
Вторая ошибка — кандидаты не задают уточняющие вопросы и сразу приступают к заданию, не выяснив дополнительную информацию. Дело в том, что одна из целей тестовых заданий — это диалог с кандидатом. Так мы мотивируем дополнительное общение. При этом когда человек выполняет тестовое задание, мы не выходим из комнаты. Он может задавать нам вопросы на протяжении всего времени, уточнять правильно ли он понял и делает ли то, что от него хотят.
Также мы обращаем, насколько кандидат следит за временем. Особенно это касается уровня Senior и выше. Контроль времени демонстрирует, как человек будет вести себя на реальном проекте в условиях ограниченного временного ресурса. Попросит ли он уменьшить scope, дать больше времени или просто завалит сроки. Очень часто кандидаты даже не фиксируют свои отведенные 10 минут. Они ждут от нас сигнала о завершении времени.
Некачественный код на тестовом задании — еще одна грубая ошибка. Некоторые утверждают, что это случайность при прохождении теста, а на продакшене все будет намного лучше:) Опыт показывает обратное. Стилистика написания и оформления кода — это почерк программиста, он формируется годами. Если код на интервью написан неважно, для нас это сигнал об уровне компетенций.
Как кандидату хорошо себя зарекомендовать. Если вы не намерены выполнять тестовое задание — скажите об этом сразу. Не тяните время, делая вид, что вы думаете и решаете, если изначально настроены негативно.
Не стесняйтесь задавать уточняющие вопросы до и во время выполнения задания. Например, полезно будет спросить: «В правильном ли направлении я двигаюсь?».
Всегда следите за временем. И, конечно, за качеством кода. Пишите такой код, который вы готовы заделиверить заказчику. Даже, если этот код на листке бумаги.
Андрей Бондарь, Team Lead Java/Full Stack в Intersog
На нашем проекте, как правило, мы не даем тестовое задание кандидатам. Хотя на других проектах в нашей компании клиенты часто сами подготавливают тестовое для кандидатов.
Ребятам уровня Middle и Senior я не предлагаю тестовое. Думаю, с моей стороны это не этично :)
Лучше поговорить тет-а-тет и дать задание вживую — например, попросить спроектировать архитектуру, определить узкие места.
На позиции Junior Java аппликантов слишком много, и мы предлагаем им тестовые задания. Вот несколько типовых примеров:
- реализовать простой веб-сервер с REST API, который использует какие-то сторонние открытые данные (например, RSS с погодой, курсами валют и прочее) и делает базовые операции с этими данными;
- написать свое файловое хранилище по типу RapidShare, S3, MegaUpload с функциями загрузки файлов, скачиванием, удалением старых файлов;
- написать поиск по очень большому текстовому файлу.
Как оцениваем тестовые работы. Суть и цель тестового — определить, как кандидат владеет фреймворками и понимает, насколько оптимально и быстро будет работать код. Также смотрим, как организован код, аккуратен ли он, есть ли тесты и документация.
Какие бывают ошибки. Плохо, если код написан в стиле «спагетти аль денте»: очень длинные и нечитабельные куски, много сырых элементов, мусора, не обработанных ситуаций. Сюда же — плохое логирование и отсутствие комментариев.
Как кандидату хорошо себя зарекомендовать. Не делайте ошибок :) И всегда пишите сопроводительное письмо с описанием того, что не успели сделать, что бы добавили и улучшили.
Владимир Кондратьев, Senior JavaScript Developer в Acceptic
Мы даем тестовые в 60% случаев технических вакансий, чаще всего — по инициативе заказчика. Но бывают и исключения, когда тестовое предлагаем мы. Обычно это происходит, если в ходе технического интервью кандидат не смог продемонстрировать уверенное владение требуемым стеком или достаточный уровень понимания предметной области. В этом случае тестовое — это дополнительная возможность убедить в своей компетентности и уровне подготовки.
Если говорить о цели, то это обычно оценка хода мыслей кандидата как специалиста в рассматриваемой предметной области. Нам нужно понять, как он декомпозирует проблему, как подходит к подбору инструментария для решения, как относится к построению кода, как именует переменные и расставляет запятые, в конце концов.
Тестовое задание должно быть из реальной жизни, никаких пузырьковых сортировок и прочих сферических коней в вакууме. Само задание — это небольшой законченный кусок функциональности, который решает задачу. Например, аутентификации, агрегирования какого-то куска данных, либо же банально функционирующий прототип небольшого приложения. При этом функциональность должна быть максимально примитивна, чтобы у кандидата не возникла мысль, что ему скинули таск из реального проекта и вынуждают поработать бесплатно.
Если говорить о примерах, то это может быть такая задача:
«Сделайте одностраничное приложение с аутентификацией и страницей дашборда. Приложение должно содержать два типа пользователей: администратор и простой пользователь. Внешний вид и набор виджетов дашборда зависит от типа пользователя. На странице дашборда нужно сделать список каких-либо сущностей, которые можно добавлять, удалять и редактировать. При этом список сущностей пользователя доступен только автору, а администраторам доступны все сущности всех пользователей и еще что-нибудь ценное для конкретного проекта».
Далее идет список дополнительных условий. Например:
- страница дашборда должна находиться на одном и том же роуте для обоих типов пользователей;
- для фронтенда использовать фреймворк Х (дополнительно можно наложить ограничения на список зависимостей);
- для аутентификации использовать secure cookie и т. п.
Как оцениваем тестовые работы. Если это тестовое задание для кандидата уровня Junior, то приложение должно работать. При этом громадный плюс, если в коде будет прослеживаться какая-то логика построения приложения.
У Middle разработчика всё должно работать без ошибок и быть более или менее читабельным.
Для квалификации выше Middle приложение должно заработать одной командой, содержать только стабильные и безопасные зависимости и выглядеть абсолютно обслуживаемым.
При проверке лично я обращаю внимание на читабельность и однородность кодстайла, на присутствие хотя бы примитивных паттернов и количество подключенных зависимостей. Также немаловажным при оценивании является полнота выполнения задания. Будет плюсом, если кандидат дополнил решение мелочами, типа confirm-диалогов для подтверждения необратимого действия, удаления или logout’a или favorite.ico.
Ну и конечно же, в современных реалиях, хорошим тоном считается, если готовое тестовое задание предоставлено через ссылку на репозиторий GitHub, GitLab, Bitbucket c простейшим Readme.
Какие бывают ошибки. Самая частая ошибка — когда в задании есть ограничения на использование фреймворка, а в решении видно, что кандидат абсолютно не знает официальные рекомендации по best practices применения этого фреймворка и пытается переизобрести колесо. Также общая оценка кардинально снижается, если кандидат ради простейшей задачи подключает объемную библиотеку и использует один единственный метод, функцию или класс из нее. Кандидат обязан знать, что есть в «коробке».
Чтобы проверить себя перед отправкой выполненного задания, удалите с вашего компьютера всё, что относится к законченному проекту: очистите БД, удалите экспорт переменных окружения, очистите систему от intermediate контейнеров. Склоньте свой проект с репозитория и проделайте всё, что вы описали в Readme, чтобы запустить свой же проект — гарантирую, вы будете удивлены.
Как кандидату хорошо себя зарекомендовать. Делайте задание не для «дяди», а для себя лично, как будто вы — заказчик фичи и вам с этим работать в будущем: развивать, поддерживать и обслуживать. Но тут также есть скользкий момент — не нужно продумывать абсолютно все нюансы, просто сделайте своё задание на
И еще одно. Не нужно бояться совершать ошибки — ошибаются все и постоянно. Просто учитесь на своих ошибках и продолжайте делать то, что вы умеете. Те, кто заинтересован, всегда увидят в вас то, что им нужно.
Алена Мельник, консультант по рекрутингу, GlobalLogic
Мы используем технические тестовые задания преимущественно при отборе кандидатов на подготовительные курсы GL BaseCamp и на позиции trainee в проекты компании. Цель тестовых заданий — «первичный отсев», который включает в себя проверку базовых технических навыков, мотивации, способности выполнять задание в указанный срок.
Менее распространенная практика — тестовые задания для опытных специалистов. Как правило, мы прибегаем к этой практике только по запросу клиента, когда ему критически важно увидеть, как человек пишет код. Или же в случае удаленного интервью, когда рациональнее предложить тестовое задание, чем просить на ходу решать какие-то задания по скайпу. Но подобная практика — скорее, большое исключение из правил.
Для отбора на подготовительные курсы GL BaseCamp предлагаем кандидатам тесты с вариантами ответов. Для проведения тестов мы используем собственную платформу GL TestBench. У кандидата есть определенное время на выполнение всех заданий, проверка результатов происходит автоматически.
Но куда больше мне нравится тесты в формате маленьких задачек. На их выполнение, как правило, нужно не более 2 часов — то есть один продуктивный вечер. Наши технические эксперты составляют задачи таким образом, чтобы на их проверку уходило не более 5 минут времени.
Как оцениваем тестовые работы. Любые тестовые задания мы оцениваем только вместе с обратной связью от наших технических специалистов. Например, даже в случае успешного выполнения тестов на GL TestBench, мы приглашаем лучших кандидатов на личную встречу, чтобы обсудить с ними выполнение их заданий.
Какие бывают ошибки. На общий результат влияет несвоевременное выполнение тестовых заданий и несоответствие результатов заданий поставленным условиям, которые всегда важно читать очень внимательно.
Как кандидату хорошо себя зарекомендовать. Как следует из вышеизложенного, нужно выполнять задание своевременно и согласно требованиям.
