20 ошибок при выполнении тестовых заданий

Перевод статьи «10 Mistakes you probably also made in your coding task for a new job» (1 часть, 2 часть).

Тестовое задание и ошибки, которые вы допускаете

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

И вы отсылаете свое решение в компанию. Некоторое время спустя вам приходит ответ. Вы практически уверены, что там во вложении черновик контракта!

Однако, прочитав письмо, вы не верите своим глазам. Компания просто поблагодарила вас за участие, но выбрала кого-то другого.

Что же пошло не так и что можно исправить на будущее? Давайте посмотрим!

Ошибка 1: вы недостаточно внимательно прочли задание

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

Ошибка 2: вы начали реализовывать решение без полного понимания задачи

Итак, вы перечитали задание несколько раз, но у вас все равно остались вопросы? Задайте их представителю компании, с которым контактируете. Нет ничего зазорного в том, чтобы задать вопрос! Напротив, это покажет компании, что вы заботитесь о качестве продукта и не хотите зря отнимать их время.

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

Ошибка 3: вы не используете Git (или любую другую систему контроля версий)

Пожалуйста! Пожалуйста! Не отсылайте по электронной почте ZIP-файл на 60 Mb со всей папкой node_modules. OSX не любит распаковывать node_modules, поэтому человек, который должен просматривать ваш код, может даже не получить шанса взглянуть на него.

Используйте лучше Git. Если вы с ним не знакомы, это хороший повод познакомиться. Он используется во многих компаниях, так что рано или поздно его все же придется изучить.

Также стоит начать использовать GitHub. Поместите туда свой код и пошлите ссылку на него представителю компании, с которым вы контактируете. Он будет вам благодарен, ведь таким образом:

  1. Ваш zip-файл не попадет в корпоративный спам-фильтр.
  2. Вы не превысите лимит размер а файла (да, даже в 2019 году есть кое-какие ограничения для электронной почты).
  3. Ваш код можно будет просмотреть, не скачивая.
  4. Вашим кодом можно будет легко поделиться с другими разработчиками компании (обычно код просматривает не один человек).

Ошибка 4: проблемы с сообщениями коммитов

Вы используете Git и это здорово. Не ограничивайтесь одним-единственным коммитом. Компании будут просматривать ваш git log, чтобы почитать сообщения коммитов.

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

Поэтому делайте коммиты почаще и пишите хорошие короткие сообщения.

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

Ошибка 5: вы забыли файл .gitignore

Это возвращает нас к ошибке №3. Если у вас нет файла .gitignore, в Git добавится все содержимое папки. В результате вы опять будете отсылать node_modules. Но они никому не нужны!

Вот хорошая подборка файлов gitignore: https://github.com/github/gitignore

Ошибка 6: у вас нет файла README.md или он плохо написан

Github выведет файл README.md и он будет показываться на главной странице вашего репозитория. Напишите продуманный контент для этого файла. Например, укажите название задачи или поясните, что делается в ходе выполнения кода. Возможно, стоит добавить зависимости (это приводит нас к следующему пункту).

Ошибка 7: у вас нет инструкции к просмотру вашего решения

Да, я могу просмотреть ваши скрипты и, если их названия хорошо продуманы, смогу понять, какой из них нужно запустить. Но все же, пожалуйста, напишите в README.md, как все настроить, чтобы я мог запустить ваш код.

Ошибка 8: у вас нет рабочей ссылки на ваше задание

«Но зачем она нужна, вы же только что сказали написать инструкцию по запуску?» – спрашиваете вы себя. Ссылка на задание облегчит работу ревьюера. Ему не придется битый час разбираться, делает ли ваш код именно то, что указывалось в задании.

Поместите текст задания где-нибудь в интернете, чтобы была возможность дать ревьюеру ссылку. Heroku, GitHub pages, aws или Azure – это лишь несколько бесплатных сервисов, которые могут помочь вам в этом.

Ошибка 9: старые и/или ненужные файлы в репозитории

Не держите в репозитории папку _old или подобные ей. Что я, как ревьюер, должен делать с этой папкой? Нужно ли в нее заглядывать? Зачем она здесь? Я в растерянности. Так что, пожалуйста, удаляйте старые и ненужные файлы из своего кода.

Удаляйте старые файлы

Ошибка 10: отсутствие сопроводительного письма

Не отсылайте пустой email со ссылкой на ваш репозиторий. Это может показаться очень грубым. Ведь получатель вашего письма – живой человек. Напишите что-то вроде: «Здравствуйте, ХХХХ, как ваши дела? Надеюсь, все благополучно. Вот ссылка на мое выполненное задание [ссылка]. Хорошего дня. С наилучшими пожеланиями, Майкл».


До сих пор мы фокусировались на том, как подготовить и отослать интервьюеру код для оценки. Давайте продолжим разбор ошибок, которые вы, возможно, допускаете при выполнении заданий. Особое внимание уделим при этом самому коду.

Ошибка 11: вы пренебрежительно отзываетесь о чем-либо

«JavaScript это легкотня!» Не знаю, почему люди так говорят, но это довольно распространенное высказывание. В принципе, можете заменить JavaScript на что угодно. Всё, что ни возьмите, будет и легко, и сложно одновременно. Водить машину легко, но водить болид Формулы-1 сложно.

Подобные высказывания показывают интервьюеру, что вы претендуете на некую элитарность. Что я имею в виду? Это похоже на вопрос, задаваемый новичками в программировании: «Какой лучший способ делать XYZ?». Нет ни лучшего, ни единственно верного способа делать что-то. Точно так же нет и лучшего языка.

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

Но вы всего лишь изучили один инструмент. Т.е., вы научились пользоваться молотком-гвоздодером, но не кувалдой. Да, вам теперь будет легче научиться обходиться с кувалдой. Но оба молотка имеют свои плюсы и минусы.

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

Ошибка 12: у вас нет тестов, хотя в спецификациях вакансии сказано, что нужно уметь писать тесты

Показать, что вы умеете писать тесты, это всегда хорошая идея. Они не обязательно должны быть совершенными. Вам не нужно иметь 100% покрытие кода. Напишите какие-то простые тесты для вашего основного функционала. Вполне вероятно, что это вам зачтется как большой «плюс».

Ошибка 13: ваш код не разделен на файлы

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

Лучше разделить код на несколько файлов поменьше. Такой подход будет полезен и в дальнейшем, когда вас примут на работу. Никому не нужен код, в котором вы разбираетесь, а другие члены команды – нет.

Пожалуйста, разбейте ваш код тестового задания на части. Это очень облегчит жизнь ревьюеру.

Ошибка 14: отсутствие комментариев в коде или излишние комментарии

Такое я наблюдал не только у начинающих разработчиков. Комментарии в стиле: // Цикл для переборки массива, при том что следующая строка – Array.forEach(). Привет, Капитан Очевидность. Было бы лучше, если бы приводилось более абстрактное описание того, что делает этот цикл, например: // подготовка данных для отправки через AJAX. Это помогло бы людям понять назначение данного отрывка кода.

Комментарии в коде

Ошибка 15: беспорядочное расположение строк кода

[code]const array = [ 1, 2];

array.forEach((a ) =>{
a = a+ 1;

console.log(a) ;
}
);[/code]

Такой код очень тяжело читать, а кроме того, это показатель небрежной работы. Сегодня у нас есть такие инструменты как eslint и prettier. Функционал для приведения кода в порядок встроен в каждом крупном редакторе или IDE, в крайнем случае можно установить соответствующий плагин/расширение. Пожалуйста, пользуйтесь всем этим.

Ошибка 16: плохо подобранные имена переменных

[code]const b = true;
const a = [];[/code]

Такой код непросто читать. Имена переменных ничего не говорят читателю о том, что такое это b. Было бы гораздо лучше использовать другие имена:

[code]const isReady = true;
const listOfPersons = [];
[/code]

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

Ошибка 17: вы оставляете закомментированный старый код

Я вижу это довольно часто и до сих пор не понимаю, зачем люди так делают.

У вас файл на 100 строк кода, 70 из которых – старый код, который вы просто закомментировали, а 30 строк – собственно, вся реализация решения. Надо ли мне как интервьюеру читать этот старый код? Что он должен мне сказать? Что сначала вы пошли неверным путем? Так никто не совершенен и безупречный код с первой попытки не пишется.

Поэтому, пожалуйста, удаляйте старый код. Если мне нужно будет увидеть, делали ли вы рефакторинг этого кода, я должен иметь возможность увидеть это в git-коммитах с соответствующими сообщениями.

Ошибка 18: вы не проверили, запускается ли ваш код

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

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

Обязательно проверяйте свой код

Ошибка 19: вы изменили что-то в коде и не проверили, остался ли он рабочим

У нас есть задание для full-stack разработчиков, в котором мы просим их сохранить переменные в базе данных. Они могут самостоятельно выбирать базу данных, а также схему и способ сохранения переменных. Мы просто говорим, что это должно быть сделано.

Вот так и случается, что люди меняют код, а после внесения изменений не проверяют его заново. Например, меняют схему или испытывают ее с маленьким файлом и т. п.

Опять-таки, прежде чем отослать свой код, проверьте, что весь его функционал по-прежнему работает, и попробуйте что-то сломать. Никто не говорит, что нужно отследить каждый edge case, но обратите внимание хотя бы на самые распространенные вещи, которые может сделать пользователь.

Ошибка 20: вы не подготовились к техническому собеседованию

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

Она из целей всего процесса отбора кандидатов это проверка, подходите ли вы команде и являетесь ли вообще командным игроком. И в целях этой проверки больший упор делается на ваши soft skills, а не на умение программировать. Поэтому, пожалуйста, прочтите свой собственный код, прежде чем отправляться на собеседование.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх