Тестовое задание, пожалуй, является самым неприятным этапом собеседования. Это связано с тем, что чаще всего предлагаемые задачи рутинные и отстраненные от реальности. Кроме того, компании часто предоставляют тестовые задания множеству кандидатов, а когда один из них принимает оффер, другие делают тестовые задания в стол, из-за чего еще больше не хочется их делать, тем не менее иногда их приходится делать.

Просматривая свои старые тестовые задания и тестовые задания кандидатов, которых я собеседовал, я увидел много однотипных ошибок и решил написать статью, о том, какие чаще всего встречаются ошибки и как их можно избежать.

Почему это важно? Сейчас на рынке начинающих разработчиков довольно большая конкуренция, и поэтому с каждым годом становится все сложнее выделяться. Эти простые правила помогут вам сделать свое тестовое задание чуточку лучше и, возможно, получить оффер мечты.

Статья в первую очередь рассчитана на начинающих разработчиков, однако может быть и опытные разработчики, смогут найти в ней что-то интересное.

Внешний вид Git репозитория

Как говорится - "Встречают по одежке, а провожают по уму". Над этой одежкой мы и поработаем в первую очередь.

README.md

Первое, что мы видим, попадая на страницу репозитория - структуру файлов и Readme File, если он есть. И что же можно с ним такого сделать ?

1. Если там есть какой-то базовый темплейт, например от бутстрапа проект с помощью различных CLI, замените его на самописный и укажите там требования к системе, которые нужны, чтобы развернуть ваше тестовое задание, например версию python/node и как нужно правильно разворачивать ваш проект.

2. Хорошим тоном будет простенький итог вашей работы. Это поможет проверяющему убедиться, что вы выполнили все требования, а также может помочь в будущем при демонстрации проекта кому-либо еще. Например вы будете показывать этот проект, вместо другого тестового, которое предлагает сделать вам другая компания.

3. Кратко опишите, что не было сделано и почему, чтобы проверяющий не лазил и не искал несуществующего кода.

4. Красиво оформите заголовки/ссылки и тд в соответствии с правилами markdown, если вы не дружите с markdown разметкой, можно использовать редакторы с WYSIWYG controls, чтобы упростить себе жизнь.

Оформление commit messages в Git

Commit messages вошедшие в историю :)

Я считаю это просто легендарно. Однако когда вы делаете тестовое задание, это - первое о чем стоит позаботиться, потому что проверяющий может зайти в историю коммитов, посмотреть как вы ведете работу, как вы именуете коммиты, что вы в них добавляете и сформировать из этого какое-то общее представление о вас, в качестве командного игрока(мы же все делаем проекты с помощью систем контроля версий).

Тут всегда есть резонный вопрос: зачем мне чистая история коммитов, если я один в проекте и все знаю ?

Ответ прост: структурный подход это хорошо. Даже в небольших проектах сохранение четкой истории коммитов может оказаться полезным. Проекты имеют свойство масштабироваться и мы не всегда помним, когда и что делали, а также к проекту может присоединиться еще кто-то и ему будет проще работать с проектом, в котором у commit messages есть какая-то семантика.

Самый простой способ сделать свои commit messages красивыми и содержательными - использовать Conventional Commits - тык. Они помогут вам кратко и лаконично описывать свои изменения и тем самым сделать историю более информативной.

Удаление лишних файлов из репозитория

Очень часто встречается история, что кандидат забывает удалить папку dist/build или какие-то тестовые файлы, системные файлы(например .ds_store на mac).

В репозитории не должно быть никаких лишних файлов. Всегда создавайте файл .gitignore и добавляйте в него все файлы, которые не нужны в репозитории.

Использование Git flow или любой другой модели ветвления

В работе часто применяются различные модели ветвления. ИМХО для тестового это в большинстве случаев будет оверхед, но если вы хотите выделиться или просто хотите сделать все по красоте, то это отличный способ, почитать можно вот тут - тык, тык1.

Deploy тестового задания

Если есть возможность задеплоить ваше тестовое задание, то обязательно стоит это сделать:

1. Экономия времени проверяющего(тем самым вы повысите его лояльность, код можно посмотреть и в репозитории, а клонировать репозиторий и разворачивать его у себя никто не хочет, особенно, когда тестовых много).

2. В дальнейшем вы сможете демонстрировать готовый продукт, например на другом собеседовании.

3. Можно выделиться на фоне других кандидатов, которые не задеплоили свое тестовое(хоть и не большой, но плюсик в карму).

Код

Тут все зависит от конкретного языка программирования, но существуют базовые правила, которые должны соблюдаться всегда:

• Соблюдение определенных style guides и паттернов принятых в технологии, например google style guide, код должен быть отформатирован и выглядеть опрятно.

• Код должен быть читаемым, не должно быть моментов, когда нужно долго думать, чтобы понять, что вы сделали.

• Семантический нейминг файлов/переменных, важно чтобы можно было сразу понять, где и что у вас лежит и зачем необходимо.

Рассмотрение корнер кейсов

Очень часто в тестовых не описано все, что должен сделать кандидат, и в каком-то смысле кандидат должен доработать его сам. По моему опыту люди очень часто делают то, что не очень важно в рамках тестового, например делают какие-то косметические улучшения UI, но при этом, не делают такие вещи как, отлов ошибок через try/catch, не пишут различные валидации, хотя это относится к главному функционалу тестового.

Совет заключается в том, чтобы оценить, какова главная цель тестового задания и что примерно ожидается от вас со стороны проверяющего. Максимальное внимание, стоит уделить корнер-кейсам ключевого функционала. Например, если это верстка интернет магазина, предусмотреть пустой экран состояния для кейса, когда с бекенда пришла ошибка вместо списка товаров.

Соответствие вашего тестового задания техническому заданию

Перед отправкой тестового на проверку, стоит с чистой головой пройтись по пунктам и проверить, что все сделано. Часто во время разработки замыливается глаз и мы не видим, что чего-то не хватает или что-то не работает, и в связи с этим упускаем из внимания какие-то мелочи.

Обязательно проверяйте, что вы ничего не забыли. Если есть какие-то вещи, которые вы осознанно не сделали/сделали иначе, обязательно опишите это в readme/комментариях, чтобы проверяющий понимал, что вы не просто забили. Также хорошей практикой является хотя бы описать ход решения задач, которые вы не сделали.

Итого

Я постарался коротко сформулировать все основные моменты, которые очень часто встречались в моей практике в тестовых заданиях кандидатов и из-за которых они оценивались хуже, чем могли бы быть оценены. Надеюсь я смог сделать твое тестовое чуточку лучше:)

Если статья показалась вам интересной, то у меня есть Телеграм Канал, где я пишу про новые технологии во фронте, делюсь хорошими книжками и интересными статьями других авторов.