LinkedIn
GitHub profile
Проекты
Advertisement
RSS
.NET Framework .NET C# VB.NET LINQ ASP.NET Web API REST SignalR Windows Forms WPF WCF RabbitMQ PHP SQL Server MySQL PostgreSQL MariaDB SQLite MongoDB ADO.NET ORM Entity Framework Dapper XML JSON HTML5 CSS3 Bootstrap JavaScript jQuery Angular React TypeScript NPM Blazor UI/UX Responsive Web Design Redis Elasticsearch GraphQL Grafana Agile Scrum Kanban Windows Server IIS PowerShell Active Directory TFS Azure Automation Software Reverse Engineering Performance Optimization Git Jira/Confluence CI/CD TeamCity SOLID KISS DRY YAGNI
Always will be ready notify the world about expectations as easy as possible: job change page

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

Добавлено: 23 января 2023 г.
Источник: https://habr.com/ru/company/skillfactory/blog/538240/
Просмотров: 23

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

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

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

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

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

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

Память

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

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

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

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

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

Общие задачи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожее
30 января 2023 г.
Автор: Иван Белокаменцев
Управлять программистами в ИТ-компании – дело особое. Не сказать, что сильно сложное. Совру, если назову простым. Особое.Книжек, статей, курсов создано великое множество. Что-то помогает, у кого-то получилось. Собственно, промахнуться с оценкой сложно – отрасль ведь не просто существует, но и...
1 сентября 2022 г.
Автор: Arnak
«Громкий уход» — это когда ты объявляешь всем, что увольняешься. Когда об этом знают по крайней мере твои работодатели. Но в последнее время резко начал набирать популярность так называемый «тихий уход» («quiet quitting»). Когда о том, что ты по сути...
7 октября 2020 г.
Наем удаленных специалистов – довольно сложная задача о поиске оптимального решения с учетом известных ограничений.С одной стороны, ты ограничен во времени. Учитывая средние зарплаты в ИТ, стоимость простоя каждого такого специалиста крайне высока. Если кандидаты находятся на стадии активного поиска,...
28 июля 2020 г.
Удалёнка бьёт по мозгам. И это я вам говорю не как те, кто погрузился в неведомо прекрасное состояние в марте, а как человек, который уже пять лет не видел офисную жизнь, не пил сонным кофе из кофемашины и не встревал...
Написать сообщение
Эл. почта
Имя
*Сообщение


© 1999–2023 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET | .NET Core | C# | ASP.NET | Windows Forms | WPF | Windows Phone | HTML5 | CSS3 | jQuery | AJAX | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban