Как приготовить тестовое так, чтобы оно понравилось даже самому привередливому проверяющему
Тестовое задание, пожалуй, является самым неприятным этапом собеседования. Это связано с тем, что чаще всего предлагаемые задачи рутинные и отстраненные от реальности. Кроме того, компании часто предоставляют тестовые задания множеству кандидатов, а когда один из них принимает оффер, другие делают тестовые задания в стол, из-за чего еще больше не хочется их делать, тем не менее иногда их приходится делать.
Просматривая свои старые тестовые задания и тестовые задания кандидатов, которых я собеседовал, я увидел много однотипных ошибок и решил написать статью, о том, какие чаще всего встречаются ошибки и как их можно избежать.
Почему это важно? Сейчас на рынке начинающих разработчиков довольно большая конкуренция, и поэтому с каждым годом становится все сложнее выделяться. Эти простые правила помогут вам сделать свое тестовое задание чуточку лучше и, возможно, получить оффер мечты.
Статья в первую очередь рассчитана на начинающих разработчиков, однако может быть и опытные разработчики, смогут найти в ней что-то интересное.
Внешний вид Git репозитория
Как говорится — «Встречают по одежке, а провожают по уму». Над этой одежкой мы и поработаем в первую очередь.
git
README.md
Первое, что мы видим, попадая на страницу репозитория — структуру файлов и Readme File, если он есть. И что же можно с ним такого сделать ?
Если там есть какой-то базовый темплейт, например от бутстрапа проект с помощью различных CLI, замените его на самописный и укажите там требования к системе, которые нужны, чтобы развернуть ваше тестовое задание, например версию python/node и как нужно правильно разворачивать ваш проект.
Хорошим тоном будет простенький итог вашей работы. Это поможет проверяющему убедиться, что вы выполнили все требования, а также может помочь в будущем при демонстрации проекта кому-либо еще. Например вы будете показывать этот проект, вместо другого тестового, которое предлагает сделать вам другая компания.
Кратко опишите, что не было сделано и почему, чтобы проверяющий не лазил и не искал несуществующего кода.
Красиво оформите заголовки/ссылки и тд в соответствии с правилами markdown, если вы не дружите с markdown разметкой, можно использовать редакторы с WYSIWYG controls, чтобы упростить себе жизнь.
Оформление commit messages в Git
Commit messages вошедшие в историю :)
Pust' u vas ne bolit zhivot
Poprawki
Я считаю это просто легендарно. Однако когда вы делаете тестовое задание, это — первое о чем стоит позаботиться, потому что проверяющий может зайти в историю коммитов, посмотреть как вы ведете работу, как вы именуете коммиты, что вы в них добавляете и сформировать из этого какое-то общее представление о вас, в качестве командного игрока (мы же все делаем проекты с помощью систем контроля версий).
Тут всегда есть резонный вопрос: зачем мне чистая история коммитов, если я один в проекте и все знаю ?
Ответ прост: структурный подход это хорошо. Даже в небольших проектах сохранение четкой истории коммитов может оказаться полезным. Проекты имеют свойство масштабироваться и мы не всегда помним, когда и что делали, а также к проекту может присоединиться еще кто-то и ему будет проще работать с проектом, в котором у commit messages есть какая-то семантика.
Самый простой способ сделать свои commit messages красивыми и содержательными — использовать Conventional Commits — тык. Они помогут вам кратко и лаконично описывать свои изменения и тем самым сделать историю более информативной.
Удаление лишних файлов из репозитория
Очень часто встречается история, что кандидат забывает удалить папку dist/build или какие-то тестовые файлы, системные файлы (например .ds_store на mac).
В репозитории не должно быть никаких лишних файлов. Всегда создавайте файл .gitignore и добавляйте в него все файлы, которые не нужны в репозитории.
Использование Git flow или любой другой модели ветвления
В работе часто применяются различные модели ветвления. ИМХО для тестового это в большинстве случаев будет оверхед, но если вы хотите выделиться или просто хотите сделать все по красоте, то это отличный способ, почитать можно вот тут — тык, тык1.
Deploy тестового задания
Если есть возможность задеплоить ваше тестовое задание, то обязательно стоит это сделать:
Экономия времени проверяющего (тем самым вы повысите его лояльность, код можно посмотреть и в репозитории, а клонировать репозиторий и разворачивать его у себя никто не хочет, особенно, когда тестовых много).
В дальнейшем вы сможете демонстрировать готовый продукт, например на другом собеседовании.
Можно выделиться на фоне других кандидатов, которые не задеплоили свое тестовое (хоть и не большой, но плюсик в карму).
Код
Тут все зависит от конкретного языка программирования, но существуют базовые правила, которые должны соблюдаться всегда:
Соблюдение определенных style guides и паттернов принятых в технологии, например google style guide, код должен быть отформатирован и выглядеть опрятно.
Код должен быть читаемым, не должно быть моментов, когда нужно долго думать, чтобы понять, что вы сделали.
Семантический нейминг файлов/переменных, важно чтобы можно было сразу понять, где и что у вас лежит и зачем необходимо.
Рассмотрение корнер кейсов
Очень часто в тестовых не описано все, что должен сделать кандидат, и в каком-то смысле кандидат должен доработать его сам. По моему опыту люди очень часто делают то, что не очень важно в рамках тестового, например делают какие-то косметические улучшения UI, но при этом, не делают такие вещи как, отлов ошибок через try/catch, не пишут различные валидации, хотя это относится к главному функционалу тестового.
Совет заключается в том, чтобы оценить, какова главная цель тестового задания и что примерно ожидается от вас со стороны проверяющего. Максимальное внимание, стоит уделить корнер-кейсам ключевого функционала. Например, если это верстка интернет магазина, предусмотреть пустой экран состояния для кейса, когда с бекенда пришла ошибка вместо списка товаров.
Соответствие вашего тестового задания техническому заданию
Перед отправкой тестового на проверку, стоит с чистой головой пройтись по пунктам и проверить, что все сделано. Часто во время разработки замыливается глаз и мы не видим, что чего-то не хватает или что-то не работает, и в связи с этим упускаем из внимания какие-то мелочи.
Обязательно проверяйте, что вы ничего не забыли. Если есть какие-то вещи, которые вы осознанно не сделали/сделали иначе, обязательно опишите это в readme/комментариях, чтобы проверяющий понимал, что вы не просто забили. Также хорошей практикой является хотя бы описать ход решения задач, которые вы не сделали.
Итого
Я постарался коротко сформулировать все основные моменты, которые очень часто встречались в моей практике в тестовых заданиях кандидатов и из-за которых они оценивались хуже, чем могли бы быть оценены. Надеюсь я смог сделать твое тестовое чуточку лучше:)
Если статья показалась вам интересной, то у меня есть Телеграм Канал, где я пишу про новые технологии во фронте, делюсь хорошими книжками и интересными статьями других авторов.
