Давайте знакомиться, меня зовут Дмитрий и вот уже 12 лет я работаю в ИТ. Занимал разные должности, Frontend разработчик, Tech Lead, Team Lead в разных компаниях. Не один раз проходил собеседования и каждый раз после ряда интервью у меня возникали все новые и новые вопросы. Предлагаю в этой статье порассуждать на тему оценки квалификации претендента, почему компании не хотят растить инженеров с позиции Junior, почему появились ИТ-волки и как нам прийти к равновесию.
Два полюса объективности (точнее, её отсутствия)
Проблема оценки квалификации напоминает мне маятник, который болтается между двумя крайностями.
Полюс первый: «Вопросы с Хабрà»
Пойти на Хабр, найти статью в духе «100 вопросов для собеседования Frontend-разработчика» и задавать их по порядку. Каково же было моё удивление, когда, проходя два интервью в разных компаниях в один день, я услышал буква в букву одинаковые вопросы, да ещё и в той же последовательности. Такой подход хорош ровно для одного сценария: если вы нанимаете Junior. Готовясь к собеседованию, кандидат вызубрит ответы и попутно узнает для себя что-то новое. Это не плохо. Плохо, когда этот же пул вопросов звучит на позицию Senior. Как минимум между Junior и Senior должны стоять концептуально разные задачи, один пишет больше код, второй думает как организовать взаимодействие компонентов программы и решает нетривиальные задачи.
Полюс второй: «Велосипедостроение»
Вторая сторона медали — это изобретение собственных методик. Алгоритмические секции, тестовые проекты, код-ревью чужого кода. Вроде бы всё логично, но практика показала: ни один из этих методов не вскрывает те преимущества или недостатки, которые будут действительно критичны для проекта, под который мы ищем человека.
Алгоритмические собеседования. Они говорят лишь о том, что кандидат готовился и заучил подходы к задачам. Это не приговор, но критично другое: разработчик, который ночами не сидит на LeetCode, может быть ничуть не хуже того, кто в нём живёт.
Приведу в пример опыт из своей жизни. Мы были молодые и амбициозные и искали в команду очень крутого Frontend разработчика. Как мы только не издевались над кандидатами в процессе прохождения собеседования, порог был явно завышен. Так мы искали себе коллегу почти 3 месяца, пока в какой-то момент нам на собеседовании не попался парень, который средне ответил на вопросы, средне решил задачи, но зато был очень общителен и постоянно шутил. И мы его взяли. И это был очень классный инженер, мы сработались и прекрасно справлялись со всеми поставленными задачами. Мы потратили очень много времени на то, чтоб потешить свое эго, и все это за счет компании.Код-ревью. Тут всё упирается в банальные холивары. Если у интервьюера и интервьюируемого различаются взгляды на архитектуру, а вес в профессии примерно равный, прав всегда будет на стороне того, кто сидит с той стороны стола.
Тестовые задания. Они работают только когда фокус сделан на ключевую боль проекта. У меня был пример, когда в core-команду искали React-разработчика для старта нового проекта с Webpack Module Federation. Задача была нетривиальная — собрать некий «браузер внутри браузера». Тестовое задание было составлено ювелирно, с упором именно на реализацию этого граничного функционала. Это помогло. Но стандартное ТЗ в духе «сделайте ToDo лист на Redux» — это просто трата времени и нервов кандидата.
Почему в командах не хотят джунов и к чему это приводит
Часто вижу картину: компании хотят нанимать только Senior-ов. Мол, наберём команду из матёрых волков, и они сами всё разрулят. Звучит красиво, но на деле я наблюдал подводные камни, и они довольно острые.
Во-первых, это синдром «Героя-одиночки». Каждый тянет одеяло на себя, бесконечные архитектурные споры и внутренняя конкуренция. А если вспомнить ошибки найма из предыдущей главы, то в лучшем случае мы получим несколько настоящих сеньоров и пару джунов, купленных по цене сеньора. В худшем — команду с завышенным ЧСВ, которая за оверпрайс выдаёт посредственный продукт. Эффект Даннинга-Крюгера не щадит никого.
Пример из жизни: в одной компании я видел, на мой взгляд, идеальную модель. Нанимали одного сильного и опытного разработчика (о том, как они проверяли его реальный опыт, расскажу чуть позже) и за адекватные деньги брали к нему в команду нескольких Junior-ов. Что это давало? Опыт + энергия + жажда знаний = очень крутой результат. Задачи закрывались качественно и в срок. Компания по сути растила кадры внутри, джуны впитывали знания как губка. Минус у схемы один: Lead должен быть ответственным и тратить время на код-ревью, а ещё через год-полтора джуны вырастали и уходили на рынок за сильно большими зарплатами (своим, конечно, поднимали, но ковидный рынок диктовал бешеные ставки, и угнаться было сложно).
ИТ-Волки: как мы сами создаём среду для «накрутки опыта»
Вернёмся к началу. У нас нет объективной оценки, и все хотят нанимать только «готовых». Что создаёт эта среда? Идеальные условия для появления ИТ-волков с накрученным стажем. Можно подтянуть теорию, выучить ответы на топ-100 вопросов, решить сотню задач на алгоритмы и сразу пойти «в дамки» на зарплату сеньора.
Но есть то, что подтянуть онлайн-курсами невозможно — это опыт коммерческой разработки. Алгоритмы не дадут фундаментального понимания того, как строить масштабируемые приложения, которые не развалятся через полгода под нагрузкой и правками бизнеса.
Давайте для наглядности (и с долей утрирования) сравним с другими сферами. Представьте, что кто-то накрутил себе опыт пилота и сел за штурвал пассажирского Boeing, имея за плечами лишь теорию управления Cessna. Или после медуниверситета «дорисовал» себе годы практики и пошёл оперировать сердце. Я понимаю, что ответственность разная, но метод проверки компетенций в «серьёзных» отраслях удивительно прост и надёжен.
Старый добрый метод, который мы незаслуженно забыли
Это проверка трудовой книжки. Электронную трудовую подделать на порядок сложнее, чем резюме на HH. Мне, если честно, не приходит в голову ни одной идеи, как это можно провернуть 😊.
Логика простая: если кандидат нигде не работал — у него нет коммерческого опыта (исключение — работа по гражданско-правовым договорам, но даже тогда 1-2 компании в выписке из ПФР, как правило, мелькают). И если вам нужен не просто инженер, а настоящий «рок-стар», метод старого доброго хантинга из конкретных компаний пока никто не отменял и ничего лучше не придумал.
Этот подход, конечно, тоже даёт осечки, но в текущем хаосе на рынке труда он выглядит куда менее рискованным, чем решение алгоритмических задач на скорость.
P.S. Всё вышесказанное — лишь мой личный опыт и наблюдения за 12 лет в индустрии. Буду рад узнать ваше мнение и истории из найма в комментариях.