В IT есть много хороших, годных, и адекватных процессов. Но есть и те, где до сих пор царит страх и ужас. Один из таких - собеседования разработчиков.
На самом деле, тут всё просто.
Нет никакой даже приблизительно объективной оценки пользы, "хорошести", и даже окупаемости программиста. Субъективщина царит и правит индустрией.
Из этого исходят следующие абсурдные моменты собеседований:
Вопросы про то, что "под капотом" у технологий. Если в низкоуровневых языках с ручным управлением памятью они выглядят адекватно - то в высокоуровневых это абсурд. Ну вот сами посудите. Одни разработчики постоянно делают всё более высокоуровневые средства, чтобы УПРОСТИТЬ жизнь разработчика, и СКРЫТЬ сложные моменты. А другие - наоборот, требуют знания этой самой внутрянки, в том числе организации ЭТИХ САМЫХ средств. Эдакая битва с ветряными мельницами. Многие говорят, что это "проверка на умение копать вглубь, и интерес к технологиям". Копать вглубь чего? Того, что НАМЕРЕННО пытались скрыть, чтобы оптимизировать время, нервы и силы? Не является ли это нецелесообразной тратой времени (с точки зрения бизнеса)? Или, к примеру, неправильным подходом к задаче? Ну, когда вместо её решения - следует раскопка этих самых средств, написание своих велосипедов, или какие-то преждевременные оптимизации?
- Если незнание внутрянки технологии не может обернуться фатальными последствиями на проде, и нет явных пробелов в её документации - данные вопросы можно смело считать абсурдом!
- Преобладание вопросов по самым-самым новым технологиям. Такие вопросы тоже ИНОГДА хороши, если новая технология - явно большая и глубокая. Но ведь в 95% случаев не так. В 95% случаев новые фичи и технологии - это то, что изучается разработчиком уровня middle и выше за время в пределах одной недели. Критическая важность знания спецом новых технологий - это абсурд чистой воды! Заметьте: именно знания их, а не интереса и стремления узнать новое. Это как раз важно, и об этом позже!
Вопросы, проверяющие уровень подготовки к собеседованию. Это про солиды, китов ооп, банду четырех паттернов и им подобное. Ужас таких вопросов даже не в том, что их могут прочитать и ну абсолютно все, начиная со стажёров (а отличить "реальное применение" от "прочитал и понял" таких почти невозможно).
- Ужаснее то, что в современных ресурсах они описаны в ОЧЕНЬ многих местах другим языком. Паттерны можно легко встретить среди каких-то общих советов по организации кода. SOLID упоминаются во множестве книг по разработке, просто другими словами и не называется принципом SOLID. Поэтому "не знающий, но использующий" - такой-же частый типаж, как "знающий, но не использующий". Абсурд? Абсурд!
Live coding простой рабочей задачи.
"А давайте-ка мы посадим разраба делать задачу за наш срок, на наших глазах с комментариями и без возможности гугла. И сделаем на основании этого вывод о том, как он решает задачи за свой срок, без наблюдения со стороны и с гуглом."
- Абсурд? Абсурд. Но вот тут есть исключения, об этом ниже.
"Критикуешь - предлагай!" - прочитав всё это, воскликнут узнавшие себя интервьюеры! И наверное, не только они.
А я возьму, и предложу!
Задачи уровня easy (и некоторые medium) с LeetCode. Главное, чтобы они НЕ требовали знания специфических алгоритмов и нарешивания похожих задач. Всё, что нужно знать для решения такой задачи - это коллекции и типы данных, используемые в языке, а так-же самые базовые алгоритмы.
Что интересно, даже такие задачи на собеседованиях - объект ненависти 90% программистов.
"Я клепал формочки - а теперь хочу клепать за х2, а мне оказывается задачки надо решать?!"
"Задачи эти потом нигде в работе не пригодятся!!!111"
"Собеседующие поднимают ЧСВ себе этими задачками!!!111"
Про то, что заученные особенности фреймворка, знание кишок и отскакивающие "три кита ООП" от зубов ему тоже не пригодятся - такой товарищ конечно же умолчит.
- Потому что на самом деле, прочитать что-то перед собесом - банально легче, чем выгружать в мозг совершенно новую задачу, мыслить и рассуждать о её решении))
Всё, что связано с системными особенностями и окружением. Это как раз то, без чего нельзя. То, что может пройти через ревью, тестирование - и дать огромный крэшище на проде. То, что возможно проверить заранее, но какими-то экзотическими методами. И ничего, если это кажется на работу тестировщика/админа/ещё кого-то. И вот конкретно в этом случае адекватным будет даже вопрос про внутрянку.
- Потому что цена таких факапов может быть высока, а справляться с ними придётся разработчику.
- Вопросы на кругозор по основному стеку. Когда мучают что-то одно вглубь - это ужасно. А вот проход по стеку технологий "в ширину", а не "в глубину" - показывает кругозор и адекватную любознательность.
- Секции системного дизайна и архитектуры. Эта штука позволяет узнать кучу практических подходов разработчика. Да, это тоже ОЧЕНЬ субъективный пункт. Один "забивальщик" на архитектуру может в итоге для конкретной компании быть полезнее двух идеалистов-перфекционистов. Но он даёт ещё весьма неочевидный плюс - показывает отличия во взглядах людей на архитектуру. Это то, что потом будет очень сложно исправить в процессе работы. Гораздо сложнее, чем замечания на pull request'ах в духе "используй вот эту новую фичу языка".
Испытательный срок, в ходе которого собеседуемый работает в компании короткий период по несколько часов в неделю, совмещая с текущим местом работы. Как-то раз мне пришло такое предложение на почту. Это идеальная вещь, которая способна решить почти все проблемы найма.
Проблемы тут только две:
- В законодательстве такой испытательный срок не предусмотрен.
- - Очень напоминает те самые "легендарные" неоплачиваемые тестовые задания, которыми компании решают свои задачи. В общем-то, следствие п.1
Почему же всё так плохо?
Секрет прост: программистов, на самом деле, очень много. И уже давно.
В 2010 мы с родителями ходили в университет, узнавать про факультеты и направления. В одном неплохом вузе нам сказали прямо: "Мы трудоустраиваем всех, кроме it-факультетов. Потому что программистов много, и начинающих трудоустроить проблема."
Да, программистами там обычно называют всех айтишников. Да, кучи курсов, джунов, растущие зарплаты на рынке, и вот это всё.
Но большинство не понимают, что в отраслях, где спецов реально мало - за вас говорит портфолио, опыт и отзывы предыдущих клиентов. И всё. Изобретать извращения на собесах там особо некому (мало же), да и незачем.
А разработка ещё и стремительно развивается. А база знаний и технологий развивается с троекратной скоростью. И когда кого-то "много", и нельзя просто взять и выбрать "кто дешевле" - начинаются субъективные оценки.
Но на самом деле, ненавидят "нормальные" вопросы обе стороны.
Про собеседуемых всё понятно - им проще "почитать солиды".
Более того - большинству из них ещё и совершенно плевать, какой продукт делать, и на каких технологиях. И вместо долгого процесса прохождения интервью в 1-2 компании - они предпочтут короткие интервью в 10, с быстрыми офферами и возможностью торга.
А интервьюерам жалко времени на подбор задачек, жалко времени на несколько секций. И страшно что в итоге отсев по задаче будет некорректным. Да, да вот это самое: "А вдруг он по факту знает и умеет столько же, сколько и я? Просто устал на работе, давно решал задачи, и не может решить вот конкретно эту задачку?!".
Но самое главное ...интервьюер тоже иногда ходит по собеседованиям! Он тоже "не любит" задачи, "не хочет тратить своё время на несколько секций", и хочет быстрее этот ваш оффер или отказ. Он не будет внедрять в интервью процесс, к которому сам имеет отвращение.
Поэтому со временем, процент "субъективщины" и абсурда на собесах будет только расти.
Я гарантирую это. Я ведь такой-же вынужденный участник этого театра абсурда :))
