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

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

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

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

  • Попробуйте разместить свою последнюю работу на веб-сайте вроде Github: в настоящее время большинство команд разработчиков полагаются на git для управления своим кодом. Независимо от того, насколько вы квалифицированы, не так уж сложно отправить свой код задачи кодирования в репозиторий Github с помощью красивого файла read.me и четких сообщений о фиксации. Это свидетельствует о профессионализме и упрощает рассмотрение вашей работы, особенно если вас попросили решить задачу кодирования из дома.
  • Для разработчика всегда полезно писать тестовые примеры для своего кода. Это показывает, что они заботятся о поддерживаемости своего кода, что может облегчить жизнь другим разработчикам в команде. Очевидно, что тестирование бывает разных видов, таких как интеграционные тесты, тесты e2e или модульные тесты. Я бы сказал, что наилучшим подходом является написание индивидуальных модульных тестов для основных функций задачи кодирования.
  • Не бойтесь пройти лишнюю милю, но также постарайтесь не сбиваться с пути. Команда по набору персонала была бы признательна, если бы вы немного подумали нестандартно и внесли какие-то улучшения в исходную спецификацию задачи кодирования, которую они вам поставили. Например, они могли попросить вас составить простой список дел; но вы могли бы приложить дополнительные усилия и добавить несколько красивых иконок и шрифтов и потратить немного времени на их стилизацию, чтобы они выглядели более привлекательно. Но загвоздка здесь в том, что проблема с кодированием должна быть устранена перед добавлением каких-либо улучшений. Так вы в любом случае собираетесь планировать свои задачи как младший разработчик, так что лучше подготовьтесь к этому с первого дня.
  • Изучите их, проверив или запросив их технический стек, и попробуйте использовать некоторые из их инструментов для решения вашей задачи кодирования. Это не только познакомит вас с тем, как они решают свои проблемы, но и положительно повлияет на их оценку вас, поскольку они более знакомы с инструментами, которые они используют регулярно изо дня в день. При этом добавление в микс знакомых вам инструментов - тоже очень хорошая идея.
  • Сделайте все возможное, чтобы структура кода была чистой. Это означает, что гораздо удобнее разделить различные части функциональности в отдельные файлы, чем объединять все в один файл. Кроме того, добавьте комментарии к частям кода, которые не очень легко понять, чтобы показать, что вы заботитесь о том, чтобы другие разработчики могли легче подобрать вашу логику в коде.

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

Так о чем же совещание по рассмотрению проблемы кодирования?

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

Вы должны помнить одну вещь: компании получают несколько очень хороших или очень плохих решений проблемы программирования, но они получают много средних. Если рекрутеры, стоящие за компанией, достаточно умны, они знают, что нанимать только людей с очень хорошими решениями непрактично. Часто, ставшие впоследствии рок-звездой, разработчики предоставляют среднее решение для программирования. Так что на данный момент их работа - оценить вашу работу, а также ваши рабочие качества, чтобы увидеть, смогут ли они привлечь вас к работе и сделать для вас хорошее вложение для будущего компании.

Итак, давайте разберемся, что они ищут.

Оценка проверки кода

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

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

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

Оценка рабочей личности

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

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

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