Организации, занимающиеся исследованиями и разработками, используют различные подходы к техническому собеседованию в рамках своих процессов набора персонала.
Компания BigPanda, в которой я работаю, практикует домашнее программирование, чтобы помочь определить качество и техническую пригодность кандидата. < br /> После того, как задача рассмотрена и ее уровень достигнет необходимой планки, проводится собеседование, на котором кандидат имеет возможность представить свою работу, объяснить свои дизайнерские решения и ответить на широкий круг вопросов.
Цель сообщения - не обсуждения того, лучше ли этот процесс, чем другие, поскольку бесчисленное количество других блогов, обсуждений и обсуждений уже прошли ниже и выше.
В течение последних месяцев, в рамках моей ответственности как интервьюера, я проверил значительную часть заданий и провел много личных собеседований после проверки. Хотя каждая реализация отличается от других, часто допускаются повторяющиеся ошибки и игнорируются важные темы.
Этот пост написан, чтобы помочь кандидатам избежать этих ловушек и выделить несколько моментов, которые ищет специалист по проверке заданий.
Заявление об ограничении ответственности: каждое задание по кодированию сосредоточено на определенных областях и преследует свои конкретные цели. Я попытался собрать общие общие проблемы и заблуждения, которые не зависят от языка и структуры.
📇 Первое впечатление: задание - ваша визитная карточка
Прежде чем углубиться, я хотел бы выделить общие рекомендации.
Для рецензента задача, которую вы отправили, отражает ваши навыки и образ мышления самым непосредственным образом.
Для меня это говорит о том, что больше о кандидате, чем его / ее резюме и профиль в LinkedIn. Это похоже на учетную запись GitHub, когда вы участвуете в проектах с открытым исходным кодом.
Принимая вызов, не забывайте о времени и усилиях, которые вы вкладываете в улучшение и защиту своего резюме или учетных записей в социальных сетях.
👍 Это ДОЛЖНО работать!
Для большинства читателей это может показаться очевидным, но на самом деле многие материалы не выполняются.
Лично я, когда сталкиваюсь с ошибкой при первой попытке запуска, я всегда проверяю, могу ли я быстро ее решить, прежде чем отклонять назначение. Но вы не хотите рассчитывать на доброту рецензента, не говоря уже о том, чтобы сэкономить время на отладку.
Большинство сбоев вызвано отсутствием необходимых пакетов или сторонних модулей. Это означает, что эти библиотеки не были указаны в списке зависимостей вашего решения (package.json, requirements.txt и т. Д.).
Вероятно, они были глобально установлены в вашей рабочей среде.
Совет для профессионалов: Я предлагаю применить ту же методологию, которую я практикую для тестирования задачи кандидата - запустить ее в чистой среде, чтобы предотвратить влияние общесистемных установленных пакетов.
Есть несколько способов добиться этого, например, использовать изолированную среду (virtualenv для Python, RVM для Ruby и т. Д.), Запустить ваш код внутри контейнера с минимальным изображением. Если попросить друга запустить ваш код на его / ее машине, это не гарантирует чистого выполнения исключений.
💪 Сторонние модули спешат на помощь
В наши дни большинство, если не все компании-разработчики программного обеспечения используют библиотеки с открытым исходным кодом в своих продуктах. Некоторые компании делают дополнительный шаг и поддерживают сообщество, внося свой вклад или открывая исходный код своих собственных письменных проектов. Такое сотрудничество улучшает качество кода и в целом способствует развитию отрасли. Но это немного не по теме.
Я хочу сказать, что не предполагайте, что вы должны написать все решение самостоятельно. Некоторые рецензенты, в том числе и я, действительно ценят возможность находить нужные пакеты, интегрировать и использовать их в вашем коде чистым и элегантным способом. Поскольку это обычная практика в повседневной жизни разработчиков.
Существует бесчисленное множество примеров, когда внешние пакеты могут пригодиться и сэкономить вам много времени. На ум приходит использование библиотеки дизайна, такой как Bootstrap / Material-UI / Semantic-UI / другой, при работе над Frontend или Fullstack упражнением.
Заявление об отказе от ответственности: суть решения должна быть решена вами таким образом, чтобы вы могли «защитить» его на последующем собеседовании.
Совет для профессионалов: убедитесь, что у вас есть хотя бы базовые представления о пакете, который вы используете. Возможно, вас спросят об этом на последующем собеседовании. И снова упомяните пакет в своем README.
🕵 Используйте Style Guide или Linter
Руководства по стилям, такие как Python PEP8, улучшают читаемость кода и делают его более согласованным. Это становится еще более важным, если вы младший разработчик и не полностью знакомы со стандартами кодирования в отрасли.
Линтеры, такие как eslint в JavaScript, добавляют еще один уровень, который помогает избежать ошибок и потенциальных рисков.
У вас ограниченное время, не теряйте его, задаваясь вопросом, следует ли вам использовать табуляцию или пробелы, или искать опечатки. Руководства по стилю и линтеры также позаботятся о том, чтобы вы не пропустили остатки, которые вы забыли удалить, например TODO, комментарий или печать.
Большинство линтеров даже имеют автоматические исправления и подключаются к большинству IDE.
Неважно, какое руководство по стилю / линтер вы выберете, главное, чтобы оно соответствовало ему во всем коде.
Соблюдение набора правил поможет рецензенту сосредоточиться на том, что действительно важно - на ваших архитектурных решениях и логике реализации (не требуется «велосипедной раздачи»).
Совет для профессионалов: не забудьте указать выбранный вами стиль / линтер в README.
🐙 Хостинг исходного кода и контроль версий
Большинство известных мне компаний используют веб-хостинг для управления версиями с помощью Git, будь то GitHub, GitLab, BitBucket или другие.
Возможность размещать как частные, так и открытые проекты делает их лучшей платформой для использования для упражнения по кодированию. Вот почему я был очень удивлен, когда несколько кандидатов решили отправить свой код по электронной почте.
Хотя это может и не быть обязательным требованием, я советую всегда отправлять свое задание через службу хостинга кода, которую использует компания, в которую вы подаете заявку, по двум основным причинам:
- Это облегчает жизнь вашим интервьюерам - они могут просто клонировать их в рабочую среду, а не загружать определенные файлы, перемещать их и в некоторых случаях даже переименовывать.
Альтернативой может быть использование веб-интерфейса хостинга кода для проверки и собеседования после назначения. - Как я уже упоминал ранее, он стал отраслевым стандартом.
Менее опытные разработчики могут быть немного напуганы работой, например, с GitHub, но, по правде говоря, это достаточно просто, и компании в настоящее время ожидают, что кандидаты знают или учатся сами.
Совет №1. Если вы обеспокоены тем, что ваш нынешний работодатель может увидеть отправленную вами задачу, обязательно используйте частное репо.
Совет №2: разбейте код на логические коммиты (если вы еще не следуете этой парадигме). Это помогает рецензенту проверить ваше задание и лучше понять вашу линию мышления и процесс разработки, которому вы следовали.
Это нормально, конечно, переупорядочивать коммиты после того, как вы закончите, только не объединяйте их все вместе .
Я бы не стал делать так, чтобы каждое изменение функционировало независимо, как я делаю в моей двухдневной работе, особенно для не слишком сложных задач.
🛂 Тесты
Тесты могут потребовать много работы и могут даже не потребоваться в некоторых упражнениях.
Но это не значит, что вы не должны их включать. Вот почему:
- Помимо проверки правильности и логики, тесты предотвращают регрессы, вызванные рефакторами, улучшениями производительности и исправлениями линтов («сделать это красиво»).
- Рецензент может использовать их, чтобы легко определить различные варианты и крайние случаи, с которыми вы работали, а также области, которые вы считаете логически сложными. Тесты также можно рассматривать как форму документации по коду.
- Они выделяют вашу задачу просто потому, что другие кандидаты стараются их щадить.
Научно-исследовательские организации по-разному подходят к написанию тестов. Некоторые ожидают, что их разработчики будут писать только модульные тесты, в то время как другие стремятся к владению кодом и чувству ответственности, с интеграцией и системными тестами.
Тем не менее, это навык, который стоит развивать, даже если компания, в которую вы обращаетесь, видит его отдел обеспечения качества несет единоличную ответственность за покрытие тестов.
Совет от профессионалов: попробуйте использовать Test Driven Development (TDD). Я искренне верю, что это ускоряет процесс разработки, заставляя вас планировать, прежде чем выполнять, и ловя регрессии. В конце концов, у вас есть ограниченное время, не проводите его вручную, проверяя после каждого изменения.
✍️ Документация
Написание документации по коду является неотъемлемой частью работы разработчика, будь то в его / его повседневных задачах или в задании по кодированию.
Под документацией я подразумеваю инструкции и сообщения для рецензента, а не внутренние комментарии к коду.
Возвращаясь к разделу хостинга / контроля версий, ИМО, самая простая и быстрая форма - это указание всех требуемых данных в файле README.md.
Он имеет простой синтаксис форматирования и в целом, вероятно, наиболее распространенный использовал облегченный язык разметки, по крайней мере, для проектов кода.
Прежде чем перечислять разделы, при написании README следует иметь в виду одну вещь:
Не предполагайте, что рецензент заранее знал о вашем сообщении. Если есть какие-то сомнения, что вам нужно что-то объяснять, не сомневайтесь.
Должен быть
- Инструкции по установке
Попытка протестировать задачу без них может быть очень утомительной и отнимать много времени. - Использование и примеры
Хотя вам это может показаться очевидным, ваша реализация CLI / API может значительно отличаться от способов, которыми другие решали задание. - Используемые технологии и пакеты
Просмотр списка строительных блоков сэкономит время рецензента и позволит им сосредоточиться на реальной логике. Используйте эту часть, чтобы дважды проверить, что вы хорошо понимаете, что на самом деле делает используемый фреймворк, и дважды проверьте, не осталось ли неиспользуемых библиотек.
Приятно
- Анализ сложности кода
Хотя это действительно связано с конкретным упражнением, чтение того, почему кандидат выбрал алгоритм или структуру данных, демонстрирует мысли и восприятие. Я рекомендую использовать большую нотацию O для временной сложности. - Допущения и отказ от ответственности
Если ваше решение основано на определенных допущениях, которые вы сделали, обязательно их перечислите.
Впервые используете язык программирования / фреймворк / базу данных? это прекрасно, просто обязательно отметьте это, чтобы вас не оценили как ветеран. - Дополнительная миля
Есть и другие способы, которые я не упомянул, чтобы сделать вашу заявку сияющей.
Независимо от того, реализовали ли вы бонус, реализовали ли проверку данных и обработку ошибок или преодолели самый сложный край случаев, не полагайтесь на экзаменатора, чтобы заметить это.
Совет для профессионалов. В конце концов, проверка представленных кандидатов - не самая захватывающая задача для менеджера по подбору персонала. Добавление ASCII-арта / цМема / гифок, связанных с компанией или заданием, может выделить его и вызвать улыбку на лице вашего рецензента.
Надеюсь, этот пост поможет вам лучше понять точку зрения рецензента при выполнении следующего задания по кодированию 🙏
Если у вас есть другие советы, которым, по вашему мнению, могут научиться другие, напишите их в разделе комментариев ниже 👇
Для (почти) ежедневных Сегодня я научился кодирования советы и хитрости проверяйте мой веб-сайт.
