Работа мечты в один клик 💼

💭Мечтаешь работать в Сбере, но не хочешь проходить десять кругов HR-собеседований? Теперь это проще, чем когда-либо!
💡AI-интервью за 15 минут – и ты уже на шаг ближе к своей новой работе.
Как получить оффер?
📌 Зарегистрируйся
📌 Пройди AI-интервью
📌 Получи обратную связь сразу же!
HR больше не тянут время – рекрутеры свяжутся с тобой в течение двух дней! 🚀
Реклама. ПАО СБЕРБАНК, ИНН 7707083893. Erid 2VtzquscAwp
Перевод публикуется с сокращениями, автор оригинальной статьи Dr Stuart Woolley.
Ленивый подход
Когда инженера-программиста просят выполнить конкретную задачу: написать алгоритм генерации факториалов (очень распространенное задание) или сортировки (одно/двусвязного) списка, никто не думает, что можно легко подготовиться и это не даст никакого представления о навыках кандидата, кроме силы механического запоминания.
Во время работы в одной компании автор обсуждал с коллегой процесс собеседования, которое они проходили в крупном хедж-фонде. Ко всем задаваемым техническим вопросам он был готов, т.к. сотрудник компании порекомендовал книгу с вопросами и ответами к собеседованию. Это была не только пустая трата времени, но и полное непонимание рекрутером компании уровня знаний кандидата. Коллега уволился через год из-за низкой технической планки по найму специалистов и постоянной неэффективной практики управления проектами.
Использование памяти
То же самое рассуждение относится и к программированию алгоритма на определенном языке. Ни один инженер-программист, работающий в реальном мире, не написал бы код без проверки синтаксиса (например, встроенного в автодополнение кода), без ссылки на техническую документацию или без копирования использования реализованного решения там, где это применимо. Не нужно изобретать велосипед.

При всей практической применимости, работа с синтаксисом конкретного ЯП основана на использовании и опыте. В то время как интервьюер может думать, что тестирование кандидата на синтаксические нюансы конкретного языка является показателем его понимания – автор материала категорически заявляет, что даже используя язык почти тридцать лет, он все еще регулярно ошибается в синтаксисе.
По мере того как карьера программиста развивается и он знакомится с новыми языками, автор регулярно путается между синтаксическими нюансами C, C++ и Objective-C. Не из-за того, что он ужасный инженер-программист, а потому что есть масса знаний, которые держатся в голове и ими нужно правильно воспользоваться в нужный момент. Хороший инженер-программист часто не знает ответа на конкретный вопрос с самого начала, но определенно знает, где искать ответ.
Общие задачи
Немного ранее мы говорили об изобретении велосипеда. Например, если вы работаете с языком C и вам необходима процедура для взаимодействия с последовательным портом, не нужно переписывать ее с нуля, если только ситуация этого специально не требует. Если нужен парсер JSON, просто возьмите уже созданный файл из библиотеки. Скорее всего он давно используется, полностью протестирован и имеет подробную (и правильную) документацию.
Вряд ли в современной программной инженерии можно встретить обычную задачу, которая либо уже не автоматизирована в написанной библиотеке, либо решение которой не является широкодоступным в алгоритмической форме.
Дискуссия-дискуссия-дискуссия
Автор полностью поддерживает выяснение того, знает ли свой предмет человек, с которым вы беседуете, но использование любого из вышеперечисленных методов совершенно бесполезно.

Например, простая дискуссия об используемых в современной программной инженерии парадигмах кодирования, о том, будет ли конкретный язык хорошим выбором для конкретной реализации, или уместна ли конкретная методология разработки программного обеспечения – это гораздо более полезные и острые темы для обсуждения.
Проведите дискуссию, чтобы выделить общие области, посмотрите, как кандидат понимает новые проблемы и, возможно, альтернативные новые методы решения старых. Как он видит развитие вещей, как бы он начал что-то решать. Оставайтесь открытыми, держитесь подальше от подробностей и мелочей. Stuart Woolley постоянно удивляется, что многие считающиеся перспективными и лидирующими в своей области компании все еще прибегают к устаревшим, монотонным и совершенно предсказуемым методам найма, которые мало что значат для оценки реальной технической ценности.
Собеседование с кем-то, у кого есть список технических вопросов – это почти всегда нежелание затягивать дискуссию по какому-то одному вопросу. Это часто показывает, что интервьюер может не полностью понять, о чем он спрашивает, и любой ответ, который точно не совпадает с написанным в его сценарии, будет классифицирован как неправильный.
Заключение
Некоторые компании перешли на более эффективные методы, другие, возможно, не дотянут до цели. Поэтому не связывайте отношения (особенно длительные) с работодателями, которые следуют устаревшей практике найма, настаивают на тестах и заданиях по программированию.
Если вы новичок в этой игре, то, возможно, вы не в том положении, чтобы отказываться от интервью – рассматривайте это как опыт. Пройдите через него, получите навыки, узнайте как можно больше, и если работа вас разочарует, просто двигайтесь дальше. По мере продвижения вперед ваша уверенность будет расти вместе со знаниями и опытом. В конце концов компания получает выгоду от вас, поэтому вы должны в равной степени получать выгоду от компании.
Если вы думаете, что вы достойный работодатель, и не можете понять, почему отличные кандидаты продолжают уходить, стоит в срочном порядке пересмотреть практику найма.
Дополнительный материал:
- Логические и математические задачи с собеседований
- 15 вопросов по Python: как джуниору пройти собеседование
- Спорим, вы не сможете решить эту задачу с собеседования в Google
- Готовимся к собеседованию в Google: 8 месяцев непрерывной работы
- Как легко пройти собеседование
Комментарии
Глядя на каждый день появляющиеся модные методики тестирования на работу (включая уже VR-технологии), постоянно говорю тоже само относительно любого тестирования с целью приёма на работу, не только программистов. Можно увидеть, как кандидат умеет решать тесты (к которым, не исключено, он тщательно готовился), но это совершенно ничего не говорит о его способностях к реальным задачам. В том числе вообще о способностях развиваться.
Во многом согласен. Если взять опытного разработчика и не опытного, но прорешавшего много тестовых задач по алгоритмам, то может вполне оказаться что неопытный будет выглядеть получше. Но как только дело дойдет до практики и нужно будет решать большую задачу, то опытный программист сделает это лучше. Многие разработчики при найме на работу до сих пор не знают что к собеседованиям нужно готовиться, а именно прорешивать кучу алгоритмов, такова действительность. Думаю выход из этой ситуции есть - нужно контрибутить в opensource, где все будет видно, тогда можно и отказываться от прохождения этих тестов. С другой стороны я согласен, что знание алгоритмов очень важная вещь, но не все из нас занимались олимпиадным программированием. Думаю Linus Torvalds не очень хорош в решении олимпиадных задач, что не делает его менее хорошим программистом и инженером в целом.