2. Whiteboarding

Еще одним крайне странным подходом является witeboarding, то есть написание кода на доске, листке, или в блокноте. Каждый раз когда я сталкиваюсь с этим, я неистово удивляюсь и злюсь. Когда кто-то в последний раз писал код в блокноте, а не в IDE? А если писал, то для чего этот странный человек занимался такой чушью?

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

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

В языках есть миллионы синтаксических конструкций и методов, которые можно использовать и именно для этого были придуманы IDE. Они нужны, чтобы в повседневной работе давать подсказки и отлавливать синтаксические ошибки, которые разработчик случайно допустил.

Собственно, whiteboarding — не более чем архаизм от дедушек, которые писали код на перфокартах (со всем уважанием к дедушкам).

3. Отсутствие связи с жизнью

Тут есть два аспекта.

Во-первых, навыки работы с алгоритмами далеко не часто реально требуются в работе и далеко не на всех функциях. Например, работа с алгоритмами сильно реже встречается на фронте и сильно чаще — на бэке. И мне абсолютно не ясно для чего требовать знания тех вещей от кандидатов, с которыми они не будут работать в реальности. Почему бы не проверять такие навыки только там, где они действительн остро требуются?

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

Вывод

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

Так вот, результаты исследований говорят, что этот коэффициент примерно равен 0.5 для классической алгоритмической секции, то есть шанс правильного отбора кандидата через стандартную алгоритмическую секцию равен 50%. Это означает, что эффективность равна броску монетки. Можно вместо часа задач подбросить монетку и в случае выпадения решки пропустить кандидата дальше.

Как вы могли догадаться подходы с таким уровнем эффективности не должны применяться при отборе кандидатов. Однако, мы живем в мире, где это все еще является стандартом и нам приходится играть по правилам индустрии. А @tifongod уже писал, как готовиться к таким собеседованиям и как их проходить.

#собеседования