Недавно я наткнулся на быстро набравший популярность пост fillpackart, который натолкнул меня на размышления, которыми я хотел бы поделиться со всеми читателями Хабра. Однако прежде всего я хотел бы подчеркнуть, что все сказанное в данной статье является моим личным мнением и видением ситуации и я не претендую на его истинность.
О современных собеседованиях
Автор вышеупомянутой статьи жалуется на то, что на собеседованиях ему перестали задавать технические вопросы. Так ли это плохо? Сколько из нас каждый день на работе пишет красно-черные деревья или использует виртуальное наследование (это просто примеры, давайте, пожалуйста, не будем обсуждать в комментариях их полезность)?
Мне кажется, что людей, ответивших на последний вопрос положительно, не так много. А ведь именно об этом и любят спрашивать на технических собеседованиях. Сильно ли бизнес пострадает, если возьмет на работу человека, который не сможет ответить на такой вопрос без поисковика под рукой?
Проблема заключается в том, что вопросы на технических собеседованиях разительно отличаются от реальных задач разработчика. В том числе и от задач, которые кандидат будет выполнять в компании, если пройдет этап собеседования. Так зачем это? Зачем проверять умение решать задачки с LeetCode или знание устройства экзотических конструкций языка? Зачем это нужно, если в дальнейшем оно едва ли пригодится, а если и пригодится, всегда можно найти подробное описание данных алгоритмов и принципов?
И самое главное: это не просто бесполезная проверка. Она превращает собеседования в бессмысленный и беспощадный ад. Из-за этого подготовка к собеседованию превращается в, по сути, бесполезное решение задачек. На самих же собеседованиях нервы берут свое и даже самые достойные кандидаты иногда теряются в решении несложных задачек.
Тут, должно быть, мне возразят, что целью собеседования с задачками в первую очередь является проверка кандидата. Да, так и есть, но далеко не все это понимают. Многие разработчики, которых HR отправляют собеседовать соискателей, об этом забывают. И тогда собеседование превращается в скучный монолог кандидата, который пытается что-то решить. Потом решение фотографируется и оно становится аргументом за или против. Правильно ли это? Нет. Я считаю, что задачи давать можно только несложные и надо помогать кандидату. Не надо рассказывать человеку все решение, но наталкивать его на правильные мысли нужно. Ведь мы разрабатываем софт не в одиночку. Разработка уже давно стала командной работой. Так почему же я до сих пор вижу разработчиков, которые на собеседовании ничего кроме условия задачки не говорят?
Я бы еще раз хотел заострить внимание: собеседования с задачками — это нормально, но только если эти задачки простые и ее решение превращается в диалог собеседующего и собеседуемого. Главное здесь — проверить, как кандидат мыслит. Как он подходит к решению задачи. Вот что важно, а не то, решит ли он эту задачу или нет. Вы же не ищете разработчиков, единственным умением которых является решение задачек с LeetCode?
Хард и софт скиллы
Рядом стоит и другой вопрос. Правда ли, что лучше нанять хорошего интроверта, чем средненького экстраверта (я не говорю про наем посредственных работников, но таких как раз можно увидеть во время собеседования)? Я уверен, что нет: как я уже говорил, разработка давно стала командной и тут становится важным взаимодействие людей в команде. Неужели лучше чтобы ваш напарник неделю сидел и разбирался в каком-нибудь классе или функции из общей базы кода, чем если бы он подошел к его разработчику и спросил его, как им правильно пользоваться? Тут же можно сказать, что крутой интроверт тоже не понятно как отреагирует на вопросы к нему.
Одиночная разработка вымирает. В агониях дергаются только фрилансеры-разработчики сайтов. Любой серьезный продукт требует команду разработчиков, а часто и не одну. Поэтому как раз крутые интроверты скоро вымрут из IT, а нам придется работать с тем, что осталось.
О хайповых технологиях
Единственный поинт, в котором я соглашусь с автором статьи, но и тут не до конца. Да, проблема с посредственными и распиаренными технологиями есть. Но и тут важно заметить, что пусть лучше все пользуются чем-то одним. Единственное решение наверняка рано или поздно станет самым проработанным. Хотя бы потому, что у его разработчиков есть на это деньги и ресурсы. А иначе мы получим много решений, которые хорошо начинали, но по ходу разработки приобрели различные проблемы. Такое состояние дел только побуждает разработку "14-го стандарта". И так далее. Давайте все же все пользоваться одним решением. Когда-нибудь его проблемы будут решены, чего не скажешь о каждом из 10 разных решений с единичными пользователями.
Автор: binpord
