Veeam — это международная IT-компания. Она разрабатывает ПО, которое позволяет управлять данными в облаке и обеспечить их защиту. В компании Михаил Брыксин руководит международной командой разработчиков из четырех человек.
Основываясь на собственном опыте, он рассказал, на что разработчики обращают внимание при проверке тестовых заданий кандидатов. На примере выдуманной задачи и ее проверки в Microsoft Visual Studio он дал советы, которые помогут будущим разработчикам найти работу в IT. Мы записали самое главное.
Иногда тестовое задание показывает больше, чем ваш опыт
Процесс найма у всех IT-компаний проходит по-разному, однако в целом он включает примерно одни и те же этапы. Сначала с кандидатом могут пообщаться по телефону, попросить сделать тестовое задание или провести одно или несколько интервью. Меняется в основном очередность. В Veeam тестовое задание ― это первый этап на пути к вакансии в отделе разработки и барьер к рассмотрению заявки.
На вебинаре Михаил Брыксин рассказал, что оно одинаково для кандидатов на все позиции ― неважно, хотите вы быть junior, middle или senior-разработчиком.
«Суть в том, что по коду всегда можно сказать, есть ли опыт у человека или нет. От джуниора не будут требовать, чтобы были соблюдены все пункты. Если вы идете на джуниора, прислали тестовое задание, оно работает, но где-то есть минусы, ничего страшного. Если вы идете на тимлида или сениора, просматривать ваше задание будут уже совершенно по-другому. В первую очередь, оно должно работать», — рассказывает Михаил Брыксин.
Разработчики хотят видеть знакомый код
Бывает, вы написали тестовое задание, отправили его и думаете, что обо всем позаботились, сделали все правильно. Вы уверены, что вас позовут или хотя бы похвалят. Однако иногда все происходит совершенно наоборот: нет никакого фидбэка, вам говорят, что решение не понравилось, советуют переделать или доработать код. По словам Михаила, мало выполнить задачу, важно выполнить ее определенным образом.
«Нужно сделать не только то, что от вас требуется, но и сделать это так, как проверяющий хотел бы видеть. Все принципы разработки ПО, если мы говорим, например, про С# или Java, одни. Все разработчики хотят видеть знакомый код, обработку ошибок, какое-то завершение», — говорит Михаил Брыксин.
Именно моментам, на которые обращают внимание при проверке, был посвящен вебинар. Разработчик начал с рассказа о том, как разработчики в принципе проверяют тестовое задание.
Будьте внимательны к деталям
«Сначала, когда я только начинал проверять тестовые, проверял все вручную, заходил, собирал проект, запускал его. Но самое ценное — это время. У разработчиков никогда не хватает времени, всегда нужно что-то писать. В общем, все хочется автоматизировать. Поэтому сейчас я проверяю через автоматизированную систему или скрипты», — объяснил он.
Из-за того, что зачастую ваш код может проверять программа, очень важно не допустить какую-то дурацкую ошибку. Например, перепутать значение, которое будет возвращаться по окончании программы. Такая маленькая ошибка может дорого стоить.
Пользуйтесь тем, что уже сделали за вас
«Бывает так, что тестовое задание сложное, и вам необходимо использовать в реализации алгоритма какую-то сортировку или структуру данных ― очередь или список. В тексте задания вас об этом не просят. Вас просят, например, сделать хеширование или написать веб-чат. У вас может возникнуть дилемма: написать это самому или использовать готовое решение. Лучше всего использовать то, что есть в стандартной библиотеке типов. Если в ней нет, можете посмотреть NuGet пакеты. С другой стороны, вы можете, например, написать свою очередь или свой список. И, возможно, он будет хорошо работать и его даже оценят, если он правильно написан. Но когда будут проверять, ваша реализация будет незнакома. Методы будут называться по-другому, а разработчик привык к стандартной системе типов. Если в тестовом задании это не запрещено, лучше использовать готовые решения и стандартные структуры данных», ― объяснил разработчик на примере.
Готовые решения увеличивают функциональность кода и уменьшают вероятность ошибки. Единственное, чтобы убедиться в правильности заимствованной части кода, разработчик советует смотреть на дату его последнего апдейта и количество скачиваний пакета.
«Использование готового пакета покажет, что вы можете найти это решение, то есть знаете, как делают другие люди и умеете работать с чужим кодом», — заключает он.
Сделайте код легко читаемым
По словам опытного разработчика, если проверяющий видит тестовое задание в первый раз, а весь код содержится в одном файле — это сложно для восприятия. Для облегчения проверки кода можно взять на вооружение несколько советов:
- Поддерживайте структуру проекта ― лучше структурировать его логически или, буквально, по папкам.
- Отмечайте ключевые моменты кода комментариями, использовать summary. Они помогают, когда проверяющие либо хотят понять, что в принципе происходит, либо дать обратную связь.
- Делайте анализ кода. Часто бывает, что вы написали много кода и просмотрели его весь, но могли что-то упустить. В этом случае могут помочь средства Visual Studio. Например, достаточно пойти в настройки проекта, там есть вкладка “Code Analysis”, и выбрать анализ кода, а затем выбрать “Microsoft All Rules” и сохранить, советует Михаил Брыксин.
- Продолжайте полировать код, когда он написан: структурировать, разбирать, раскладывать по папкам, проверять.
Еще несколько лайфхаков:
- Не забывайте про обработку ошибок
- Сделайте readMe, TODO и History of commits
- Избегайте рекурсии в коде, переходите на циклы
- Избегайте дубликаций. Их отсутствие — одна из метрик, по которым оценивают код
- Зачастую в самом тестовом задании сказано вкратце описать использованные архитектуру и алгоритмы. Сделайте это
Михаил предупреждает, что тестовые задания могут быть очень разными. Вас даже могут попросить показать аккаунт на GitHub, где лежит код, за который вам не стыдно.
«Качественно выполненное тестовое задание бывает показательнее опыта даже в 10-20 лет. В большинстве случаев оно может сыграть ключевую роль. Я уверен, что эти советы помогут вам получить заветный оффер», — заключает разработчик.
