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

Ленивые тропы

Просить программистов выполнить конкретную задачу, например написать алгоритм для генерации факториалов (очень распространенный) или отсортировать [односвязный | двусвязный] список, можно легко запомнить заранее и не дает никакой информации о навыках кандидата, кроме их силы механического запоминания. Вы также можете спросить код ASCII символа A.

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

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

Использование памяти

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

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

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

Фактически, по мере того, как моя карьера разработчика программного обеспечения развивалась и я лучше знакомился с интересующими меня языками, я регулярно путаюсь между синтаксическими нюансами, скажем, C и C ++ или Objective-C. Это не потому, что я ужасный инженер-программист (хотя некоторые могут с этим не согласиться ...), а потому, что вы можете держать в голове очень много знаний и сразу вспоминать их.

Хороший инженер-программист часто не может придумать ответ на конкретный вопрос, но наверняка знает, где искать ответ. Может быть, подумайте о том, чтобы спросить, где лучше всего найти такую ​​информацию, как вопрос на собеседовании?

Общие задачи

То, что я вкратце затронул ранее, - это принцип не изобретать велосипед заново. Например, если вы работаете на C и вам нужна процедура последовательного порта, вам не нужно переписывать ее с нуля, если этого не требует ситуация. Возможно, вам понадобится парсер JSON, что является очень распространенным требованием - если вы не кодируете на встроенной плате с ограниченными ресурсами, на спутнике на геостационарной орбите или в Мальболге, тогда, возможно, вам следует просто взять заранее написанный код из библиотека. Скорее всего, он используется в течение длительного времени, полностью протестирован и содержит подробную (и правильную) документацию. Твердый.

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

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

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

Обсуждение Обсуждение Обсуждение

Я полностью поддерживаю выяснение того, «знает ли человек, с которым вы проводите собеседование, свое дело», но использование любого из вышеперечисленных методов, на мой взгляд, совершенно бесполезно. Скажи так, как есть.

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

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

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

Часто говорят, что собеседник должен проводить собеседование с компанией так же часто, как и сама компания. Я полностью поддерживаю это.

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

Суть

Некоторые компании перешли на более эффективные методы, другие, что ж, не достигли цели. Здесь я призываю вас, коллеги-программисты, не связываться с компаниями, которые следуют устаревшим методам приема на работу и настаивают на тестах и ​​упражнениях по программированию.
Особенно продолжительных!

Я слышал истории о компаниях, которые просили завершить проекты в срок, назначенный кандидатом, что часто занимало несколько дней.

У других есть общие «тесты способностей» для определенных языков, с множественным выбором, где намек на мозговой туман в течение ограниченного отведенного времени означает, что игра окончена!

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

Если вы более опытный человек, как я, тогда нанимающие компании - просто поговорите со мной. Я был рядом, я что-то видел и что-то делал, все требования указаны на стене и в CV, и я возмущаюсь, что меня направляют по какому-то общему каналу приема на работу и неоднократно проверяют на мои способности.

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