❓ Почему нельзя соглашаться на тестовый кодинг во время собеседования
Собеседования по программной инженерии часто включают в себя какое-то тестовое задание по программированию, и это не очень хорошо. Объясним, почему.
Перевод публикуется с сокращениями, автор оригинальной статьи Dr Stuart Woolley.
Ленивый подход
Когда инженера-программиста просят выполнить конкретную задачу: написать алгоритм генерации факториалов (очень распространенное задание) или сортировки (одно/двусвязного) списка, никто не думает, что можно легко подготовиться и это не даст никакого представления о навыках кандидата, кроме силы механического запоминания.
Во время работы в одной компании автор обсуждал с коллегой процесс собеседования, которое они проходили в крупном хедж-фонде. Ко всем задаваемым техническим вопросам он был готов, т.к. сотрудник компании порекомендовал книгу с вопросами и ответами к собеседованию. Это была не только пустая трата времени, но и полное непонимание рекрутером компании уровня знаний кандидата. Коллега уволился через год из-за низкой технической планки по найму специалистов и постоянной неэффективной практики управления проектами.
Использование памяти
То же самое рассуждение относится и к программированию алгоритма на определенном языке. Ни один инженер-программист, работающий в реальном мире, не написал бы код без проверки синтаксиса (например, встроенного в автодополнение кода), без ссылки на техническую документацию или без копирования использования реализованного решения там, где это применимо. Не нужно изобретать велосипед.
При всей практической применимости, работа с синтаксисом конкретного ЯП основана на использовании и опыте. В то время как интервьюер может думать, что тестирование кандидата на синтаксические нюансы конкретного языка является показателем его понимания – автор материала категорически заявляет, что даже используя язык почти тридцать лет, он все еще регулярно ошибается в синтаксисе.
По мере того как карьера программиста развивается и он знакомится с новыми языками, автор регулярно путается между синтаксическими нюансами C, C++ и Objective-C. Не из-за того, что он ужасный инженер-программист, а потому что есть масса знаний, которые держатся в голове и ими нужно правильно воспользоваться в нужный момент. Хороший инженер-программист часто не знает ответа на конкретный вопрос с самого начала, но определенно знает, где искать ответ.
Общие задачи
Немного ранее мы говорили об изобретении велосипеда. Например, если вы работаете с языком C и вам необходима процедура для взаимодействия с последовательным портом, не нужно переписывать ее с нуля, если только ситуация этого специально не требует. Если нужен парсер JSON, просто возьмите уже созданный файл из библиотеки. Скорее всего он давно используется, полностью протестирован и имеет подробную (и правильную) документацию.
Вряд ли в современной программной инженерии можно встретить обычную задачу, которая либо уже не автоматизирована в написанной библиотеке, либо решение которой не является широкодоступным в алгоритмической форме.
Дискуссия-дискуссия-дискуссия
Автор полностью поддерживает выяснение того, знает ли свой предмет человек, с которым вы беседуете, но использование любого из вышеперечисленных методов совершенно бесполезно.
Например, простая дискуссия об используемых в современной программной инженерии парадигмах кодирования, о том, будет ли конкретный язык хорошим выбором для конкретной реализации, или уместна ли конкретная методология разработки программного обеспечения – это гораздо более полезные и острые темы для обсуждения.
Проведите дискуссию, чтобы выделить общие области, посмотрите, как кандидат понимает новые проблемы и, возможно, альтернативные новые методы решения старых. Как он видит развитие вещей, как бы он начал что-то решать. Оставайтесь открытыми, держитесь подальше от подробностей и мелочей. Stuart Woolley постоянно удивляется, что многие считающиеся перспективными и лидирующими в своей области компании все еще прибегают к устаревшим, монотонным и совершенно предсказуемым методам найма, которые мало что значат для оценки реальной технической ценности.
Собеседование с кем-то, у кого есть список технических вопросов – это почти всегда нежелание затягивать дискуссию по какому-то одному вопросу. Это часто показывает, что интервьюер может не полностью понять, о чем он спрашивает, и любой ответ, который точно не совпадает с написанным в его сценарии, будет классифицирован как неправильный.
Заключение
Некоторые компании перешли на более эффективные методы, другие, возможно, не дотянут до цели. Поэтому не связывайте отношения (особенно длительные) с работодателями, которые следуют устаревшей практике найма, настаивают на тестах и заданиях по программированию.
Если вы новичок в этой игре, то, возможно, вы не в том положении, чтобы отказываться от интервью – рассматривайте это как опыт. Пройдите через него, получите навыки, узнайте как можно больше, и если работа вас разочарует, просто двигайтесь дальше. По мере продвижения вперед ваша уверенность будет расти вместе со знаниями и опытом. В конце концов компания получает выгоду от вас, поэтому вы должны в равной степени получать выгоду от компании.
Если вы думаете, что вы достойный работодатель, и не можете понять, почему отличные кандидаты продолжают уходить, стоит в срочном порядке пересмотреть практику найма.
Дополнительный материал:
- Логические и математические задачи с собеседований
- 15 вопросов по Python: как джуниору пройти собеседование
- Спорим, вы не сможете решить эту задачу с собеседования в Google
- Готовимся к собеседованию в Google: 8 месяцев непрерывной работы
- Как легко пройти собеседование