Сообщение администратору
Имя:
Почта:
Сообщение:
Вход на сайт
Логин:
Пароль:

Поддержка  •  Дневник  •  О сайте  •  Реклама  •  Поставить баннер  •  Прислать  •  Хроника  •  Translate  •  Рекомендованное  •  Написать администратору Гости: 7    Участники: 1 Авторизация Авторизация   Регистрация 
Метод Научного Тыка
RULVEN
Поиск  
Blackball iMag | интернет-журнал
RSS-лента
Поделиться ссылкой:
Каталог


Начало » Разработка ПО » Почему вы никогда не должны соглашаться на собеседования с программированием

Почему вы никогда не должны соглашаться на собеседования с программированием


Почему вы никогда не должны соглашаться на собеседования с программированием
Добавлено: Пн 30.01.2023 • Sergeant
Источник: источник
Просмотров: 519
Комментарии: 0


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

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

Попросив инженеров-программистов выполнить конкретную задачу, например написать алгоритм генерации факториалов (очень распространённый) или отсортировать односвязный или двусвязный список, которые легко запоминаются, вы не получите никакого представления об умениях кандидата, кроме умения зубрить. С таким же успехом можно спросить ASCII-код символа 'A'.

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

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

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

Память

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

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

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

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

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

Общие задачи

Кое-что я уже затронул: это максима — не изобретайте колесо. Например, если вы работаете на языке Си и вам нужна процедура последовательного порта, не пишите её с нуля, если только ситуация не требует этого. Возможно, вам нужен парсер JSON, очень распространённое требование — если только вы не пишете код на встроенной плате с ограниченным ресурсом, для спутника на геостационарной орбите или в Malbolge; тогда, возможно, вам стоит просто вытащить из библиотеки то, что уже написали. Скорее всего, код уже давно применяется, он полностью протестирован и имеет подробную (и корректную) документацию. Он надежен.

Вряд ли в современной программной инженерии встретится общая задача, которую ещё не автоматизировали в библиотеке, либо алгоритм которой сложно найти.

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

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

Дискуссия. Дискуссия. Дискуссия

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

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

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

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

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

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

Подведем итоги

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

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

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

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

Если вы, как я, старше и опытнее, пусть нанимающая компания просто поговорит с вами. У нас много опыта, мы многое видели и делали, квалификацию ясно видно в резюме и CV. И я возмущён тем, что меня направляют по общему конвейеру найма и многократно проверяют мои способности.

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



Мне нравится 0   Мне не нравится 0



Комментарии

Чтобы добавить видео с YouTube, нужно написать [@youtube=xxxxx] , где xxxxx – ID видео.


Комментарии: 0
Нет ни одного комментария.

Новое
5 вкусных салатов с курицей вчера, 09:00
5 вкусных салатов с курицей
Митболы в густом пикантном соусе вчера, 02:31
Митболы в густом пикантном соусе
Почему W-образные моторы уходят в прошлое, если они были лучше V-образных Пн 02.12.2024
Почему W-образные моторы уходят в прошлое, если они были лучше V-образных
20 простых и очень вкусных салатов с кальмарами Сб 30.11.2024
20 простых и очень вкусных салатов с кальмарами
Вирусы на Android: подробное руководство по обеспечению безопасности Пн 25.11.2024
Вирусы на Android: подробное руководство по обеспечению безопасности
15 интересных салатов со свежими огурцами Сб 23.11.2024
15 интересных салатов со свежими огурцами
Зал короля Артура оказался неолитическим загоном для скота Пн 18.11.2024
Зал короля Артура оказался неолитическим загоном для скота
15 действительно вкусных салатов с крабовыми палочками Сб 16.11.2024
15 действительно вкусных салатов с крабовыми палочками
Когда устал от алгоритмов: Ревью кода на собеседовании Вт 12.11.2024
Когда устал от алгоритмов: Ревью кода на собеседовании
Пн 11.11.2024
10 не самых очевидных причин, чтобы уволиться
Книги
Blazor in Action Вт 04.06.2024
Blazor in Action
Год: 2022
Security for Containers and Kubernetes Вт 28.05.2024
Security for Containers and Kubernetes
Год: 2023
Designing Data-Intensive Applications Вт 14.05.2024
Designing Data-Intensive Applications
Год: 2017
Fundamentals of Software Architecture Вт 07.05.2024
Fundamentals of Software Architecture
Год: 2020
Разработано на основе BlackNight CMS
Release v.2024-11-16
© 2000–2024 Blackball
Дизайн & программирование:
О сайтеРеклама
Visitors
Web-site performed by Sergey Drozdov
BlackballРекламаСтатистикаПоддержка
МузыкаПлейлистыКиноВидеоИгрыАудиоПрограммыСтатьиКартинкиЮморФорумДневник сайтаПрислать контентРекомендованное